The implementation path
Discover
Choose a narrow user job
Contract
Design tools and results
Guard
Map identity and risk
Prove
Test real and hostile prompts
Operate
Observe, support, and improve
1. Define the first user job
Write the request in the language a real person would use, identify the outcome they need, and state where automation must stop. “Connect Salesforce” is a technology task. “Prepare an account brief from CRM, billing, and support, without changing any records” is an implementable user job.
Scope template
When this user asks for this outcome, use these systems, stop before this side effect, and return this evidence.
2. Identify systems of record
For every fact and action, name the authoritative system. Review its API, authentication, rate limits, permission model, event behavior, data residency, and operational owner. If a system lacks a stable interface, MCP does not remove that integration problem—it gives the eventual adapter a standard outward face.
3. Choose the deployment boundary
| Pattern | Fits when | Questions to resolve |
|---|---|---|
| Local process | Capabilities live on one machine: files, local software, development tools. | Publisher trust, process privileges, sandboxing, update path, secret exposure. |
| Internal remote service | Employees need shared access to company systems. | Network path, identity propagation, tenant/workspace policy, availability, support ownership. |
| Public remote service | Customers connect from supported third-party AI hosts. | OAuth, client compatibility, tenant isolation, abuse controls, product terms, incident response. |
| Hosted provider | The organization wants an operator to own runtime, updates, and monitoring. | Data handling, credentials, portability, logs, SLAs, exit plan, responsibility split. |
4. Map identity and permissions before tools
Decide whether calls use the person’s downstream identity, a delegated token, or a service account. Derive tenant and user scope from verified authorization—not model-supplied parameters. Define which roles may discover each capability, which may call it, and which actions require a new confirmation or step-up scope.
5. Design a small, coherent tool surface
Start from user intent instead of mirroring every API endpoint. Separate reads from writes, and split tools when permissions or side effects differ materially. Give every tool an explicit input schema, compact structured result, stable identifiers, and accurate risk annotations.
Read the complete tool-design guide →6. Define results, errors, and state
Return only what the model needs for the next decision. Use output schemas for predictable structured data, pagination for lists, source IDs for traceability, and actionable tool errors that let the model correct missing or invalid arguments.
Do not hide important workflow state inside a server session. Return explicit opaque handles for prepared actions or long-running work, authorize every later use, document expiry, and make retries safe. Compatibility matters while hosts adopt newer stateless protocol revisions at different speeds.
7. Add approvals at the consequence boundary
A confirmation should describe the actual effect: recipient, destination, amount, record, visibility, and reversibility. Avoid a generic “Allow tool?” dialog when the user needs to understand what will happen.
Weak approval
Allow send_message?
Useful approval
Send this reply to Maya Chen at Acme and mark ticket #1842 resolved?
8. Build observability for both calls and selection
Record which tools were available, surfaced, selected, approved, denied, called, retried, and failed. Include user and tenant identity, server version, sanitized arguments, result size, latency, downstream correlation ID, and side-effect status. Keep credentials and sensitive payloads out of logs.
9. Test the behavior, not only the endpoint
The request names the exact action.
The request implies a goal in ordinary language.
The correct behavior is to use no tool.
Two records match; the assistant must ask.
The user lacks access to a tool or record.
A document attempts prompt injection.
A downstream call times out after a partial write.
The same approved action is requested twice.
The host must find a tool in a large catalog.
Use the official MCP Inspector for protocol and schema behavior, then test inside every target host. A server that passes protocol tests can still have poor tool selection, confusing approvals, oversized results, or unsupported optional features.
10. Pilot narrowly and expand from evidence
Launch with a limited group, read-only capabilities where practical, clear support ownership, and an easy disable path. Review real prompts, denied requests, false tool selections, result quality, approval abandonment, and operator incidents before adding more tools.
Build, adopt, or buy?
| Question | Likely direction |
|---|---|
| A trusted connector already covers the job and required controls? | Adopt it; verify behavior and permissions rather than rebuilding. |
| The workflow depends on proprietary business logic or several internal systems? | Build a focused internal or customer-facing MCP server. |
| The API is stable but the team does not want to operate auth, hosting, and monitoring? | Consider a hosted implementation with clear ownership and portability terms. |
| The job is fixed, deterministic, and has only one caller? | A conventional integration or automation may be simpler than MCP. |
Definition of ready
A person can predict what the AI may access, what it may change, when it will ask, and where the evidence will be.
That is a more useful launch standard than “the server connects.”
Implementation guidance draws from the official server guide, MCP Inspector, OpenAI tool-design guidance, and MCP security best practices.