# What is an MCP server for business software, and why does one connection for many accounts matter? An MCP server lets an AI chat read your business software directly. Here is what that means when the business owns four accounts rather than one. Published: 2026-09-07 Source: https://atso.ai/blog/mcp-server-for-business-software/ --- An MCP server is a small service that sits in front of a business system and offers it to an AI chat as a set of named tools the AI is allowed to call. 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. ## What is an MCP server? It is a service that translates a business system into a fixed list of actions an AI chat can take. K2view describes the Model Context Protocol behind it as "a standard designed to connect GenAI applications with enterprise data and AI tools". Each action has a plain name and a fixed shape. Atso's Xero server publishes nine of them, all prefixed `xero_`, covering 17 resource types and 8 reports. Ask Claude for last month's profit and loss for one company and it picks the report tool, fills in the organisation and the date range, and reads the answer back. Nothing is uploaded, nothing is pasted, and the figures are the ones in the accounting system at that moment. ## How is an MCP server different from an API? The API is how software reads your data. The MCP server is the standard wrapper that lets an AI chat use that API without anyone writing custom code for it. Cal.com's rundown of MCP servers separates the two jobs in a list. An API is the way you reach business data; the MCP entry reads "MCP servers help you create a stable connection with business data sources". Xero has had an API for years, and that is the problem. An API assumes a developer on the other end who reads the documentation, handles the tokens, and builds the thing that asks the questions. MCP moves that work into a piece of software you connect once, so the AI can ask the questions itself. ## Why would a business want one at all? Because it removes the export step. The AI reads the live figures instead of a spreadsheet somebody exported last Tuesday. An export is a photograph of the books at one moment, and it loses the structure on the way out. The AI sees rows of text with no idea which account they came from, which currency they are in, or whether a later credit note changed them. A connection has none of those problems, and it does not go stale between the question and the answer. ## What happens when the business owns more than one account? This is where most MCP servers stop, because one connection usually means one account. An owner with four Xero organisations disconnects one before reaching the next. Xero's official MCP server is honest about this, and it is worth being clear that Xero does have one. It is, in the words of a walkthrough checked on 6 September 2026, "a self-hosted, local server you run yourself with developer credentials, not a hosted mcp.xero.com". It needs "A Xero developer app with a custom connection (client ID and secret)". And the line that matters most for a group: "A custom connection is tied to a single Xero organisation." So the shape of the problem is not a missing feature. It is the default. One connection, one account, and a business with several accounts doing the switching by hand. ## Why does one connection for many accounts matter? Because the questions an owner asks are group questions, and an AI that sees one entity at a time cannot answer them. "Which of my companies is carrying the payroll cost?" "Did the same supplier raise prices in all four?" "Where did the group's cash actually go last quarter?" None of those fit inside a single organisation. With one connection per account the owner becomes the integration layer: disconnect, reconnect, copy a figure into a note, repeat, and hold the comparison in their head. That work is slow enough that most people stop asking the question, which is the real cost. ## What does a group answer have to get right? It has to say which account each number came from, and it must never quietly add together figures in different currencies. A group total with no labels is worse than no total, because it looks finished. That is a whole subject in itself, and Atso's Xero reporting is built around it. The server labels every figure with the organisation it came from, keeps currencies apart rather than summing across them, and says which organisation it could not reach instead of returning a total that quietly leaves one out. The post on [connecting Claude to several Xero organisations](/blog/claude-multiple-xero-organisations/) sets out the three words a group total can carry. ## Who in the team should be able to see which accounts? Access should be something the business sets, per person and per connection, rather than something everybody inherits the moment one account is connected. The common model today is inherited permissions. Skyvia describes it well for one popular server, the Salesforce MCP server, which "uses your own Salesforce access rights, so whatever you can or can't do in Salesforce also applies here". That is fine when one person connects one account for themselves. It stops being fine when a bookkeeper needs two of your five organisations and no more. Writing aimed at large IT teams does treat separation seriously, but as infrastructure. TrueFoundry, for example, groups servers by environment or business unit. That is a useful idea for a platform team with a gateway to run. It is not an answer for an operations lead who has five organisations, three colleagues, and no wish to run anything. ## Why does sign-in matter more than it looks? Because the specification makes authorisation optional, so a server can hold a company's books and ask nobody who they are. The Model Context Protocol authorisation specification says plainly that "Authorization is **OPTIONAL** for MCP implementations". Where authorisation is used, the same specification is strict about how. Authorisation servers "**MUST** implement OAuth 2.1", clients must use PKCE, and servers "**MUST** validate that access tokens were issued specifically for them as the intended audience". That last rule is what stops a token meant for one service being replayed against another. We built OAuth 2.1 into Atso on day one instead of starting with a shortcut token, because Anthropic's own connectors were found to fail against authless MCP servers. It cost real time before the first useful reply came back in a chat window. We would make the same choice again, because the alternative is a server holding a group's books with a bearer token in a settings field and no way to see who is using it. In Atso an owner can list every AI client currently holding a token, and revoke one, which takes effect on that client's next call. ## Do you have to be a developer to use one? No, but the server you are most likely to meet first assumes you are. Xero's official MCP server, checked on 6 September 2026, is self-hosted and needs "A Xero developer app with a custom connection (client ID and secret)". The AI chat side is already easy. Claude's own documentation describes the whole step as "Add your connector's remote MCP server URL", and custom connectors are available on the Free, Pro, Max, Team and Enterprise plans, with free users limited to one. The hard part is what sits at the other end of that address. Atso's path is built for the person who will never run a server. You sign in with a magic link, connect each Xero organisation once, and paste one address into claude.ai. There is no client secret to generate and nothing to keep running on a laptop. ## What does Atso connect to today? Xero is live across several organisations, Infusion is live and read-only, Shopify has a connector but no tools yet, and Unleashed is not built. That list is deliberately exact: - **Xero.** Nine `xero_*` tools, several organisations behind one connection, covering 17 resource types and 8 reports. - **Infusion.** Three `infusion_*` tools. Reading only, and the restriction is enforced in code rather than by policy, because Infusion has no test company and every request goes against a real set of live books. Why that connector [cannot write to your books](/blog/infusion-mcp-server/) is a post of its own. - **Shopify.** An owner can connect and disconnect stores and see them listed. Claude cannot read Shopify data yet. - **Unleashed.** Nothing exists. If your business runs on one account of one system, an MCP server is a convenience. If it runs on four, the account boundary is the whole question, and it is worth asking any server you look at how it answers.