MCP: Giving AI a Proper Door into Objo Studio

The newly released Objo Studio 26.8.5 lets external coding agents work directly with an open Objo solution. Not by rummaging through project files, and not through the traditional copy-and-paste protocol, but through a carefully designed implementation of the Model Context Protocol.

AI has arrived in development tools with all the subtlety of a marching band.

Every IDE now seems to have an assistant, a chat panel or some form of predictive code completion. Some are genuinely useful, others are just an attempt to jump on the AI-bandwagon.

For Objo Studio, I wanted to build something more fundamental.

Studio already has an optional built-in AI assistant, but the new External Agents (MCP) feature is different. Instead of deciding which assistant you should use, Objo Studio exposes a secure set of development tools through a standardised open protocol. You can then work with Codex, Claude Code, Visual Studio Code or another compatible agent of your choice.

Your IDE should not get to choose your AI for you.

What MCP actually changes

The Model Context Protocol is an open standard through which AI applications can discover and use tools supplied by other software.

A useful shorthand is that MCP gives AI agents something resembling a standard peripheral interface. Rather than teaching every agent a private Objo Studio protocol, Studio implements MCP once and compatible clients can connect to it.

In Objo Studio, the arrangement looks like this:

Codex, Claude Code, VS Code or another agent
					  ↕
			   MCP over stdio
					  ↕
	  objo-studio-mcp command line app
					  ↕
	   authenticated local connection
					  ↕
		the live Objo Studio solution

The MCP component is a small command-line companion bundled with Studio. The external client launches it and communicates through standard input and output. The companion then connects to Studio through a private, user-local named pipe on Windows or Unix-domain socket on macOS and Linux.

There is no web server quietly listening in the background, no open network port and no cloud relay belonging to Objo. If the feature is disabled, there is no endpoint at all.

More than “please write me a method”

The first version exposes 17 purpose-built tools. Together they allow an agent to:

• Discover open Studio solution windows.
• Read the live solution and project structure.
• Read source from Studio, including unsaved changes.
• Inspect the current editor context, caret and selection.
• Search and read the documentation bundled with Studio.
• Retrieve structured compiler diagnostics.
• Create, rename and move supported source items.
• Apply version-checked source edits.
• Open a document at a particular location.
• Compile a project through Studio’s normal compiler pipeline.
• Save the solution, when separately permitted.

This makes a very different workflow possible.

You might ask an agent to add validation to a class. It can inspect the solution, locate the relevant source, consult the Objo documentation if it is uncertain about an API, read the current unsaved buffer, apply an edit and compile the project. If compilation reports a mistake, the agent receives structured diagnostics and can correct it.

No project export. No guessing how an .objo package is arranged internally. No ritual offering to the clipboard. The clipboard has served nobly as the universal AI integration bus, but I think it has earned a rest.

The live IDE is the source of truth

External coding agents usually work with files on disk. That model is convenient, but it becomes awkward when an IDE owns richer state.

The code visible in your editor may not yet have been saved. A source item may have an internal identity that cannot safely be inferred from its filename. A structural change may need to update the project model rather than merely moving something in the filesystem.

Objo Studio’s MCP tools operate on that live model.

Documents and solutions carry revision numbers. Before changing something, an agent must provide the version it actually read. If you have typed, renamed, moved or undone something in the meantime, Studio rejects the stale edit and tells the agent to read the new state. Studio does not silently merge conflicting changes or let an agent cheerfully overwrite the work you did thirty seconds earlier.

Every successful external edit is also recorded as a normal Studio undo action. You can use Edit > Undo and Edit > Redo just as you would for your own changes.

Editing and saving are deliberately separate. An agent may be allowed to propose and apply changes while the solution remains unsaved. Persisting those changes requires the additional Save solution permission.

An open door

Letting an AI agent control an IDE requires more thought than adding a checkbox labelled “I trust the robot”.

External-agent access is off by default. A new client must be explicitly paired in Studio and initially receives read-only access. Further capabilities are granted separately:

A client cannot grant itself more permissions. Studio checks the stored permission immediately before every operation, so changing or revoking access takes effect without trusting the external process to behave itself.

Pairing uses a generated secret that Studio shows only while creating the configuration. Studio retains a salted hash rather than the original token. Credentials are passed to the companion through its environment rather than command-line arguments, and they do not appear in discovery records, solution files or activity history.

Recent activity is visible inside Studio, but it contains only safe metadata such as the client, tool, duration and outcome. Source code and tool arguments are not retained in that history.

Why MCP cannot run your program

One omission is intentional: an external agent cannot run or stop an Objo application through MCP.

At first glance, allowing a run after each edit sounds convenient. Unfortunately, Objo applications can use desktop APIs that launch processes or interact with the operating system. Giving an agent permission to edit arbitrary source and then execute it would effectively grant those abilities too.

Putting a confirmation dialog immediately before that operation would make it more visible, but it would not make the capability narrow. It would be security theatre with an OK button.

MCP can compile and inspect diagnostics, but it cannot run an application, launch a process, use a terminal or read and write arbitrary files. It also cannot access Build, Publish or Profile.

The visual designer, testing and debugging are outside this first MCP release too. I would rather expose a small set of operations with clear semantics than advertise an “AI-powered IDE” and quietly hand the agent a shell.

How this differs from the other RAD tools

It would be unfair to suggest that other development tools are doing nothing with AI.

WINDEV’s published material describes context-aware generative WLanguage completion, including inline suggestions based on the current project, windows, reports and data definitions. That can certainly make typing faster. However, predictive text at the cursor is still predictive text at the cursor. It is not an open interface through which an independent agent can inspect a live project, make guarded structural changes and compile the result.

Xojo has also moved beyond a simple chatbot. Its 2026r2 release notes say that Jade can request project source and compiler errors and can work with several hosted or local model providers. That is welcome progress. The documented code workflow, however, still centres on copying or inserting generated code into the currently selected method. It is an assistant embedded in the IDE rather than the IDE exposing a stable, permissioned tool surface to whichever external agent the developer prefers.

Visual Basic developers working in Visual Studio have access to a much larger AI ecosystem, and Microsoft deserves credit here. Visual Studio’s Copilot agent mode can use built-in tools and connect to MCP servers.

The direction of that integration is important, though. Visual Studio acts as the client, bringing external MCP services into its Copilot workflow. Objo Studio also acts as a tool provider: Codex, Claude Code and other clients can connect to the live IDE. You are not required to move your working relationship into one vendor’s chat panel.

Microsoft’s current documentation also notes that its Copilot agent does not support stepwise undo or redo. Objo’s MCP changes participate in Studio’s normal undo system because external editing was designed into the automation boundary rather than added as a special file-replacement path.

This is not about declaring that established products have no AI features. They clearly do. The distinction is between adding AI to an IDE and making the IDE genuinely accessible to an open ecosystem of agents.

Small tools can make architectural bets too

Objo Studio is a much smaller product than Visual Studio or WINDEV. I cannot compete with those companies by buying more GPUs or adding a slightly more enthusiastic sparkle icon to a toolbar but I can make better architectural choices.

The important part of this feature is not a particular language model. Models will improve, prices will change and today’s favourite assistant may not be tomorrow’s. Tying the deepest integration to one model or one chat product would make Studio’s capabilities age at the same rate as that choice.

MCP gives Objo Studio a stable boundary between the IDE and the agent. Studio owns the project model, compiler, permissions, undo history and safety rules. The external client owns the conversation and model selection. Either side can evolve without pretending they are the same product.

That separation also means external-agent access is not a premium AI add-on. Reading, editing, compiling and saving through MCP are available without an Objo Studio licence. Build, Publish and Profile remain the licensed capabilities, exactly as they are elsewhere in Studio.

The beginning, not the destination

This first MCP release is intentionally source-focused. It does not yet expose the visual designer, debugger, test runner or project creation. Those areas need proper semantic operations and their own security review; they should not be reached through a generic “do whatever seems useful” tool.

Even with that boundary, this release changes what working with Objo can feel like. An external agent can understand the project you actually have open, consult the correct documentation, work with unsaved source, make reviewable changes and learn from the real compiler.

That is substantially more useful than a clever autocomplete, and substantially safer than turning an agent loose on an undocumented project package.

The differentiator is not simply that Objo Studio “has AI”. By now, almost everything has AI. Presumably my toaster is waiting for a firmware update.

The differentiator is that Objo Studio treats your choice of agent as yours, exposes its capabilities through an open protocol and keeps the IDE—not the model—in charge of what is allowed.

That, I think, is where development tools need to go next.

Download Objo Studio