An MCP server is a small service that stands in front of a business system and offers it to an AI chat as a fixed list of tools. Atso is one of these: it gives a business one MCP connection that lets the AI chats their team already uses, such as Claude, ChatGPT and Gemini, read their business software across every account and organisation they own, with control over who can see and change what.
Plenty has been written about what is wrong with MCP, almost all of it for the people building servers. This is the version for the person who pasted an address into Claude and found the answers thinner than the demonstration suggested. Five limits explain most of that disappointment, and only one of them comes from the protocol itself.
What is an MCP server actually responsible for?
The protocol defines how an AI client and a tool server exchange messages, and almost nothing about whose data those messages reach. It settles the envelope, not the contents.
Read the specification and you find rules for JSON-RPC encoding, for two transports, for session identifiers and for error codes. What you do not find is any rule about how many accounts a server may hold, how it should tell one member of a team from another, or what it is allowed to write. Those are left to whoever builds the server. That single fact explains why two MCP servers for the same system can feel like different products, and why “MCP is limited” is usually the wrong diagnosis.
Why does an MCP server usually run on your own laptop?
Because one of the two transports in the specification works by your AI client starting the server as a program on the same machine, and it is the one the specification tells clients to support wherever they can: in the stdio transport, “The client launches the MCP server as a subprocess”, and “Clients SHOULD support stdio whenever possible”.
This is the limit that is genuinely structural, and it decides who can use a server at all. A stdio server lives on one computer. It cannot be shared with a colleague, it stops when the laptop sleeps, and its credentials sit in a configuration file on that machine. For a developer this is convenient. For a finance lead it means the connection exists in a form they cannot use.
Xero’s own MCP server is the clearest first-party example. It is started by your AI client
through an npx command in claude_desktop_config.json, which means it exists only on the
machine that launched it. That is a fine arrangement for the developer who set it up and no
arrangement at all for the bookkeeper who also needs the numbers.
The alternative is the Streamable HTTP transport, where the server “operates as an independent process that can handle multiple client connections”. That is the kind you connect by pasting an address, and it is what a hosted service gives you.
Why can an MCP server only show one account at a time?
Usually because the server was built to hold one set of credentials, and sometimes because the AI client will not let you add the same server twice. Claude.ai is the case documented below.
This is the limit business owners hit hardest, and it is worth being precise about where it comes from, because it is not the protocol. It is two independent choices stacked on top of each other.
The server side: a server has to be built to hold more than one set of credentials, and that is a decision its author makes rather than something the protocol arranges. Xero’s own MCP server offers two modes, and the difference is instructive. A Custom Connection carries a client ID and secret, and Xero describes it as “a better choice for testing and development which allows you to specify client id and secrets for a specific organisation”. One connection, one organisation. The second mode takes a bearer token instead, and Xero calls that “a better choice if you are to support multiple Xero accounts at runtime and allow the MCP client to execute an auth flow (such as PKCE) as required”.
So the multi-account route exists, and it is worth saying so plainly rather than pretending the limit is absolute. What it asks for is the part that matters: something has to run the authorisation flow and supply a fresh token for each account, and the server is still one you host yourself on one machine. The capability is real and the work is left to you.
The client side: even when a server could hold more, the AI client may not let you add it twice. An open issue on Anthropic’s connector tracker, raised on 15 April 2026 and still open when checked on 14 September 2026, reports exactly this. Adding a second connector at an address you already use returns “A server with this URL already exists”, which blocks connecting two accounts of the same service.
A vendor’s own server can hit the same wall from the other side. Asked whether one MCP connection could reach two Atlassian accounts, the answer on Atlassian’s community forum was that “Rovo MCP can only maintain a single active OAuth session per browser/account context, so connecting to two separate Atlassian accounts simultaneously isn’t supported yet”.
None of that is written in the specification. A server built to hold many accounts behind one address, and to name the account on every figure it returns, does not have this problem. That is the shape Atso takes with Xero.
Why can the server not tell who is asking?
Because authorisation is optional in the specification, and a server that skips it sees one shared system account instead of a person.
The wording is explicit: “Authorization is OPTIONAL for MCP implementations.” For servers running over stdio it goes further, saying they “SHOULD NOT follow this specification, and instead retrieve credentials from the environment”. A key in a configuration file has no idea which human is at the keyboard.
The practical effect is that the server cannot separate the person from the assistant from the shared account the credentials belong to. All three arrive as the same caller.
For one person on one laptop this costs nothing. For a business it decides whether you can answer two ordinary questions: who saw the payroll figures, and how do we cut off a contractor who has left. A server with no idea who is calling cannot answer either.
Atso took the option the specification leaves open and built OAuth 2.1 into the first release rather than a shortcut token, because Anthropic’s own connectors were found to fail against authless MCP servers. The practical result is that an owner can see every AI client holding a token for their organisation and revoke any of them, and revoking takes effect on that client’s next call.
Does connecting more MCP servers make the AI better?
No. Every connected server spends part of the same context window describing its tools before the assistant has read your question, so there is a point past which more servers make the answers worse.
Tool definitions are sent to the model before it sees your question, so they are charged on every request whether or not they are used. The assistant is slower and it pays for those tokens each time, and it is choosing from a longer list of tools that are wrong for the question in front of it.
This is a real constraint on us rather than an abstract one. Atso exposes 30 connector tools across seven connected systems, between three and six per system, and keeping that number down is a design decision made on every connector. A server that published every endpoint each of those systems offers would be a worse server.
Why do so many MCP problems turn out to be setup problems?
Because configuration is where the reported faults cluster. In a published study of faults filed against open-source MCP servers, configuration categories carry most of the labels.
The paper, published on 5 March 2026, gathered 407 MCP-related issues from 385 repositories, and labelling them produced 419 labels because some issues carry more than one. Server or tool configuration accounted for 31.74%, server or host configuration for 28.64%, and server settings for 27.45%. Documentation added 6.92% and ordinary programming faults 5.25%.
Those percentages describe how the fault labels fall rather than how the issues divide, and they come from public repositories rather than from hosted services, so read them as a shape and not a headcount. The shape is clear enough: the great majority of labels are about getting the thing running and pointed at the right data, and very few are about the model being incapable. When a connection disappoints, the first question is what it was configured to reach.
Which of these limits are protocol rules, and which are choices?
Only the transport behaviour is fixed. Whether a server holds one account or many, and whether it can tell who is asking, are decisions its author makes, which is why two servers for the same system behave differently.
| Limit | Where it comes from | Can a different server fix it |
|---|---|---|
| Runs on one machine | The stdio transport, by design | Yes, over HTTP |
| One account at a time | Server credentials, and client rules | Yes |
| Cannot tell who is asking | Authorisation is optional | Yes, with OAuth 2.1 |
| Tool descriptions cost context | Every connected server | Partly, by exposing fewer tools |
| Setup is where the reported faults cluster | How servers are distributed | Yes, by hosting it |
The useful version of “MCP is limited” is therefore narrower: this server is limited, in these named ways, and most of them are fixable by a different server rather than by a change to the protocol.
What does Atso do differently about these limits?
Atso is one hosted MCP connection that holds many accounts at once, authenticates each person with OAuth 2.1, and lets an owner revoke any AI client that holds a token.
Three of our own build decisions are limits worked around rather than features:
- OAuth 2.1 from the first release, although the specification marks authorisation as optional, because Anthropic’s connectors were found to fail against authless servers.
- Xero tokens held per login rather than per organisation. Xero issues one token set per login covering every organisation that login can reach, so storing one per organisation would have made sibling organisations invalidate each other’s tokens.
- A group total is never silently summed across currencies.
xero_group_reportreturns one column per organisation and marks the totalcomplete,partialwhen one organisation’s data was unavailable, oromittedwhen the organisations use different currencies. Every column names its organisation, its currency and the time the data was pulled.
The limits we have not solved are worth naming too. Tool descriptions still cost context. Prompt injection is still a live risk for every MCP server including ours. And a connection we have not built reads nothing at all, which is the subject of the vendors that ship no MCP server at all.
If you want the background on what an MCP server is before any of this, start with MCP servers for business software.