Definition
An MCP server is the component that exposes tools, resources, prompts, or other context to an MCP-compatible client.
The server tells the client what capabilities are available, what arguments each tool expects, and how a tool call should be handled. In a small prototype, the server may directly wrap one local script, one filesystem operation, or one API call.
In production, the server is more than an adapter. It becomes the trusted place where credentials, source boundaries, validation, rate limits, failures, and audit logs are handled before an AI-requested action reaches a real system.
How an MCP client talks to a server
The server participates in a lifecycle: initialize, advertise capabilities, list tools or resources, then handle requests.
An MCP host such as an AI desktop app, IDE, or internal agent runtime creates an MCP client connection to one or more servers. Each connection lets the host discover what the server can provide and decide which capability is relevant for the user's task.
For tools, the practical flow is simple: the client asks for the tool catalog, receives names, descriptions, and schemas, then sends a structured call when the model chooses a tool. The server still decides whether that call is allowed.
Simplified server capability shape
json{
"server": {
"name": "orders-mcp-server",
"capabilities": {
"tools": true,
"resources": true,
"prompts": false
}
},
"tools": [
{
"name": "search_orders",
"description": "Search approved order fields by customer, status, or date range.",
"inputSchema": {
"type": "object",
"properties": {
"customerId": { "type": "string" },
"status": { "type": "string" },
"limit": { "type": "integer", "maximum": 50 }
},
"required": ["customerId"]
}
}
]
}What an MCP server can expose
A server can expose more than executable tools, although tools are usually the most visible part of MCP.
| Primitive | Purpose | Production note |
|---|---|---|
| Tools | Executable capabilities the client can request. | Validate identity, scope, arguments, and action policy before execution. |
| Resources | Context data the client can read. | Keep resources scoped and avoid exposing sensitive records by default. |
| Prompts | Reusable interaction templates. | Treat prompts as guidance, not as a security control. |
| Notifications | Signals that available capabilities or state changed. | Useful when published tools can change without restarting the client. |
Local server vs remote server
MCP servers can run locally for developer workflows or remotely for centralized product and security control.
| Server type | Good for | Watch out for |
|---|---|---|
| Local MCP server | Developer tools, local files, test scripts, single-user workflows. | Secrets may end up in local config; distribution and updates can be messy. |
| Remote MCP server | Team tools, SaaS products, shared APIs, governed database access. | Needs authentication, tenant isolation, rate limits, logging, and careful network exposure. |
| Gateway-backed MCP server | Multiple APIs, database scopes, or teams that need repeated controls. | Requires strong source modeling, publication state, and validation rules. |
What an MCP server is responsible for
The server owns the AI-facing contract and the execution boundary.
- Expose a clear tool catalog to MCP clients.
- Write descriptions that help the model choose the right tool without guessing.
- Accept structured tool call arguments and validate them before execution.
- Map tool calls to known upstream operations instead of trusting arbitrary client-provided URLs or SQL.
- Keep upstream credentials, database connection strings, and API secrets server-side.
- Return useful results or errors without leaking stack traces, tokens, or private implementation details.
- Emit logs and metrics that make tool usage auditable.
Security model
An MCP server should not treat the model's requested tool call as permission to execute.
A model can suggest a useful tool call, but the server must enforce policy. That means checking who is calling, whether the tool is published, whether the caller owns the source, whether arguments match the schema, and whether the requested action stays inside the approved scope.
For API-backed tools, the server should map the tool to a known upstream operation and strip unsafe client-supplied headers. For database-backed tools, schema metadata and data execution should be separate, and executor calls should only use published tables and columns.
Custom MCP server vs MCP gateway
A custom MCP server is useful for a narrow job. A gateway is useful when the same controls repeat across many sources.
| Approach | Good for | Watch out for |
|---|---|---|
| Custom MCP server | Small internal tools, one-off adapters, local prototypes. | Auth, logging, validation, credentials, quotas, and tool lifecycle must be redesigned each time. |
| MCP gateway | Multiple APIs, database scopes, teams, customers, or production workflows. | Needs careful source modeling, tenant isolation, publication controls, and conservative validation. |
| Hybrid model | Custom domain tools behind a shared gateway boundary. | Keep the gateway as the enforcement layer and avoid duplicating policy in prompts. |
Production checklist
For production use, an MCP server needs more than a working tool call.
- Authentication is required for every remote MCP connection.
- Tool visibility is controlled by owner, workspace, source, and publication state.
- Input schemas are strict enough to reject unexpected arguments.
- High-risk tools are narrow, logged, and optionally confirmation-gated.
- Credentials are rotated and never returned to clients after save.
- Logs redact sensitive fields while keeping enough context for audit and debugging.
- The team can disable, narrow, or republish tools without changing every client manually.
Common anti-patterns
Most MCP server problems come from exposing too much too early.
| Anti-pattern | Why it is risky | Better pattern |
|---|---|---|
| One broad tool with natural-language instructions | The model can ask for actions that are hard to validate. | Publish narrower tools with structured input schemas. |
| Direct database connection in the client | Local client config becomes the security boundary. | Keep connections server-side and expose scoped metadata and executor tools. |
| Every OpenAPI endpoint becomes a tool | The catalog becomes noisy and may include destructive or irrelevant operations. | Curate a smaller published catalog for AI workflows. |
| Policy hidden in prompt text | Prompt guidance can be ignored or manipulated. | Enforce policy in backend validation before execution. |
Sources and further reading
Common questions
Can one MCP server expose many tools?
Yes. An MCP server can expose a catalog of tools. A gateway can generate and curate that catalog from sources such as OpenAPI documents or database scopes.
Does the MCP server run the tool directly?
Sometimes. It may run a local function, call an upstream API, or route to another executor. In a gateway model, it applies policy before forwarding the call.
Should an MCP server be local or remote?
Local servers are useful for personal developer workflows. Remote servers are better when a team needs shared credentials, centralized policy, tenant isolation, and audit logs.
Is an MCP gateway an MCP server?
It can act as the MCP server endpoint for clients while adding publishing, security, validation, and observability around the tools.
What should never live only in an MCP server prompt?
Security policy should not live only in prompt text. Authentication, authorization, scope checks, argument validation, rate limits, and redaction should be enforced in trusted backend code.