The short answer
Model Context Protocol (MCP) is a standard way for an AI application to connect to external data and actions through a host, one or more clients, and specialized servers. Start with the mental model, choose the right deployment boundary, then add explicit validation, approval, and audit controls before any write-capable workflow reaches production.
MCP in one mental model
An MCP system has three roles:
Role | What it owns | The practical question |
|---|---|---|
Host | The user experience, model access, policy, and overall coordination | What is the user trying to accomplish? |
Client | One session and capability connection inside the host | Which server is allowed to participate, and with what context? |
Server | A bounded set of resources, tools, or prompts | What data or action can this integration expose safely? |
This separation matters because an AI model should not receive unrestricted access to every system behind one connection. A host can create isolated client connections, apply different permissions, and keep one server failure from silently widening another server’s authority.
MCP servers can expose three main primitives. Resources provide context, tools perform actions or retrieval, and prompts package reusable instructions. They can be used together, but they should not be treated as interchangeable. A resource is useful when the application should control what context is attached. A tool is appropriate when the model may request an operation. A prompt is useful when the user should choose a prepared workflow.
Choose a reading path by outcome
Understand the protocol
What Is an MCP Server? Meaning, Architecture, and Examples explains the basic definition and common examples.
MCP Server Architecture: Hosts, Clients, Servers, and Protocol Layers goes deeper on lifecycle, messages, and trust boundaries.
MCP Resources vs Tools vs Prompts helps you choose the right primitive.
Local vs Remote MCP Servers compares deployment and identity trade-offs.
Build and secure a server
How to Build an MCP Server turns the protocol into a production checklist.
MCP Security Checklist for Teams covers approval, scoped identity, input validation, logging, and incident readiness.
Connect MCP to real work
Connect Claude Code to a Shared Workspace focuses on scope precedence and team context.
Connect Codex to a Shared Knowledge Workspace connects repository work with durable team decisions.
Playwright MCP Research Workflow shows a source-to-citation browser workflow.
n8n and MCP separates orchestration from tool access and shared context.
Linear MCP Workflow turns research into reviewable product work.
Local or remote: choose the trust boundary first
A local server is usually the simpler choice when a workflow is tied to one device, uses local files or developer tools, and does not need centralized team operations. The client launches the server as a subprocess, so operating-system permissions and process isolation become part of the security model.
A remote server is usually the better fit when many users need the same capability, identity must be centrally managed, or the service needs shared monitoring and availability. For HTTP-based connections, authentication, authorization, origin validation, session handling, rate limits, and tenant isolation are product requirements—not optional polish.
A hybrid system is common. Device-bound tools can remain local while shared knowledge, CRM, issue tracking, and controlled write-back live behind remote servers. The important design choice is not “local versus remote” in the abstract. It is whether the execution boundary matches the identity, data, and operational boundary.
Build for production, not only for a demo
A production MCP server needs more than a list of callable functions:
Define a narrow capability contract. State what the server can read, what it can change, and what is deliberately outside scope.
Use explicit input schemas. Reject malformed or over-broad requests before they touch downstream systems.
Bind every request to identity and tenant context. Never infer permission from a model instruction.
Separate read and write capabilities. Make consequential actions easy to identify and review.
Design idempotency and recovery. A retry should not duplicate an order, ticket, or publication.
Return actionable errors. The client should know whether to correct input, ask the user, retry, or stop.
Log actor, scope, request, and outcome. Logs must support investigation without leaking secrets.
Test denial paths. Prove that the server rejects wrong tenants, expired credentials, unsupported protocol versions, and unsafe payloads.
Put a human gate before consequential actions
A useful safety pattern is: intent → validation → approval → execution → audit.
Validation checks the schema, requested scope, current state, and policy. Approval shows the person what will change, where it will happen, and which identity will be used. Execution applies the smallest permitted action. Audit records the result and links it back to the user’s decision.
Not every tool call needs a modal dialog. Read-only retrieval can often proceed under a pre-approved scope. A high-impact or irreversible write should usually require fresh confirmation. The approval threshold should be based on consequence, not on whether the model sounds confident.
How a shared workspace changes the workflow
MCP connects systems; it does not automatically create durable team context. A shared workspace adds the layer where people and agents can keep source material, decisions, review status, and reusable outputs together.
In Dokki, an MCP-connected workflow can use the workspace as the canonical knowledge layer while external servers provide bounded access to code, browsers, CRM records, issues, or other systems. The operating model is:
retrieve source evidence through approved tools;
store the evidence and interpretation in a shared artifact;
let people review claims and proposed actions;
execute only the approved step;
record the outcome so the next agent starts from current context.
This reduces a common failure mode: a successful tool call whose rationale and evidence disappear inside a private chat.
MCP evaluation checklist
Before adopting an MCP server, ask:
Does the documentation clearly separate resources, tools, and prompts?
Which protocol revision and transports are supported?
How is authentication handled for local and remote use?
Can permissions be scoped by tenant, user, and action?
Are write-capable tools clearly distinguished from reads?
Which actions require human confirmation?
Are retries idempotent?
Are logs useful without containing secrets?
How are server updates, credential rotation, and revocation handled?
Can the team test failure and denial paths before rollout?
Frequently asked questions
Is MCP an API replacement?
No. MCP is a protocol for connecting AI applications to contextual data and actions. An MCP server often wraps existing APIs, SDKs, databases, or local tools and presents them through a consistent capability model.
Does an MCP server run locally?
It can. The standard supports local stdio connections and remote Streamable HTTP connections. The right choice depends on identity, data location, operational ownership, and team access.
Are MCP tools safe by default?
No tool is safe merely because it uses MCP. Safety depends on authentication, authorization, input validation, tenant isolation, approval design, rate limits, logging, and the downstream system’s controls.
What should I build first?
Start with one narrow, read-only capability that solves a real workflow problem. Add writes only after identity, permissions, idempotency, confirmation, and audit behavior are tested.
What is the difference between an MCP host and client?
The host is the AI application and user experience. A client is the host-side connection that maintains a session with one MCP server and negotiates its capabilities.
Sources
Last verified: July 28, 2026.