Linux Foundation Model Context Protocol Associate

MCP is built on JSON-RPC. You read requests, responses and notifications, follow the initialization handshake, and see how both sides agree on a protocol version and the capabilities they will use.

• JSON-RPC requests, responses and notifications
• Request identifiers and matching replies
• The initialize handshake
• Protocol version and capability negotiation
• Keeping a connection alive and closing it cleanly
• Reading a message trace

You build A hand-written client session against a simple server, annotated message by message.

Three roles share the work. You learn what the host application, each client and each server is responsible for, how a host connects to several servers, and how local and remote transports differ.

• Host, client and server responsibilities
• One client per server connection
• The stdio transport for local servers
• Streamable HTTP for remote servers
• Choosing a transport
• Where the model sits in this picture

You build An architecture diagram of a host connected to three servers, with the transport for each chosen and justified.

Models need to know exactly what a tool accepts and returns. You describe inputs with JSON Schema, return text, images and structured results, and write descriptions that help a model use tools correctly.

• JSON Schema for tool inputs
• Structured output and output schemas
• Content types: text, images and resource links
• Writing tool names and descriptions for a model
• Validating arguments on the server
• Versioning schemas without breaking clients

You build A tool definition with input and output schemas, validated against good and bad calls.

MCP offers a small set of building blocks. Servers expose tools, resources and prompts, and clients can offer sampling, roots and elicitation back. You learn what each is for and who controls it.

• Tools: actions the model can request
• Resources: data the application can read
• Prompts: reusable templates a user selects
• Sampling: a server asking the host for a model completion
• Roots and elicitation
• Who controls each primitive: model, application or user

You build A small server that exposes one tool, one resource and one prompt for the same domain.

A tool call crosses several boundaries. You follow it from discovery through the model’s choice, execution and result, and learn how progress, cancellation, protocol errors and tool errors are reported.

• Listing tools and reacting to list changes
• The model’s choice and the call request
• Results and how they return to the model
• Protocol errors compared with tool execution errors
• Progress updates and cancellation
• Timeouts, retries and idempotent tools

You build A server whose tools report progress and return clear, model-readable errors, with tests for each failure.

A tool call can move data and change systems, so who may do what matters. You identify trust boundaries between user, host, model and server, require consent for risky actions, and treat tool descriptions and results as untrusted input.

• Trust boundaries in an MCP deployment
• User consent and approval for tool calls
• Least privilege for servers and their credentials
• Prompt injection through tool results
• Untrusted servers and tool descriptions
• The confused deputy problem

You build A threat model for a host that connects to one trusted and one untrusted server, with the controls for each risk.

Remote servers need real authentication. You learn how OAuth 2.1 is used with HTTP transports, why tokens must not be passed through blindly, and which limits and checks keep a server safe.

• OAuth 2.1 flows for remote servers
• Scopes and the principle of least privilege
• Why token passthrough is unsafe
• Input validation and output filtering
• Rate limits and resource limits
• Sandboxing local servers

You build A remote server secured with OAuth, with scopes matched to each tool and tests for denied requests.

When an agent acts through tools, someone will ask what happened. You log calls with the context to reconstruct them, trace requests across host, client and server, and keep records that serve both debugging and review.

• What to log for each tool call
• Correlating requests across components
• Traces and metrics for MCP traffic
• Audit trails and retention
• Protocol-level logging
• Spotting abuse from logs

You build A logging and tracing setup that reconstructs any tool call from request to result.

MCP is used where agents need real systems. You survey typical operational uses, see how existing servers and SDKs speed up building, and judge when an integration is portable across hosts.

• Typical use cases: developer tools, data access and workflows
• Reference servers and official SDKs
• Choosing between building a server and using one
• Portability across different hosts
• Versioning and long-term maintenance
• Evaluating a third-party server before adopting it

You build An adoption plan for one internal system, with a build-or-reuse decision and a list of risks.

Design and build an MCP integration for a real workflow. You choose the primitives, write schemas, secure access, log what happens and test failure paths, then explain the design to the people who will rely on it.

• Choosing a workflow and its tools
• Designing primitives and schemas
• Building the server and connecting a host
• Securing, logging and testing it
• Documenting the integration for its users

You build A working MCP server for one real workflow, with a security note and a test suite.