An MCP server gives an AI application a standardized interface to specific data and operations. It can expose a document, describe an available tool, and receive a request to run that tool. The host application still chooses what to expose to the model, how to manage context, when to seek approval, and how to present the result.
Connecting a server therefore adds capabilities, not an automatic guarantee of intelligence, authorization, or correct behavior.
This walkthrough uses the MCP specification revision 2026-07-28, checked on October 28, 2026. That matters: older tutorials often begin with an initialize handshake, while this revision uses self-contained requests and optional discovery.
Locate the host, client, and server
Suppose you want a coding application to check the status of a build in your team's build service.
The host is the AI application you interact with. It manages the conversation and decides which integrations are available.
An MCP client is the component inside that host that communicates with one server. The host may manage several clients, each connected to a different server.
The server is a program exposing the build service through MCP. It receives protocol requests, checks access, calls the underlying service, and returns results.
Those roles come from the MCP architecture overview. They describe responsibilities, not necessarily separate machines. A server can run as a local process or be reached remotely.
The underlying build system is another component. MCP does not replace its database, job scheduler, permissions, or definition of a successful build.
Understand the capabilities a server can expose
MCP provides several ways to make an integration useful:
| Primitive | In the build-service example | Purpose |
|---|---|---|
| Tool | get_build_status(build_id) |
Request an operation with defined arguments |
| Resource | A build-policy document or service schema | Provide information the application can read |
| Prompt | A reusable build-investigation template | Supply a prepared interaction pattern |
The server concepts guide explains these primitives and their discovery methods. A server need not expose all three.
A read-only lookup can be a tool; “tool” does not automatically mean a write. Conversely, a tool may publish a package or cancel a build. Inspect its actual contract and the access it receives.
The prompt primitive also does not imply that text from a server outranks the user's instructions. A host must handle external material according to its trust and authorization design.
Follow a discovery and call sequence
Here is a conceptual sequence for the synthetic build integration:
- The host selects a configured server and the credentials or local process environment allowed for it.
- Its client optionally calls
server/discoverto learn supported versions and capabilities. - The client sends
tools/listand receives the build-status tool definition. - The host makes the relevant tool available to the model.
- The model proposes a call for a particular build, and the host applies its policy.
- The client sends
tools/call; the server checks access and queries the build system. - The server returns the result, which the host can show to the model and user.
This sequence is illustrative. It is not a recorded connection to a real build service.
In revision 2026-07-28, requests declare the protocol version and client capabilities in _meta; client identity can also be supplied. The versioning and compatibility specification explains that there is no required initialization handshake for this revision. Servers must implement discovery, but clients do not have to call it before every operation.
An illustrative JSON-RPC call over a stdio connection is:
{
"jsonrpc": "2.0",
"id": 3,
"method": "tools/call",
"params": {
"name": "get_build_status",
"arguments": {"build_id": "build-42"},
"_meta": {
"io.modelcontextprotocol/protocolVersion": "2026-07-28",
"io.modelcontextprotocol/clientInfo": {
"name": "example-host",
"version": "1.0.0"
},
"io.modelcontextprotocol/clientCapabilities": {}
}
}
}
The id correlates the response with this protocol request. build_id identifies the build in the application. Confusing the two would make logs and recovery difficult.
A possible result is:
{
"jsonrpc": "2.0",
"id": 3,
"result": {
"resultType": "complete",
"content": [
{"type": "text", "text": "Build build-42 passed."}
],
"structuredContent": {
"build_id": "build-42",
"status": "passed"
},
"isError": false
}
}
The tools specification defines tool discovery, calls, and structured results. The fields inside this example's structuredContent are the build tool's application contract, not universal MCP fields.
Discovery describes capability, not trust
A tool definition can tell the application what arguments the server expects. It cannot prove that the server implements the description honestly or that the requested action is authorized.
The host must know which server it is connecting to and what access is appropriate. The server must authorize access to the requested build. The build service remains responsible for its own enforcement.
If the tool later expands from reading status to canceling builds, that is a material capability change. Reusing the same connection does not make the new effect equivalent to the old one.
Likewise, a successful protocol exchange is not proof of a successful business operation. The returned result could indicate a tool error, a partial application outcome, or an operation still needing input. The caller needs to interpret the actual result rather than treating receipt of JSON as success.
Local and remote transports change the operating boundary
The architecture documentation describes stdio for communication with a local process and Streamable HTTP for network communication. The protocol's structured messages are part of both, but process launch, networking, credentials, and deployment differ.
A local server can have substantial access through the environment in which it runs. “Local” is not a synonym for sandboxed. A remote server introduces network and identity considerations and may serve many clients.
The 2026-07-28 release announcement also describes HTTP routing headers and the removal of protocol-level sessions in the new revision. The JSON example above deliberately shows a stdio message; it is not a complete HTTP request.
Application state can still exist. A build server obviously remembers builds even if each protocol request is self-contained. “Stateless protocol” describes the exchange model, not the elimination of storage from every connected application.
Check compatibility instead of assuming it
Older MCP revisions use different lifecycle behavior. A client or server may support one revision or several, and optional extensions require their own support. A product advertising “MCP support” does not establish that every feature in this article works in that product.
Before adopting an integration, identify the actual client, server, SDK versions, supported protocol revisions, transport, and required capabilities. Test the specific discovery and call path you need. Include a failure case, such as an unknown build or denied access, and inspect how the host communicates it.
MCP is useful when a common interface reduces integration-specific work. The application still needs good tools, relevant context, access control, and verification. Those responsibilities become easier to locate once the protocol boundary is clear.
Research note: this is a documentary walkthrough of MCP 2026-07-28, reviewed October 28, 2026. The build tool and messages are synthetic; no server connection, SDK conformance test, or product compatibility claim is reported.
