What MCP Actually Standardises — and Why We Haven't Adopted It Yet

The short answer

The Model Context Protocol is a standard interface between an AI application and the tools or data it uses. Before it, every assistant wrote a bespoke connector for every service — an N×M problem, where N assistants times M services meant nobody built the long tail. MCP makes it N+M: a service exposes one MCP server, and every MCP-speaking client can use it.

That is the whole idea, and its unglamorousness is the point. It is USB for tool access. Vyra does not support it today, and this post ends with an honest account of why, because "we haven't built it" is a more useful answer than a reframe.

The problem it fixes

Before a standard, giving an assistant access to your filesystem, your database and your issue tracker meant three integrations written specifically for that assistant. Do it again for a second assistant and you write three more.

The economics of this are brutal for everyone except the largest vendors. A connector only gets built when (assistant popularity × service popularity) clears the engineering cost, which means the biggest assistants get the biggest services and nothing else gets built at all. Your internal tooling — the thing you most want an assistant to reach — never clears the bar, because you are one customer.

MCP inverts the incentive. You write one server for your internal tool and every compliant client can use it. Suddenly building the connector is worth it, because you are doing it once for yourself rather than lobbying vendors.

What an MCP server actually exposes

Three primitives, and the distinctions between them matter more than they first appear:

Tools are functions the model can call — with a name, a description, a typed input schema, and side effects. create_issue, run_query, send_message. This is the primitive everyone means when they say MCP.

Resources are data the client can read — files, records, documents — addressed by URI. Crucially, reading a resource is not a model decision; the application fetches it and puts it in context. This separation is a real safety property: resources cannot be triggered by the model deciding to call something.

Prompts are reusable templates a server offers, surfaced as user-selectable commands rather than model-invoked actions.

The protocol runs over JSON-RPC, with a local transport (stdio, for a server running as a subprocess on your machine) and a remote one (HTTP with server-sent events). The local case is the one that changed things most: an MCP server running on your laptop reaches your actual filesystem and your actual local database, with no cloud round trip for the data itself.

What it does not do

Worth being precise, because MCP gets credited with properties it does not have.

It is not an agent framework. MCP describes how a client discovers and calls a tool. It says nothing about planning, memory, retries, or how an agent decides what to do. Those remain entirely the application's problem. An MCP client with no orchestration is a very well-connected chat window.

It does not provide memory. There are memory MCP servers, and they work, but they are servers like any other — the protocol has no opinion about persistence. An assistant whose memory is an MCP server has memory the way a program with a database has state: it works, and it is something you assembled and maintain rather than something the architecture provides.

It does not solve authorisation. The server handles credentials. The protocol standardises the call, not who is allowed to make it. Scoping remains yours to design, and a permissive MCP server is exactly as dangerous as a permissive anything else.

It does not defend against prompt injection. If a tool returns content containing instructions, the model sees it as tokens like any others. In fact, by making it dramatically easier to connect an assistant to more data sources, MCP widens the surface that hostile content can arrive through. The protocol makes the plumbing standard; it does not make the water clean. This is the blast-radius argument — the mitigation is scoping what a compromised client can do, not trusting the channel.

Why an open protocol changes what an assistant is for

The deeper effect is on product shape rather than on integrations.

An assistant with a fixed set of built-in capabilities is a product: someone decided what it does, and that decision is the thing you are evaluating. An assistant that speaks an open protocol is closer to a platform: what it does is determined by what you connect, and the vendor's job is reasoning quality and orchestration rather than coverage.

Both are coherent. They suit different people. A platform rewards users willing to configure it and punishes those who are not — an MCP client with nothing connected does very little, and the setup cost is real: servers to install, credentials to provision, permissions to think about. A product works immediately and stops exactly where its author stopped.

Claude Desktop is the clearest expression of the platform approach and is genuinely excellent at it; we compare the two shapes directly on Vyra vs Claude Desktop.

Why Vyra has not implemented MCP

The honest version.

Vyra's integration surface is fixed: n8n, a native automation workspace, smart-home control, an autonomous web agent, messaging across WhatsApp, Telegram and Discord. That is a product-shaped decision, and it was made for a specific reason — Vyra is built around a goal engine that runs unattended in the background, and unattended execution against arbitrary user-installed tools is a harder safety problem than the same tools used interactively.

When you invoke a tool in a chat session, you are present. You see the call, you see the result, you catch the wrong one. When a background executor invokes a tool at 3am against a server whose semantics the system has never seen, there is nobody to catch anything. The irreversible-action detection that makes background execution defensible relies on understanding what an action does, and a tool description written by a third party is a weak basis for that judgement.

That is a reason to be careful, not a reason never to do it — and it is not the whole truth. The rest of the truth is that Vyra is in closed alpha, built by one person, and MCP support is a significant piece of work that has not been prioritised over making the core loop good. Framing a resourcing decision as purely a safety principle would be dishonest.

So: not supported today, no shipped date, and if open extensibility into your own tools is your deciding factor, Claude Desktop is the better choice right now and we would rather say so than imply a roadmap we have not committed to.

Common questions about MCP

Do I need to be a developer to use MCP?

To write a server, yes. To use existing ones, decreasingly so — clients have made installation much simpler, and there are directories of ready-made servers for common services. Connecting an assistant to your own internal tool still means someone writes a server.

Is MCP a standard or one vendor's protocol?

It was introduced by Anthropic and released as an open specification, and adoption has spread well beyond Anthropic's own products — multiple clients and a large ecosystem of third-party servers. It behaves like an open standard in practice. It is not administered by a traditional standards body.

Does MCP work with local tools and data?

Yes, and this is one of its better properties. The stdio transport runs a server as a local subprocess, so it reaches your filesystem, local databases and local services directly. Note the distinction that gets blurred: the data access is local, but the model reasoning about it is usually still a cloud model, so context is transmitted. Local tool access is not local inference — a distinction also worth watching in local vs cloud model routing.

Will Vyra support MCP?

No committed plan and no date. The architectural hesitation is real — unattended background execution against arbitrary third-party tools is a genuinely harder safety problem than interactive use — but the more immediate reason is simply that it is a large piece of work on a small project. If it becomes the thing people most want, that changes the calculus.

---

Vyra is a resident agent with built-in integrations and a background goal engine, not an extensible client. Which of those you want is a real decision, and the comparison pages are written to help you make it rather than to win it. Join the waitlist if the resident-agent shape is the one you are after.