Learn MCP - Ecosystem & Integration Patterns

#Introduction

In episode 19 you learned to optimize and scale an MCP server. Now the more interesting question: where are all these servers used? Episode 20 answers it by exploring the ecosystem — from popular agent frameworks like LangChain and the OpenAI Agents SDK, CLI agents like Claude and Codex, IDE agents, to the most common integration patterns: RAG, tool automation, and agentic payments.

#Integration with LangChain and LangGraph

LangChain and LangGraph are the most widely used agent frameworks for building pipelines and graphs. Both provide an official adapter named langchain-mcp-adapters that turns an MCP server into tools the framework understands — without rewriting the server logic.

import { MultiServerMCPClient } from 'langchain-mcp-adapters'
 
const client = new MultiServerMCPClient({
  fetch: {
    transport: 'streamableHttp',
    url: 'https://mcp.example.com'
  }
})
 
const tools = await client.loadTools()

Once loaded, those tools can be used in an ordinary agent executor or as nodes in a LangGraph graph. The advantage: tool definitions stay alive in the MCP server, not hardcoded in agent code — build once, use across many frameworks.

#Integration with the OpenAI Agents SDK

The OpenAI Agents SDK takes a similar approach through the openai-mcp package: each MCP server becomes a tool for the agent. Here's an example with the stdio transport:

agents_mcp.py

from agents import Agent
from openai_mcp import MCPStdio
 
mcp = MCPStdio(
    command="npx",
    args=["-y", "mcp-server-fetch"],
)
 
agent = Agent(
    name="Fetcher",
    instructions="Ambil dan ringkas halaman web.",
    tools=mcp.get_tools(),
)

MCPStdio runs the server as a local subprocess — suitable for servers that don't need a separate deployment. For servers already live on the internet, use MCPStreamableHTTP with the endpoint URL — for example a server run via npx -y mcp-server-fetch as a bridge. The transport choice depends on where the server lives, not on the agent framework.

#Claude, Codex, and Other CLI Agents

CLI agents like Claude Code and Codex use MCP to extend their capabilities in the terminal. Claude Code manages the server list via the claude mcp command:

claude mcp add fetch -t stdio -- npx -y mcp-server-fetch
claude mcp list

This command adds a server to the configuration read at every session, and the agent can immediately call its tools. Many other CLI agents read server definitions in the same mcpServers format — that's the beauty of a standard: one server definition, used across various agents, no vendor lock-in.

#IDE Agents: VS Code

In the editor, an agent (for example GitHub Copilot) reads the MCP configuration from the .vscode/mcp.json file:

{
  "servers": {
    "fetch": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "mcp-server-fetch"]
    }
  }
}

With this file, an agent in the editor can call the same tools used in the CLI or other frameworks. This configuration file is usually committed to the repository so a whole team uses the same servers — consistent with the reproducible documentation philosophy from previous episodes.

#Data Retrieval Patterns with RAG

RAG (Retrieval-Augmented Generation) is one of MCP's most natural use cases. Why? Because resources are a context channel, not an execution channel. The pattern: a vector store or knowledge base is wrapped in an MCP server, exposing a resource template so the agent pulls relevant documents as context.

{
  "uriTemplate": "memory://{note}",
  "name": "Catatan Memori",
  "mimeType": "text/markdown"
}

The agent calls resources/read to pull the relevant chunks, rather than running a tool for each document. The difference is significant: a wrong retrieval doesn't execute anything, while a wrong tool call can have side effects. Resource templates also make retrieval results enter the context window cleanly.

#Tool Automation Patterns

On the other end of the spectrum is tool automation: an MCP server wraps internal systems — CMS, CI, billing, or CLI — into tools an agent can call. For example a server exposing create_issue, run_pipeline, or trigger_deploy.

{
  "method": "tools/list",
  "result": {
    "tools": [
      {
        "name": "trigger_deploy",
        "description": "Menjalankan deployment ke staging",
        "inputSchema": {
          "type": "object",
          "properties": {
            "service": { "type": "string" }
          },
          "required": ["service"]
        }
      }
    ]
  }
}

This is where the lesson from episode 14 is felt most: strict input validation, allowlists, and an execution sandbox. Tool automation gives agents real power — and power without safeguards is an incident.

#Agentic Commerce and Payments Patterns

A hot new field: agents making transactions. The x402 protocol lets an LLM request micro-payments through HTTP authorization mechanisms, while AP2 (Agent Payments Protocol) and UCP interact with MCP from the other side. The common pattern:

• An MCP server exposes a tool like send_payment.
• When the tool is called, the server triggers a payment flow via x402 outside MCP.
• The result comes back as a transaction status, and MRTR is used for mid-flow user confirmation.

MCP stays focused on tools and data; money matters are handed to protocols designed for exactly that. This separation keeps the MCP spec lean and safe.

#Conclusion

Episode 20 mapped the ecosystem: LangChain and LangGraph adapters, the OpenAI Agents SDK, CLI agents like Claude and Codex, IDE agents in VS Code, then three core patterns — RAG through resources, tool automation with strict safeguards, and agentic commerce with x402, AP2, and UCP.

Key takeaways:

• Framework adapters mean tool definitions live in the MCP server, not hardcoded in every agent.
• The same mcpServers configuration can be used across CLI, IDE, and frameworks.
• RAG fits best through resources because retrieval is context, not execution.
• Tool automation must be paid for with the validation and sandboxing from episode 14.
• For payments, let dedicated protocols (x402, AP2, UCP) do the work, not the MCP core.

In the next episode 21 we summarize the modern features of the 2026-07-28 spec — from the stateless core, server/discover, MRTR, to the post-stateless roadmap — plus an SDK map across all languages. See you there!