Enterprise MCP Server: How to Design, Host and Govern One

An enterprise MCP server exposes one domain of your systems as a small set of well-described tools, authenticated per caller, restricted to least privilege, logged on every call and run somewhere your security team can govern. The protocol makes a server easy to write; the enterprise part is everything around the code.

Server, not platform

Keep the terms straight. A server is the component that turns tool calls into operations on a system. A platform is the layer above that governs many servers, as covered in the gateway article. An enterprise usually ends up with both: several focused servers and one control point. A common mistake is to push governance logic into each server, which duplicates effort and drifts out of sync.

Design rules that survive production

One domain per server. A CRM server, a billing server, a document server. Narrow servers are easier to review, scope and retire.

Few tools, clear names. Models pick tools from their descriptions. Ten precise tools beat fifty overlapping ones. Write descriptions for a reader who knows nothing about your internal jargon.

Separate read from write. Put queries and mutations in different tools so a policy can allow one without the other. Never hide a delete behind a tool named “update”.

Return less. Return only the fields the task needs. Large raw records waste context and leak data the model never required.

Idempotent and bounded. Writes should be safe to retry, and queries should have limits so one call cannot dump a table.

Errors that teach. A clear error message lets the model correct itself instead of looping.

Key takeaway: the best tool is the one you would be comfortable letting a new, fast and slightly overconfident intern call without supervision.

Choosing where to run it

Option	You operate	Data path	Typical use
In your VPC or hardware	The server and its uptime	Stays inside	Internal APIs, legacy systems, databases
Managed remote endpoint	Nothing, but you configure connections	Passes through the vendor	Standard SaaS business data
Developer laptop	Everything	Local	Prototyping only

BusinessMCP illustrates both ends. Its hosting service gives you a managed endpoint for business data tools such as analytics, CRM contacts, Stripe revenue and Search Console, and it states that it hosts your data connections, not your own server code. Its Enterprise page covers the other end: a custom MCP server inside the customer’s VPC or on their own hardware, with delivered source code and documentation, which BusinessMCP does not operate after handover. Knowing who runs the server afterwards is a contract question worth settling early.

If you want to build the server yourself, BusinessMCP’s documentation includes a walkthrough on building an MCP server and on connecting a custom MCP server to its endpoint.

Security basics inside the server

1. Authenticate every request. Do not rely on network location alone.
2. Validate inputs. Treat arguments from the model as untrusted user input, because they effectively are.
3. Use a dedicated service account with the minimum rights on the underlying system.
4. Keep secrets out of tool output. A model that can read a token can repeat it.
5. Guard outbound requests. If a tool fetches URLs, block internal addresses to prevent server-side request forgery. BusinessMCP publishes its gateway’s SSRF guard under an MIT licence, which is a useful reference implementation.
6. Log calls with caller, tool, arguments and outcome.

The wider checklist is in MCP security best practices for enterprise.

Lifecycle and ownership

A server without an owner becomes a liability. Assign each one a named team, a version number and a retirement plan. Decide how changes to tool names and schemas are announced, since agents and prompts may depend on them. Add a smoke test that lists tools and calls one harmless tool, and run it on every deploy. Monitor latency and error rate per tool; a tool that fails often trains models to avoid it, which quietly changes agent behaviour.

Testing with real agents

Unit tests do not tell you whether a model will choose the right tool. Build a small evaluation set of realistic requests and record which tool each one calls and whether the result is correct. Run it after any change to descriptions or schemas. Include adversarial prompts that try to push the agent toward forbidden actions, and confirm the policy blocks them rather than relying on the model to refuse.

When not to build a server

If the tools you need are standard (web analytics, a CRM, ad accounts, billing) and already available through a managed endpoint, building duplicates work and adds maintenance. Reserve custom servers for systems no hosted option reaches. For a view on how teams decide, see how to implement MCP in an enterprise, and for the cost side compare pricing models.

A short pre-launch checklist

Before a server goes live, confirm these items on one page.

• The service account has only the rights the tools need, and nothing else.
• Every tool has a plain-language description, an input schema and a documented failure mode.
• Read and write tools are separate and can be allowed or denied independently.
• Result sizes are capped and sensitive fields are stripped by default.
• Calls are logged with caller identity and outcome.
• There is a named owner, a rollback path and a way to disable one tool without redeploying everything.
• A restricted test key has been used to confirm that forbidden calls are refused.

If you will connect the server to a governed endpoint rather than expose it directly, the access rules should live there, as described in enterprise MCP access control, while the server stays small and focused. That separation keeps each piece reviewable.

Naming and describing tools so models choose well

Tool descriptions are effectively the user interface, and the user is a model. Start each description with the verb and the object: “Search customer accounts by name or domain and return up to 20 matches.” State what the tool does not do, such as “Does not return contact emails.” Give parameter descriptions with examples of valid values and units. Avoid internal acronyms, and avoid two tools whose descriptions overlap, because the model will pick between them unpredictably. When you rename a tool, treat it as a breaking change: agents, saved prompts and policies may all reference the old name. Keep a changelog next to the server, and announce changes to the teams whose agents depend on it. A few hours spent on descriptions typically removes more failures than any amount of retry logic, and it costs nothing at runtime.