· Pair with term definitions while reading.
Model Context Protocol — architecture
The following is a conceptual map aligned with how MCP is described in public documentation. Method names, transport details, and versioning rules can change between specification releases; always verify against the current specification.
Roles
An MCP host is typically the application that runs or orchestrates the model session (for example an IDE, desktop agent, or custom runtime). The host establishes one or more connections to MCP servers, which encapsulate integrations: databases, ticketing systems, browsers, local filesystem adapters, and so on. The host exposes model-side capabilities to the protocol layer; servers expose integration-side capabilities. Exact lifecycle and permission UX are host-defined; the protocol specifies the message surface between them.
Core primitives
MCP organizes extensibility into a small set of first-class primitives (terminology per specification):
- Tools — model-invokable actions with typed inputs/outputs (e.g. “create issue”, “run query”). These imply side effects or computation outside the model weights.
- Resources — addressable content the model or user can read (files, URLs, entity records), often with URIs analogous to openable documents.
- Prompts — reusable templates or workflows packaged by the server for structured interaction, distinct from ad hoc user chat text.
Servers advertise supported primitives during capability negotiation; hosts decide what is surfaced to the model and under which consent or policy gates.
Transports and messaging
MCP communication is framed for bidirectional client–server messaging. In practice you will see transports such as stdio (subprocess pipes, common for local CLI servers) and HTTP-based streaming variants for remote deployments. The wire format builds on JSON-RPC–style request/response and notification patterns; servers may stream incremental results where the spec allows. Consult the transport chapter of the specification for normative requirements, including authentication and session lifecycle for remote transports.
| Deployment feel | Typical transport pattern | Engineering notes |
|---|---|---|
| Local dev / IDE | stdio subprocess pipes | Fast loop; server inherits OS privileges of the spawned process—harden secrets. |
| Remote / shared service | HTTP-based streaming (per current spec) | Plan for TLS, auth, session rotation, and rate limits like any public API. |
Security posture (non-normative)
From a threat-modeling perspective, an MCP server often executes with the privileges of the host process or its child OS user. Malicious or vulnerable servers can exfiltrate API keys, read accessible files, or invoke dangerous tools. Operators should pin dependencies, review server source, isolate secrets with least privilege, and apply network egress controls for remote integrations. This paragraph summarizes conventional engineering practice; it is not part of the MCP standard text.
Related pages
- FAQ — comparisons and misconceptions
- Glossary — MCP vocabulary
- Resources — specification and documentation links
If you are building the surface around MCP—landing pages, docs, or deployment—25web.tech carries adjacent engineering notes. For readers who first want the vocabulary of “app” itself, whatisanapp.org mirrors this site’s explainer style on that question.