AI is moving at a pace that's hard to keep up with — new models every few months, new providers, new ways for an assistant to actually do something instead of just answering questions. Delphi developers shouldn't have to sit on the sidelines of that while everyone else builds in Python or JavaScript. That's the whole premise of TMS AI Studio: bring modern AI — cloud models, local models, and the tool-calling standard that ties them to real applications — into native Delphi, with one consistent way of working across all of it.

Version 2.0 pushes on every one of those fronts at once. It keeps pace with the fastest-moving part of the AI world — MCP, the Model Context Protocol that lets assistants like Claude and ChatGPT call into your own tools — while adding a major new AI provider, OpenRouter.ai, to the growing list you can already reach from a single component. And crucially, none of it costs you a rewrite: everything you built on an earlier version keeps working exactly as it did.

Always on the newest revision of MCP

The real headline here is the newest revision on the block: 2026-07-28, published only weeks ago, is already fully supported — not on a roadmap, not "coming soon," but there today, on both the server and client side. And it doesn't stand alone: everything the spec has added since the very first release in late 2024 — five revisions in total — is supported right alongside it, so nothing an older assistant relies on stops working the moment a newer one shows up.

That's what staying current with MCP actually means in practice: not scrambling to catch up every time the spec moves, but already being there when it does.

Under two years old, five revisions in, and TMS AI Studio hasn't missed one.

Upgrade today. Nothing breaks.

None of the above is something you opt into feature by feature. Recompile an existing MCP server or client against v2.0, and it's simply fluent in more of the protocol than it was before — because the server and whatever connects to it always agree, automatically, on the newest dialect they both happen to know. An older assistant still gets a correct conversation; a newer one gets everything the latest revision has to offer. Your code doesn't need to know the difference:

// exactly the code you already have
Server := TTMSMCPServer.Create(Self);
Server.Transport := Transport;
Server.RegisterTool('get_weather', GetWeatherHandler);

// on v2.0, this same server now negotiates
// protocol revision 2026-07-28 with any client that supports it —
// nothing above this comment changed to make that happen

The same is true if you're building the other end of that connection. A TTMSMCPClient you already wrote does exactly the same negotiation, automatically, the moment it connects:

// exactly the code you already have, on the client side
var
  Server: TTMSMCPClientServerItem;
begin
  Client := TTMSMCPClient.Create(Self);
  Server := Client.Servers.Add;
  Server.TransportType := ttHTTP;
  Server.URL := 'https://your-mcp-server.com/mcp';
  Server.Start;
end;

// on v2.0, this same client also negotiates the newest
// protocol revision the server understands — again, nothing
// above this comment needed to change

Forward on both sides of the conversation

It's easy for a release like this to quietly favor one side — the server catches up, the client lags behind. Not here. Both directions move forward together, and a couple of smaller conveniences arrive with them: connected assistants now find out immediately when you add or remove a tool, resource, or prompt — no extra call required —

Server.Tools.RegisterTool('add_note', AddNoteHandler);
// that's it — every connected assistant is told about
// the new tool automatically, the moment it's registered

— and sign-in now works the same way in both directions, as the next section covers.

OAuth in the client: signing in without writing a sign-in flow

A server-side login screen is only half of OAuth. The other half is a client that knows how to react when a server says "not so fast" — and until now, that side of the conversation was something you had to build yourself. In v2.0, TTMSMCPClient does it for you.

When a protected MCP server answers with "unauthorized," the client's transport notices on its own, works out which login service to trust, opens the system browser for the user to sign in and approve access, and — once that's done — retries the original request with the token it just received. No callback to wire up, no token storage to write, no retry logic of your own:

var
  Server: TTMSMCPClientServerItem;
begin
  Client := TTMSMCPClient.Create(Self);
  Server := Client.Servers.Add;
  Server.TransportType := ttHTTP;
  Server.URL := 'https://your-mcp-server.com/mcp';
  Server.Start;
end;

// if the server responds "unauthorized", the client opens a
// browser, waits for the user to approve, and quietly retries —
// nothing above this line needed to know a login was coming

Three steps, zero lines of sign-in code — the client handles all of it on its own.

Want a hand on the wheel anyway? A handful of events let you step in exactly where it helps — open the sign-in page in your own embedded browser control instead of the system one, choose which login service to use when a server offers more than one, or simply get notified the moment a token comes back. Leave them alone, and the client still signs in correctly without you touching any of it.

One gateway, hundreds of AI models: OpenRouter.ai support

With the latest extension to TMS AI Studio, Delphi developers can now also use OpenRouter.ai as a cloud LLM service. Switching to OpenRouter is as simple as changing a single property:

TMSMCPCloudAI1.Service := aiOpenRouter;

From that point on, TMS AI Studio takes care of the service integration, allowing your Delphi application to access the wide range of AI models available through OpenRouter's unified API.

The model to use can be selected through:

TMSMCPCloudAI1.Settings.OpenRouterModel := 'z-ai/glm-5.3-flash';

The default model is z-ai/glm-5.3-flash, which offers an attractive combination of high performance and low usage cost. In fact, attractive pricing is one of the interesting aspects of using OpenRouter.ai. It provides access to a very broad selection of models, with many capable models available at remarkably low token prices. This makes OpenRouter particularly interesting for developers who want to experiment with different LLMs, as well as for applications where AI is used frequently and inference cost therefore becomes an important consideration.

Of course, another major strength of OpenRouter.ai is that you are not tied to a single model provider. Its catalog provides access to a large and continuously evolving selection of models, including popular model families from OpenAI, Anthropic Claude, Google Gemini, Meta Llama, DeepSeek, Qwen, Mistral, xAI Grok, Z.AI GLM, and many others. This makes it particularly convenient to experiment with different models or select the best model for a particular task without having to implement a different API integration for every AI provider.

Another interesting OpenRouter feature, especially for professional and European users, is its support for data residency and provider routing controls. With the appropriate OpenRouter business offering, routing can be restricted to infrastructure in specific regions, such as EU-only or US-only processing. This can be important when considering data privacy, regulatory requirements and data sovereignty policies.

And this is precisely where TMS AI Studio becomes especially powerful. OpenRouter.ai is yet another service that plugs into the same Delphi-friendly architecture:

Ten AI providers, cloud and local, behind one consistent component. OpenRouter is simply the newest door into that same room.

With the meanwhile extensive range of directly supported cloud LLM services, local LLMs and hundreds of available models, developers can integrate AI into Delphi applications through one consistent component API. Changing from a local model to a cloud model—or experimenting with an entirely different model family—can often be reduced to changing just a service or model property, while the rest of the application code remains unchanged.

With OpenRouter.ai added to TMS AI Studio, Delphi developers gain even more choice in models, providers, performance and pricing, while continuing to work with the same familiar TMS AI Studio component architecture.

More models, more providers, attractive AI pricing and more deployment choices—without adding more complexity to your Delphi application.

Easier to learn, easier to build on

Alongside the release itself, a few things changed in how you actually get to it. Full documentation for everything in v2.0 is already up, covering the protocol negotiation, the client-side OAuth flow, and every CloudAI provider in detail. TMS AI Studio also joins the new install experience introduced across TMS products, and as part of that, the demos move to their own GitHub repository — so you can freely edit them, keep your changes under version control, and not have to worry about a future install or Smart Setup run quietly overwriting the copy you've been working in.

What v2.0 adds up to

AI is changing fast, on every front — new models, new providers, new standards for how assistants reach real applications. TMS AI Studio v2.0 is about making sure Delphi doesn't have to wait to benefit from any of it. Your existing MCP servers and clients keep working, unchanged, while gaining everything the newest protocol revision has to offer, on both ends of the connection. Signing in to a protected server is no longer something you build by hand on either side. And reaching a wider, cheaper, ever-growing spread of AI models is now a one-line change rather than a new integration.

TMS AI Studio is the complete toolkit for bringing AI and the Model Context Protocol to your Delphi applications. Build MCP servers and clients, connect Claude and other assistants to your own tools and data, and add cloud AI to your VCL and FMX apps — all in native Delphi. Discover TMS AI Studio.