Model Context Protocol (MCP) standardizes a boundary that every tool-using AI system otherwise has to invent: how an application describes available capabilities, connects to them, invokes them, returns results, and keeps the user in control. It does not define one model, vendor, programming language, or database.
That distinction matters. MCP is not a directory of every AI tool, an automatic agent, or a security sandbox. It is a protocol. Implementations can use it to connect a coding assistant to a repository service, a support agent to a ticket system, or a desktop application to local files without designing a new integration format for every pairing.
The host-client-server architecture
The official architecture separates three roles. The names can sound interchangeable at first, but each has a different responsibility:
| Role | What it owns | Typical responsibilities |
|---|---|---|
| MCP host | The user-facing AI application | Model integration, consent, authorization decisions, context aggregation, policy, and the overall user experience. |
| MCP client | One stateful connection to one server | Initialization, protocol negotiation, request routing, notifications, subscriptions, and connection isolation. |
| MCP server | A focused set of external capabilities | Exposing tools, resources, and prompts while respecting the permissions and security boundary of that server. |
A host can connect to several servers, but it creates a separate client instance for each one. That one-to-one client-server relationship helps keep sessions and security boundaries distinct. A repository server does not automatically gain access to the credentials or data of a database server just because the same host uses both.
What happens during an MCP connection
- The host selects and starts a connection. A local server may run as a child process; a remote server may already be available over HTTPS.
- Client and server initialize the session. They exchange protocol versions, implementation information, and declared capabilities.
- The host discovers supported primitives. Depending on negotiated capabilities, it can list tools, resources, or prompts.
- The user or model requests an operation. The host applies its permission and confirmation policy before forwarding a valid protocol request.
- The server returns a result or an error. Results may be structured or unstructured and can include text, images, audio, or resource links where the specification allows them.
- Notifications keep state current. Implementations can announce list changes, progress, cancellation, and other negotiated events.
Capability negotiation is important because MCP evolves. A client should not assume that every server implements every optional feature, and a server should not send a request the client never declared it can handle.
Tools, resources, and prompts are not the same thing
Tools: operations the model can invoke
An MCP tool has a name, a human-readable description, and an input schema. It may also declare an output schema and behavior annotations. A tool can query a service, create an issue, inspect a file, or perform another operation.
Tool descriptions and annotations help the host present choices, but the current specification says clients must treat annotations as untrusted unless they come from a trusted server. A label such as “read-only” is not proof that an unknown implementation has no side effects.
Resources: context the application can read
Resources represent data that can enter the model's context: a document, database schema, repository file, application state, or another addressable item. Servers can expose individual resources and URI templates, and may support subscriptions when content changes.
A resource is not simply a tool with no arguments. It expresses contextual data that the application can discover and read, while a tool expresses an operation the model can request.
Prompts: reusable interaction templates
Prompts are server-provided message templates or workflows, often with arguments. They are generally user-controlled: an interface might show “Review this pull request” or “Summarize this incident” as a reusable action. The host obtains the resulting messages and decides how to present or use them.
Client features: requests that travel the other way
MCP also defines capabilities that a server can request from the client when negotiated, including model sampling, user elicitation, and logging. This does not give a server unlimited access to the host's model or user. The host remains responsible for policy, consent, and what information crosses the boundary.
Local stdio and remote Streamable HTTP
The data layer uses JSON-RPC 2.0 messages. The transport layer determines how those messages travel:
- stdio connects local processes through standard input and output. It is direct and has no network transport overhead. Protocol messages must own stdout; diagnostic logs belong on stderr so they do not corrupt the stream.
- Streamable HTTP uses HTTP POST for client-to-server messages and can use Server-Sent Events for streaming. It fits remote services and requires the normal disciplines of HTTPS, origin validation, authentication where needed, and hardened session handling.
“Local” and “safe” are not synonyms. A local process runs with some operating-system identity and can still access valuable files or execute dangerous operations. “Remote” does not automatically mean public; a remote server may be private and strongly authorized.
MCP security: the protocol is not the sandbox
MCP can make boundaries explicit, but it cannot guarantee that every server, tool, input, or returned document is trustworthy. A production design should apply several layers:
- Informed consent. Explain what data will be read, what action will occur, and where information will be sent.
- Least privilege. Expose the smallest useful capability set and grant only the scopes, files, network access, or accounts required.
- Per-operation policy. A connection approval is not blanket authorization for every future destructive or external action.
- Input and output validation. Validate tool arguments against the schema and treat server output as untrusted data, especially before feeding it to another server.
- Credential isolation. Keep tokens out of model context and logs. For remote authorization, validate the token audience and never pass a client token unchanged to an upstream API.
- Prompt-injection defenses. A document returned as a resource can contain hostile instructions. Content does not become trusted merely because it arrived through MCP.
- Runtime containment. Use operating-system permissions, sandboxes, network controls, timeouts, resource limits, and auditing according to the risk.
For HTTP-based authorization, the current MCP specification builds on OAuth standards and protected resource metadata. Exact requirements change as the specification advances, so implementers should use the current authorization document and maintained libraries rather than copy an old flow into custom code.
When should you use MCP?
MCP is attractive when an AI host needs to discover capabilities from multiple independently maintained servers, present a consistent integration experience, or connect to remote services using a standard protocol. It is also useful when tools, resources, prompts, notifications, and lifecycle negotiation belong together.
A direct API may be simpler when one application controls both sides and already has a stable typed client. A command-line interface may be the smallest boundary for local automation when the agent already has a terminal. The choices can also compose: an MCP server may call an API or wrap a carefully selected CLI.
Our detailed MCP vs CLI vs API comparison examines discovery, transport, permissions, portability, and operational cost. The short version is that an interface should match the boundary you actually need, not the acronym with the most attention.
Where QZX fits
QZX (Quick Zap Exchange) is currently a CLI, not an MCP server. Terminal-capable agents can discover QZX commands, invoke them as processes, and request structured JSON. Every public command is designed to return at least success and message, plus domain fields.
An MCP adapter could expose a selected subset of QZX commands as tools. A responsible adapter would not publish all commands blindly. It would map explicit input schemas, preserve JSON results, retain approval and backup requirements, isolate privileges, and clearly distinguish read-only operations from mutations.
Agent host
└─ MCP client
└─ focused MCP server
└─ selected QZX command --jsonThat composition can be useful, but it adds another process and policy boundary. When a host already has a terminal and a documented QZX command matches the task, direct CLI use may remain the more economical option.
A practical evaluation checklist
- Is the server maintained by a party you trust, and can you inspect what it exposes?
- Are its tools, resources, and prompts focused rather than unnecessarily broad?
- Does the host show clear consent for data access and consequential actions?
- Are tokens, files, network destinations, and operating-system privileges limited?
- Does the implementation use current MCP libraries and the current specification?
- Can you test failure, timeout, cancellation, malformed output, and partial side effects?
- Would a direct API or CLI solve the same problem with fewer moving parts?
Frequently asked questions
What is Model Context Protocol?
Model Context Protocol, or MCP, is an open protocol that standardizes how AI applications connect to external tools, data resources, and reusable prompts through client-server sessions.
What is the difference between an MCP host, client, and server?
The host owns the AI experience and policy. It creates one client for each stateful server connection. The server exposes a focused set of external capabilities.
What are tools, resources, and prompts in MCP?
Tools are operations the model can invoke, resources supply contextual data, and prompts are reusable message templates or workflows presented through the host.
Which transports does MCP use?
The current architecture documents stdio for direct local process communication and Streamable HTTP for remote or networked communication, with optional Server-Sent Events for streaming.
Does MCP make AI tools safe automatically?
No. MCP is an interface, not a sandbox. Consent, least privilege, authorization, validation, isolation, secure credentials, and prompt-injection defenses still belong to the implementation.
Is QZX an MCP server?
No. QZX is currently a CLI. An MCP server could wrap selected QZX commands, but it would need to preserve their validation, permissions, safety, and structured result contracts.