# What are the limits of an MCP server today?

Most MCP servers run on one laptop, hold one account and cannot say who asked. Here is which of those limits the protocol imposes and which are choices.

Published: 2026-09-14
Source: https://atso.ai/blog/mcp-server-limitations/

---

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](/blog/claude-multiple-xero-organisations/).

## 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_report` returns
  one column per organisation and marks the total `complete`, `partial` when one
  organisation's data was unavailable, or `omitted` when 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](/blog/business-software-without-mcp-servers/).

If you want the background on what an MCP server is before any of this, start with
[MCP servers for business software](/blog/mcp-server-for-business-software/).