RUNLOCALAIv38
->Will it run?Best GPUCompareTroubleshootStartLearnPulseModelsHardwareToolsBench
Run check
RUNLOCALAI

Independently operated catalog for local-AI hardware and software. Hand-written verdicts. Source-cited claims. Reproducible commands when we have them.

OP·Fredoline Eruo
DIR
  • Models
  • Hardware
  • Tools
  • Benchmarks
TOOLS
  • Will it run?
  • Compare hardware
  • Cost vs cloud
  • Choose my GPU
  • Prompting kits
  • Quick answers
REF
  • All buyer guides
  • Learn local AI
  • Methodology
  • Glossary
  • Errors KB
  • Trust
EDITOR
  • About
  • Author
  • How we make money
  • Editorial policy
  • Contact
LEGAL
  • Privacy
  • Terms
  • Sitemap
MAIL · MONTHLY DIGEST
Get monthly local AI changes
Monthly recap. No spam.
DISCLOSURE

Some links on this site are affiliate links (Amazon Associates and other first-class retailers). When you buy through them, we earn a small commission at no extra cost to you. Affiliate links do not influence our verdicts — there are cards we rate highly that we don't have affiliate relationships with, and cards that sell well that we refuse to recommend. Read more →

© 2026 runlocalai.coIndependently operated
RUNLOCALAI · v38
  1. >
  2. Home
  3. /Learn
  4. /Courses
  5. /MCP Server Implementation
  6. /Ch. 2
MCP Server Implementation

02. MCP Specification Overview

Chapter 2 of 22 · 15 min
KEY INSIGHT

MCP defines a complete lifecycle of connection, capability discovery, and request-response patterns that all implementations must follow. The MCP specification defines a state machine for connections between clients and servers. Understanding this lifecycle is essential before writing any server code. **Connection Initialization:** When an MCP client connects, it sends an `initialize` request containing protocol version information and client capabilities. The server responds with its name, version, and capabilities. This exchange establishes which features both sides support. After initialization, both sides send `initialized` notifications to signal readiness. **Capability Declaration:** Servers declare which features they support in their response. The three capability categories map directly to the three feature types: ```json { "capabilities": { "resources": { "subscribe": true, "listChanged": true }, "tools": {}, "prompts": { "listChanged": true } } } ``` A server declaring `"tools": {}` supports tool operations but not dynamic tool list updates. A server with `"tools": null` does not support tools at all. **Request/Response Pattern:** All operations use JSON-RPC 2.0. Requests include an `id` field for correlation, methods are named with dot notation (`tools/list`, `resources/list`), and responses include either a `result` object or an `error` object. **Notification Pattern:** Some operations do not expect responsesΓÇöthese are notifications. For example, when a resource changes, the server sends a `notifications/changed` message. The client does not respond to notifications. **Error Handling:** MCP defines standard error codes: - `-32700`: Parse error (invalid JSON) - `-32600`: Invalid request (wrong structure) - `-32601`: Method not found - `-32602`: Invalid parameters - `-32603`: Internal error Custom error codes below `-32000` are reserved for transport-specific errors. **Protocol Versioning:** MCP uses semantic versioning for the protocol. Clients should negotiate compatible versions, though the specification recommends supporting at least version 1.0 for stability.

EXERCISE

Using the MCP specification, identify which JSON-RPC method would be used to: (a) request a list of available tools, (b) execute a tool with parameters, (c) subscribe to resource change notifications. Write the method names without looking at reference material.

← Chapter 1
What is MCP?
Chapter 3 →
Architecture: Client vs Server