One Connection or One per Tool? Choosing How AI Reaches Your Systems

There are two common ways to connect AI to business systems through MCP. One server per tool gives narrower permissions and lets you lock each tool separately. One gateway in front of everything is simpler to connect and manage centrally. Neither is right for every business; the choice depends on risk, scale and who maintains it.

Should AI reach your systems through one connection or one per tool?

Choose by risk and by how many places need connecting. Separate servers per tool suit systems where a mistake is costly, because each can be locked on its own terms. A single gateway suits a business connecting many assistants to many low-risk tools, because it is set up once. Most end up with a mix.

The question comes up as soon as a team connects its second or third system. The CRM has a vendor server, the drive has another, and someone suggests putting everything behind one endpoint. That is a reasonable idea with real trade-offs.

This article lays out both options neutrally. The right answer depends on the systems involved, not on a preferred architecture.

How do MCP connections work?

MCP has three parts. The host is the AI application, such as Claude or an editor. A client inside it holds a connection to one server. The server is the program that exposes a system's tools and data. A host connecting to five servers runs five clients, one dedicated connection each.

According to the MCP documentation, the host creates "one MCP client for each MCP server", and each client "maintains a dedicated connection with its corresponding MCP server". Local servers usually serve one client; remote servers usually serve many.

The scale is large. According to Anthropic, there were more than 10,000 active public MCP servers by December 2025. So most systems a growing business uses already offer one, and the architecture question is how to arrange them. The MCP explainer covers the basics.

What does one server per tool give you?

Separation. Each system gets its own server, its own credential and its own permission rules. A read-only lock on the CRM does not depend on how the website connection is configured. If one server misbehaves or a vendor adds a risky tool, the damage is confined to that system.

Permission rules can target a single server cleanly. In Claude Code, for example, a rule written as the server's name followed by a wildcard matches every tool from that server, and nothing else. That makes per-tool policies easy to read and hard to get wrong.

Separate servers also suit separate clients or business units. A server registered for one client's systems cannot reach another's.

The cost is setup. Each assistant needs each server configured, and each credential is stored and rotated separately. A team with five assistants and eight systems faces a lot of connections to maintain.

What does a single gateway give you?

Simplicity at the edge. Each assistant connects once, to the gateway, and the gateway reaches every system behind it. Configuration, credentials and access control live in one place, and logging can be central too. Adding a new assistant becomes one connection instead of eight.

Docker describes its MCP Gateway as acting "as a centralized proxy between clients and servers, managing configuration, credentials, and access control." Other gateways and aggregating servers follow the same shape.

The trade-offs mirror the benefits. A gateway holds every credential, so it becomes the most valuable thing to protect. Its permissions must be fine-grained enough to keep each tool separate, or one broad rule covers everything. And if it fails, every connection fails together.

Tool volume matters as well. According to Anthropic's engineers, agents connected to thousands of tools may "process hundreds of thousands of tokens before reading a request". The MCP documentation suggests clients that federate many servers use progressive tool discovery rather than loading every tool up front.

How do the two compare?

Separate servers win on isolation and per-tool locks. A gateway wins on setup effort, central control and adding assistants quickly. Both can be secure, and both can be badly configured. The deciding factors are how risky each system is, how many assistants connect, and who will maintain the setup.

Unapproved connections are a risk either way. OWASP's MCP Top 10 lists shadow MCP servers and a lack of audit and telemetry among its top risks, so keep a register whichever pattern you use. The guide to access versus permission covers the locks themselves.

How do you choose for your business?

Sort your systems by what a mistake would cost. Anything that sends messages, publishes, spends or changes records of truth deserves its own server with its own lock. Low-risk reads, such as documents and reference data, can sit behind a shared connection. Then decide who maintains the setup, because an unmaintained gateway is worse than none.

A short decision guide:

1. List every system the AI should reach, and what it may do there.
2. Mark the risky ones: anything external, financial or hard to undo.
3. Isolate those on separate servers, read only to start.
4. Group the rest behind a gateway if many assistants need them.
5. Register everything, with an owner and a review date.

Revisit the choice as the business grows. A setup that suited three assistants may not suit thirty.

Skein designs how a client's AI reaches its systems, starting every connection read only and granting write access one tool and one action at a time; the shared knowledge layer page shows how that knowledge is reached. That suits a business connecting AI to several systems at once. A team connecting one assistant to one drive can simply use the vendor's own connector.

Frequently asked questions

What is an MCP gateway?

An MCP gateway is a server that sits between AI applications and many other MCP servers. Each assistant connects once to the gateway, which manages configuration, credentials and access control for the systems behind it. It simplifies setup and centralises logging, but concentrates risk in one place that needs careful protection.

Is one MCP server per tool more secure?

It is easier to keep narrow. Each system has its own credential and permission rules, so a lock on one tool never depends on another, and a fault stays confined. A well-run gateway can be secure too, but its own rules must be fine-grained enough to keep each tool separate.

How many MCP servers should a business connect?

As many as the work genuinely needs, and no more. Start with the systems a specific job requires, read only. Every connection is something to secure, register and review, so unused servers should be removed. The number matters less than knowing what each one can do.

Do too many MCP tools slow AI down?

They can. Each tool's description takes up space in the model's context, and Anthropic notes that agents connected to thousands of tools may process hundreds of thousands of tokens before reading a request. Load tools only when needed, and remove ones nobody uses.

Can I mix servers and a gateway?

Yes, and many businesses do. Put systems where a mistake is costly, such as messaging, publishing or finance, on their own servers with their own locks. Group low-risk reads behind a shared connection. Keep one register of everything connected, whichever route each system takes.

Related reading