An enterprise MCP server is a small service your team runs that lets AI agents call your company systems, such as the CRM, ticketing, the data warehouse and internal docs, through one standard interface instead of a custom integration per tool. The hard part is not the protocol. It is deciding what to expose, scoping access tightly, logging every call, testing tools before an agent touches them, and naming an owner.
This guide is for engineering leaders setting Q1 plans who keep hearing "can the agent just connect to Salesforce?"
What an MCP server is, in plain terms
Anthropic introduced the Model Context Protocol on November 25, 2024, as an open standard for connecting AI assistants to the systems where data lives. The official docs compare it to a USB-C port for AI applications: one shape of connector, many devices.
The host is the AI application (Claude, ChatGPT, VS Code or your own agent), which opens one client connection per server. The server is the program that exposes your system. According to the MCP architecture overview, a server can offer three things:
- Tools: functions the agent can call to take an action, such as "create_ticket" or "run_saved_query".
- Resources: data the agent can read for context, such as a schema or a document.
- Prompts: reusable templates that help the model use the tools well.
Servers run locally over stdio or remotely over Streamable HTTP. For an enterprise the remote server matters most, because it serves many users behind your identity provider, and MCP recommends OAuth for its tokens.
Support is broad now. The MCP site lists Claude, ChatGPT, Visual Studio Code and Cursor as clients. OpenAI's docs show MCP servers used from ChatGPT and as a tool in the Responses API. Microsoft's Copilot Studio documentation says it currently supports MCP tools and resources. Salesforce announced a native MCP client for Agentforce in its Agentforce 3 release on June 23, 2025. Build one good server per system and every approved agent can use it.
Next question: What does it take to build a custom MCP server for our stack?
Which internal systems to expose first
Start where agents save real hours and a wrong call is cheap to undo. Read before write, one system at a time:
- Internal docs and wikis (read only). Policies, runbooks, specs. High value, and the risk maps to page permissions you already have.
- Ticketing (read, then narrow writes). Search and summarize first, then comments and status changes on a few projects. No deletes or bulk edits.
- CRM (read, then scoped writes). Account lookups and activity logging come first. Field updates come later, with the agent acting as the signed-in user so sharing rules apply.
- Data warehouse (curated views only). No raw SQL against production schemas. Expose named, parameterized queries over approved views, with row limits. A senior data engineer should own which views exist.
Leave payments, HR records and access changes for last, with human approval on every write.
Next question: How do you connect AI agents to a CRM and data warehouse?
Build your own or use a vendor-hosted MCP server
Vendors such as Sentry now run their own remote MCP servers, and Anthropic shared pre-built servers for systems such as GitHub and Postgres at launch. That changes the question from "how do we connect" to "whose code sits between our agents and our data". Use this as a rule of thumb:
A common middle path: vendor servers for read access to standard tools, plus a thin internal server for business actions such as "escalate a priority-one ticket". Business-level tools are easier for a model to pick and easier to secure than fifty generic endpoints.
Next question: Where do you find engineers who have built MCP servers?
Authentication and least-privilege scopes for an enterprise MCP server
An MCP server carries the permissions of every tool it exposes. Treat it like any production API that acts on behalf of users.
The official MCP security best practices are blunt on two points. First, token passthrough is forbidden: MCP servers must not accept any tokens that were not explicitly issued for the MCP server. Your server validates its own tokens, then gets separate credentials for the downstream system. Second, scopes should be minimal. Its list of common mistakes includes wildcard scopes such as "all" or "full-access" and bundling unrelated privileges to avoid future prompts.
- Sign in through your identity provider with SSO.
- Act as the user, not as a service account, wherever the downstream system supports it, so existing permissions and sharing rules still apply.
- Start with read scopes. Request write scopes only when a write tool is first used, and log each step-up.
- Keep humans on consequential writes. OpenAI's MCP docs advise keeping approval enabled for tools that can modify data or take other consequential actions.
- Control which servers people can add. The VS Code docs note that an organization can restrict which servers are available. Keep an approved list and block the rest.
Next question: Can we add a senior security engineer to review agent access?
Logging, rate limits and audit
When an agent does something odd at 2 a.m., you need to know which user, agent, tool call and arguments.
- Log every tool call with user identity, client identity, tool name, arguments (with secrets and personal data masked), result status and latency. MCP requests carry client identity in their metadata.
- Use correlation IDs from agent to downstream API.
- Rate limit per user and per tool, so a looping agent hits a ceiling before your CRM's API quota does.
- Cap result sizes. Large responses cost tokens and expose more data than the task needs.
- Send logs to your existing stack. The current MCP docs point new implementations to OpenTelemetry.
Next question: Can we add a senior SRE to run monitoring and on-call?
Test tools before agents call them
A tool is only as good as its name, description and input schema, because that is all the model sees. Test in three layers.
- Contract tests. Use the official MCP Inspector, which runs in the browser, as a terminal UI or as a CLI. The CLI mode can list tools and call them with arguments, so you can run it in CI on every change.
- Permission tests. Call each tool as a low-privilege user and confirm it refuses what that user cannot do in the source system. Include expired and wrong-audience tokens.
- Agent evaluations. Give a real agent realistic tasks in staging and check it picks the right tool and stops when it should. Include hostile inputs, such as a ticket telling the agent to export the customer list. See our AI agent testing approach.
Next question: How do you test an AI agent before it reaches production?
Who owns MCP servers on your team
MCP servers fail quietly when nobody owns them: an API changes, a description goes stale, and agents make poor choices with no error to page anyone. A workable split:
- Platform team owns the shared pieces: hosting, identity integration, logging, rate limits, the approved server list and the deployment pipeline.
- The team that owns each system owns its server's tools. The CRM team owns the CRM tools, the data team owns the warehouse tools. They know what a safe action looks like.
- Security reviews every new tool that writes data, and every scope change.
- One named engineer per server is on call for it, with the server listed in your service catalog like any other production service.
If your platform team is already full for Q1, this is where a dedicated forward-deployed engineering pod can stand up the first servers and the shared plumbing, then hand them over.
Next question: What does a forward-deployed AI pod team do?
Checklist: before you ship an internal MCP server
If any item is a "no", fix it or narrow the scope before a production agent connects.
- The server has a named owner, an on-call path and an entry in the service catalog.
- Every tool maps to one business action, with a clear name, a specific description and a strict input schema.
- Users sign in through SSO; the server validates that every token was issued for it and never passes client tokens downstream.
- Tools act as the signed-in user where the downstream system allows it, so existing permissions apply.
- Initial scopes are read only; write scopes are requested only when needed, and each step-up is logged.
- Writes that change money, access, customer records or production systems require human approval.
- Warehouse access goes through curated views and parameterized queries with row limits, never free-form SQL.
- Every call is logged with user, client, tool, masked arguments, result and latency, and the logs land in your existing monitoring stack.
- Rate limits exist per user and per tool, and result sizes are capped.
- Contract tests run in CI with the MCP Inspector CLI, and permission tests cover low-privilege users and wrong-audience tokens.
- An agent evaluation set, including prompt-injection cases, passes in staging with fake data.
- There is a kill switch to disable one tool, or the whole server, in minutes.
Next question: What does it cost to hire an AI engineer?
How Ryz can help
Ryz AI pod teams are senior engineers who build agent systems inside your cloud and repos, alongside your team, and our MCP server development work covers the full path above: scoped tools, SSO, logging, tests and handover. Pods have shipped production AI such as a marketing-compliance system that reviews 8,000+ documents and a driver-support agent covering about 218,000 calls a year in three languages. If you would rather grow your own team, you can hire MCP developers from the top 1% of engineers we interview, working US business hours and reporting to your leads. You own all code and IP.
FAQ
Is MCP only for Claude?
No. Anthropic introduced it, but it is an open protocol. The MCP site lists ChatGPT, Visual Studio Code and Cursor among supported clients, Microsoft Copilot Studio supports MCP tools and resources, and Salesforce announced a native MCP client for Agentforce in June 2025.
Do we need an MCP server if our agent already calls our APIs directly?
Not on day one. MCP pays off when several agents or AI tools need the same systems, because you build and secure the integration once. One agent and one API can use direct calls.
What is the biggest security mistake with an enterprise MCP server?
Broad credentials. One wide-scope service account shared by every agent turns a stolen token or a confused agent into access to everything. Per-user auth, minimal scopes and no token passthrough prevent most of that.
How long does a first internal MCP server take to build?
A read-only server over one well-documented system is a modest project for a senior engineer. Most of the time goes into scoping, auth, logging and tests, not protocol code.
