The short version
Model Context Protocol, or MCP, is a standard way for an AI application to discover and use external data and tools. That can reduce one-off integration work, but it does not make the connected systems safe by default. The protocol standardizes communication; your organization still owns identity, authorization, data handling, review, and operations.
The right first deployment is narrow and boring: one trusted server, one read-only workflow, one user group, and an audit trail. This playbook explains what MCP changes, what it does not change, and the gates an enterprise should require before expanding access or enabling write actions.
01What does MCP actually standardize?#
MCP standardizes how an AI client discovers capabilities and exchanges context with a server. A server can expose resources for context and tools that perform actions. MCP does not replace the source system's API, identity provider, access rules, or audit controls; it creates another governed path to them.
| MCP provides | The enterprise still owns |
|---|---|
| A common client-server protocol | Which servers and clients are approved |
| Capability and tool discovery | Whether each capability should be exposed |
| Structured requests and responses | Data classification and retention |
| Authorization patterns for remote servers | Identity, scopes, access reviews, and offboarding |
| A route to invoke tools | Approval, audit, recovery, and accountability for actions |
Do not describe MCP as a universal data layer. It is an integration protocol operating across systems that keep their own contracts, permissions, and failure modes.
02When is MCP a better choice than a direct integration?#
MCP is useful when several approved AI clients need the same governed capability, when tools need to be discoverable at runtime, or when a reusable server can replace repeated client-specific adapters. A direct integration may remain simpler for one fixed workflow, one application, and a small stable API surface.
| Favor MCP | Favor a direct integration |
|---|---|
| Several AI clients need the same capability | One application owns one fixed workflow |
| Capabilities need a shared governance boundary | The existing API gateway already provides the needed boundary |
| Tools or resources change independently of clients | The contract is small, stable, and explicitly coded |
| The organization can operate the server | No team can own monitoring, updates, and incident response |
03What risks change when an AI system can call tools?#
The system can now combine untrusted content, model interpretation, credentials, and real actions. Prompt injection can arrive through retrieved material, a compromised server can change tool behavior, excessive scopes increase the blast radius, and chained tools can move data or take actions in ways no single integration review anticipated.
- Prompt injection in documents, webpages, messages, or tool output
- Malicious or changed tool descriptions that steer model behavior
- Tokens accepted by the wrong service or passed through to downstream systems
- Overbroad access that exposes more data or actions than the workflow requires
- Write actions that execute before a person understands the consequence
- Cross-tool chains that turn a low-risk read into a high-risk disclosure or action
- Insufficient logs to reconstruct what the user, model, server, and source system each did
The control objective is not to make the model perfectly obedient. It is to keep the system safe when the model is mistaken, manipulated, or uncertain. Permissions and approval gates must live outside the model's prose instructions.
04What should the enterprise approval gate require?#
Require a named owner, documented data flows, trusted code and hosting, least-privilege scopes, user-level authorization, action-level controls, test evidence, logs, and a shutdown path. Review the exact tools and schemas rather than approving a server name in the abstract, because capability changes can change risk.
Owner
Name the team responsible for code, credentials, support, changes, and incidents.
Inventory
Record every resource, tool, input, output, downstream system, and data class.
Authorize
Use user-level identity, narrow scopes, audience-bound tokens, and tested offboarding.
Constrain
Separate read and write tools, disable unused actions, and require approval for consequential changes.
Test
Exercise prompt injection, malformed input, permission failure, server changes, and source-system outages.
Observe
Log discovery, calls, approvals, errors, identity, and resulting source-system changes.
Recover
Document how to revoke credentials, disable the server, undo actions, and notify affected owners.
05What should a safe first MCP deployment look like?#
Start with a read-only retrieval task on non-sensitive or already-approved internal information. Limit access to a small group, expose only the two or three capabilities the task needs, and compare the result with the existing process. Add write access only after the read path is stable and the approval and recovery controls have been tested.
| Phase | Exit condition |
|---|---|
| 1. Local test | Known inputs and adversarial cases produce bounded, logged behavior |
| 2. Read-only pilot | A small group retrieves approved information without expanding access |
| 3. Limited action | One reversible write action has explicit confirmation and source-system audit |
| 4. Production | Owner, support, monitoring, access review, change review, and incident response are active |
A successful prototype proves that the connection works. A production deployment proves that the organization can control, observe, update, and stop it.
06How should teams measure whether MCP is worth operating?#
Measure the workflow improvement after review, not the number of connected tools. Track completion time, retrieval quality, error and denial rates, human approvals, incidents, and operating cost. Compare MCP with the direct integration or manual process it replaces, including security review and maintenance time.
- Time from user intent to a verified result
- Percentage of requests completed without manual rework
- Permission denials and attempted out-of-scope actions
- Approval rate and cancellation rate for write actions
- Errors caused by tool, schema, or server changes
- Time to revoke access or disable a faulty capability
- Engineering and security time required to operate the server
Questions people ask#
- Does MCP make an integration secure?
- No. MCP provides protocol and authorization patterns, while the implementation still needs trusted software, least privilege, token validation, input and output handling, action controls, logs, and operational ownership.
- Should employees install public MCP servers themselves?
- Not for company systems or data unless policy explicitly permits it. Treat a server as executable integration software with access to data and actions, not as a harmless prompt add-on.
- Should the first server support write actions?
- Usually not. Start with read-only access and establish identity, scope, logging, change review, and incident response first. Add one reversible write action with explicit confirmation when those controls work.
- Can one service account be shared by every user?
- Avoid it when user-level authorization is possible. Shared credentials obscure who accessed what, complicate offboarding, and often grant every user the service account's full reach.
- How should server updates be handled?
- Treat tool names, descriptions, schemas, scopes, and downstream behavior as controlled changes. Review the diff, re-run tests, keep new actions disabled by default, and preserve a rollback path.
Sources#
- 01Model Context Protocol
Anthropic
Anthropic's official overview of MCP as a standard for connecting AI applications to external data sources and tools.
- 02Security Best Practices
Model Context Protocol
The protocol project's guidance on session security, token handling, least privilege, prompt injection, and dangerous tool execution.
- 03Authorization
Model Context Protocol
Normative requirements for OAuth-based authorization, audience-bound tokens, PKCE, secure redirects, and token storage.
- 04Developer mode and MCP apps in ChatGPT
OpenAI
Current enterprise controls for testing, publishing, role-based access, action selection, change review, confirmations, and private-network connectivity.
- 05Understanding prompt injections
OpenAI
Official explanation of indirect prompt injection through third-party content and the need for layered technical defenses.
Free canvas
The AI Operating Model Canvas
One page for deciding who owns what: where AI work is funded, who approves it, how it gets evaluated, and what the escalation path is when it goes wrong.
Open the companion toolThe timely half
What I'm seeing this week, by email.
By subscribing you agree to Substack's Terms of Use, their Privacy Policy, and their Information Collection Notice.
Playbooks stay current. The newsletter tells you what changed. Free.