MCP: Protocol Hub

Complete guide to the MCP protocol for agentic commerce: scope, API model, implementation checklist, and best practices.

eLLMo AI Protocols Team
eLLMo AI Protocols Team
12 min read

Short orientation

When AI assistants and agent runtimes cannot discover what your systems can do, they cannot reliably serve your catalog or complete transactions. This protocol hub is for engineering teams and technical product managers implementing the Model Context Protocol (MCP) in production agentic commerce stacks. It provides a precise definition, scope, primitives, architecture and API model, an implementation checklist, common pitfalls and best practices, and pointers to related protocols. It aligns with eLLMo AI's protocol-plural strategy to make brands discoverable, trusted, and transactable without replatforming.

Definition of MCP

The Model Context Protocol (MCP) is a JSON-RPC 2.0 based protocol that standardizes how AI clients and servers negotiate capabilities and exchange messages. Server features include tools (callable actions), resources (readable artifacts), and prompts (template bundles). Client features include roots (virtual file trees), sampling (LLM interactions), and elicitation (schema-driven forms and URLs).

MCP's lifecycle includes initialization, capability negotiation, operation, and shutdown. It is transport-agnostic with common deployments over HTTP(s), WebSocket, or stdio. MCP is complementary to commerce protocols; it does not define catalogs or orders, but provides a clean way to expose them as tools, resources, and prompts.

References: MCP Base Overview (2025-11-25); MCP Lifecycle (2025-11-25); Agentic Commerce Protocol Landscape 2025-2026 (eLLMo AI); API-first vs protocol-first for agentic commerce (eLLMo AI).

Protocol scope and primitives

MCP focuses on capability negotiation and structured message exchange between a client (e.g., an agentic runtime) and a server (e.g., a brand gateway). Scope includes connection lifecycle and version negotiation; capability negotiation (what the server and client can do in-session); server feature exposure (tools, resources, prompts); client feature exposure (roots, sampling, elicitation); and utilities such as pagination, logging, completion, and tasks (experimental).

Message primitives (JSON-RPC 2.0)

All messages follow JSON-RPC 2.0.

1

Request

method + params + id (non-null, unique per session).

2

Result response

result + id (matching request).

3

Error response

error + id (matching request).

4

Notification

method + params; no id, no response.

Capability objects (selected)

Server and client capabilities advertised during negotiation.

1

Server: tools

Lists and executes callable actions; listChanged support. Direction: Server to Client.

2

Server: resources

Lists and reads resources; subscribe and listChanged support. Direction: Server to Client.

3

Server: prompts

Lists and resolves prompt templates; listChanged support. Direction: Server to Client.

4

Server: logging, completions

Structured logs and argument autocompletion. Direction: Server to Client.

5

Client: roots

Exposes filesystem-like roots. Direction: Client to Server.

6

Client: sampling, elicitation, tasks

LLM sampling, server-initiated form/URL elicitation, and experimental task tracking. Direction: Client to Server.

JSON Schema usage

Default dialect is 2020-12 when $schema is absent. Clients and servers must validate schemas against the declared or default dialect. References: MCP Base; MCP Server Tools (2025-06-18).

Architecture and API model

Interaction model: the client sends initialize; the server returns capabilities; the client sends initialized; normal operations (tools, resources, prompts, logging, completions) follow; shutdown occurs via transport closure. Transport options are HTTP(s), WebSocket, or stdio. For HTTP, clients include the MCP-Protocol-Version header after negotiation.

MCP client-server architecture with capability negotiation and JSON-RPC message exchange.

MCP client and server with negotiated capabilities and JSON-RPC message flow over HTTP/WebSocket/stdio

Core API methods (selected)

Lifecycle and feature methods.

1

Lifecycle

initialize (request/response), notifications/initialized.

2

Tools

tools/list, tools/call, notifications/tools/list_changed.

3

Resources

resources/list, resources/read, resources/templates/list.

4

Prompts

prompts/list, prompts/get, notifications/prompts/list_changed.

Initialization (client to server)

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {},
      "elicitation": { "form": {}, "url": {} },
      "tasks": { "requests": { "elicitation": { "create": {} }, "sampling": { "createMessage": {} } } }
    },
    "clientInfo": {
      "name": "ExampleClient",
      "title": "Example Client Display Name",
      "version": "1.0.0",
      "description": "An example MCP client application"
    }
  }
}

Initialization (server to client)

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "logging": {},
      "prompts": { "listChanged": true },
      "resources": { "subscribe": true, "listChanged": true },
      "tools": { "listChanged": true }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "title": "Example Server Display Name",
      "version": "1.0.0",
      "description": "An example MCP server providing tools and resources"
    }
  }
}

Tools: list and call (examples)

Client requests tools/list (optionally with cursor for pagination). Server returns a list of tools with name, title, description, and inputSchema. Client then calls tools/call with name and arguments. Server returns result with content (e.g., text) and optionally structuredContent for machine-friendly parsing. Server may send notifications/tools/list_changed when the tool list changes.

MCP lifecycle handshake from initialization to shutdown.

Four-phase flow: initialize, capabilities result, notifications/initialized, operations, shutdown

Implementation checklist

Your roadmap to AI-first commerce

1

Protocol lifecycle

Implement initialize and respond with negotiated protocolVersion and capabilities. Enforce version header on HTTP transports after negotiation. Send and handle notifications/initialized at the correct phase. Apply request timeouts and cancellation.

2

Capabilities and features

Declare server capabilities for tools, resources, and prompts; include listChanged and subscribe (for resources). Provide tools with inputSchema and optional outputSchema; validate on server. Implement resources/list and resources/read with MIME types and annotations. Expose prompts/list and prompts/get with message parts (text/image/audio) as needed.

3

Schema and validation

Default to JSON Schema 2020-12 when $schema is absent. Validate all input and output against declared schemas; reject unsupported dialects with clear errors. Provide completion endpoints if offering autocompletion.

4

Security and governance

Sanitize and validate all tool inputs; rate-limit calls; log invocations. For sensitive tools, keep a human-in-the-loop confirmation path. Secrets in resource URIs can leak across clients; use environment or secure config instead. Respect same-origin constraints for icons and media.

5

Observability

Emit structured logging; include correlation IDs (JSON-RPC id) in logs. Track listChanged events and reconcile client feature state. Maintain audit trails for production operations.

6

eLLMo AI alignment

Map existing REST or GraphQL endpoints to MCP tools with intent-centric names. Connect eLLMo's Verified Brand Graph as the authoritative backing for resources and prompts. Keep MCP side-effect tools aligned with brand policy guardrails and commerce truth.

To stay up to date, follow us on LinkedIn and sign up to our mailing list via our mailing list.

Common pitfalls and best practices

Pitfall: Overexposing tools 1:1 with internal endpoints

When tools mirror internal endpoints with no intent semantics or guardrails, agents get brittle contracts and unclear behavior. Design intent-centric tools (e.g., quote_shipping instead of post_/v1/rates) and attach clear input and output schemas.

Pitfall: Skipping JSON Schema validation

Leads to brittle interoperability and LLM confusion. Implement outputSchema for machine-friendly parsing; return both structuredContent and a text echo for backwards compatibility.

Pitfall: Ignoring capability negotiation

When clients call methods that were not declared in capability negotiation, servers reject requests and integration breaks. Use listChanged notifications to drive cache invalidation and client reconciliation loops.

Pitfall: Missing timeouts and cancellation

Results in hung requests and resource exhaustion. Enforce per-request timeouts and support cancellation and progress notifications.

Pitfall: Returning only unstructured text

When an outputSchema exists but you return only unstructured text, machine consumers cannot parse results reliably. Return both structuredContent and a text echo for compatibility. Apply least-privilege for tools and confirm destructive or high-risk operations with users.

Best practice: Audit and governance

Log all tool calls with inputs, durations, and outcomes; redact PII where necessary. eLLMo's protocol-first posture favors intent-centric tools over 1:1 endpoint wrapping and keeps catalog and policy truth consistent.

Related protocols and standards

1

UCP (Universal Commerce Protocol)

Commerce data and transaction orchestration.

2

ACP (Agent Commerce Protocol)

Agent-led commerce flows and negotiation.

3

A2A (Agent-to-Agent)

Cross-vendor delegation and collaboration.

Standards and integration path

Standards: JSON-RPC 2.0 (request/response/notification envelope); JSON Schema 2020-12 (parameter and output validation); MCP Spec (latest base, lifecycle, server tools). For stack guides (e.g., Shopify), see Integrations.

Related internal resources

Parent hub: Agentic Commerce Protocols overview. Related protocols: UCP, ACP, A2A. Integrations hub (implementation guides by stack). Glossary: Agentic commerce, Answer Engine Optimization.

FAQs

What is MCP in one sentence?

A JSON-RPC based protocol that standardizes capability negotiation and server/client features (tools, resources, prompts; roots, sampling, elicitation).

Does MCP define orders or catalogs?

No. Represent those via MCP tools, resources, and prompts; commerce semantics come from protocols like UCP and ACP.

Which transport should I use?

HTTP(s) or WebSocket for services; stdio is common for local processes. MCP is transport-agnostic.

Which schema dialect should I target?

Default to JSON Schema 2020-12 unless you explicitly declare another dialect.

How do I expose a new action?

Add a tool with an inputSchema (and optional outputSchema), declare the tools capability, and return results with content and structuredContent.

How do clients discover changes?

Use listChanged notifications for tools, resources, and prompts; implement pagination for large lists.

How do I prevent unsafe actions?

Combine least-privilege tool design, input validation, user confirmations, and audit logging.

How does eLLMo AI help?

eLLMo maps your existing stack to MCP (and UCP, ACP, A2A) via a translation layer, enforces policy guardrails, and distributes verified knowledge without replatforming.

Ready to implement MCP?

Get a protocol gateway and verified catalog across MCP, UCP, ACP, and A2A without replatforming.

Join Our Mailing List

Stay tuned. Join our mailing list to be among the first to experience the future of search. We'll be in touch with news and updates.

We respect your privacy. Unsubscribe at any time.

MCP: Protocol Hub | eLLMo AI Protocols