LangChain MCP: Use MCP Tools in LangChain Agents
LangChain's MCP adapter lets agents call external tools, but production success depends more on server quality and permission design than on connection code.
LangChain MCP connects a LangChain or LangGraph agent to tools exposed by Model Context Protocol servers. Install LangChain's official adapter, configure a local or remote server, load its advertised tools, and give those tools to an agent. The connection is straightforward; controlling credentials, tool output, and write access is the real engineering work.
Table of contents
- What LangChain MCP actually is
- What exists today
- Setup
- Tools you get
- Permissions and blast radius
- Real limits
- When not to use it
What LangChain MCP actually is
LangChain MCP is an adapter layer, not a special model and not a catalog of fixed tools. It translates tools advertised by an MCP server into LangChain tools that an agent can select and call during a run.
Once connected, an agent can do whatever that server deliberately exposes: search records, retrieve a file, inspect an issue, run a database query, or create an object. LangChain handles the agent loop; the server owns the tool schema, authentication, side effects, and returned data. The LangChain MCP documentation also covers MCP resources as LangChain Blob objects, prompts as messages, structured tool results, and multimodal content.
That boundary matters. MCP does not make an unreliable API reliable, and an agent does not understand permissions merely because a tool has a good description. At MCP Directory, we would start with one narrow server and two or three read tools, then add writes only after observing actual calls. Browse our MCP capabilities guide before treating tools, resources, and prompts as interchangeable—they serve different jobs.
What exists today
The Python adapter is an official LangChain-maintained project; most servers it can connect to are separate products or community projects. Production readiness therefore has to be judged twice: once for the adapter and again for every server.
For Python, the verified package is langchain-mcp-adapters. Its official GitHub repository says it converts MCP tools into LangChain tools and includes a multi-server client. JavaScript/TypeScript support lives in the LangChain.js repository under @langchain/mcp-adapters; do not assume Python examples copy directly into TypeScript.
Server provenance is a different question. A vendor-operated remote server usually has clearer authentication and support, while a vendor-authored local server still leaves deployment and patching to you. A community server may be perfectly usable, but you must review its source, release activity, license, credential handling, and tool schemas. Our official-server collection helps narrow the search, while best MCP servers provides broader discovery. “Listed” should never mean “trusted by default.”
Setup
A minimal Python setup needs a supported Python environment, langchain-mcp-adapters, LangChain or LangGraph, a model integration, and one verified MCP server. Test the server independently before putting an agent in the loop.
- Install the packages named in the adapter quickstart:
langchain-mcp-adapters,langgraph, and the model provider integration you actually use. - Obtain the server's exact launch command or MCP endpoint from its own documentation. Use
stdiofor a trusted local process or Streamable HTTP for a remote service. - Create the narrowest token or OAuth grant the service permits. Keep secrets in a secret manager or runtime environment, never in source control.
- Instantiate
MultiServerMCPClient, load tools withawait client.get_tools(), pass them tocreate_agent, and invoke the agent asynchronously. - Exercise each tool with fixed test inputs before allowing open-ended prompts. The MCP Inspector debugging guide recommends inspecting tools and calls outside the agent first.
This is the verified remote-client shape from LangChain's documentation; replace the example URL and header with values documented by your chosen server:
import os
from langchain_mcp_adapters.client import MultiServerMCPClient
client = MultiServerMCPClient({
"service": {
"transport": "http",
"url": "https://your-server.example/mcp",
"headers": {
"Authorization": f"Bearer {os.environ['SERVICE_TOKEN']}"
},
}
})
tools = await client.get_tools()
This is a Python dictionary keyed by your own server alias, not a top-level mcpServers JSON document. For local stdio, LangChain accepts a transport, command, and argument list; copy those values only from the server publisher. The protocol defines stdio and Streamable HTTP, while legacy HTTP+SSE is deprecated in the current MCP transport specification. Use the MCP config generator to reduce punctuation mistakes, then compare its output with the target client's schema.
Tools you get
You get exactly the tools reported by the connected server—there is no universal LangChain MCP tool list. Inspect await client.get_tools() at startup and treat any change in names or schemas as a dependency change.
| Verified name | Where it exists | What it does |
|---|---|---|
get_tools() | MultiServerMCPClient | Loads advertised MCP tools and converts them into LangChain tools. |
get_resources() | MultiServerMCPClient | Loads all or selected MCP resource URIs as LangChain blobs. |
get_prompt() | MultiServerMCPClient | Retrieves one named MCP prompt, optionally with arguments, as messages. |
add / multiply | Official adapter demo server only | Demonstrates two callable arithmetic tools; these are not built into the adapter. |
The distinction in the table prevents a common failure: writing a prompt that demands search_issues when the chosen server advertises another name—or no issue-search tool at all. The official adapter README is the source for the demo names, while the LangChain docs define the three client methods. In production, log the discovered name, description, and input schema during deployment, then fail the deployment if a required contract disappears.
Permissions and blast radius
Start read-only, use a dedicated integration identity, and require approval for consequential writes. An MCP tool call runs with the credential's real authority, so a mistaken agent action is an API action, not a harmless draft.
A dedicated account makes ownership visible in audit logs and prevents the agent from inheriting a developer's broad access. Restrict it to selected workspaces, repositories, database schemas, or folders. If the service offers separate read and write scopes, issue a read token first; do not grant an omnibus scope for convenience. MCP's authorization guidance recommends splitting access by tool or capability where possible.
For writes, put a policy check or LangChain interceptor before execution. Show the user the concrete target and arguments for deletion, publication, payment, permission changes, or bulk updates, and require confirmation. A careless ticketing write can spam an entire project; a database write can corrupt many rows; a file tool can expose or overwrite confidential material. The MCP tools security guidance calls for user confirmation on sensitive operations, visible inputs, timeouts, result validation, and audit logs. I would also cap batch size server-side because prompts are not access controls.
Real limits
MCP standardizes discovery and invocation; it does not remove context limits, provider quotas, network failures, or gaps in an upstream API. Design every tool as a bounded interface with pagination, filtering, timeouts, and explicit errors.
A 20,000-row result may fit through HTTP yet still swamp the model's context window, increase token cost, and reduce answer quality. Return counts plus a small page, keep bulky structured content outside conversation history when possible, and let the agent request the next page. LangChain stores MCP structuredContent as a tool artifact by default rather than automatically exposing all of it to the model, as documented in its structured-content guide. That is a useful safety valve, not permission to return unbounded data.
Rate limits remain those of the MCP server and its upstream service. Agent loops can multiply calls, so add per-run budgets, retries with backoff only for transient failures, and idempotency controls for writes. Stateless calls are another surprise: MultiServerMCPClient creates a fresh session per invocation by default; stateful servers require an explicit persistent session. Finally, MCP cannot create capabilities absent from the source API. If an API cannot search historical records, impersonate a user, or perform a transaction, the server cannot honestly offer it.
When not to use it
Do not use MCP when one stable API call or an existing LangChain integration already solves the job. The protocol adds discovery, transport, another dependency boundary, and usually more operational failure modes.
Choose a plain API script for deterministic scheduled exports, bulk migrations, or a fixed read-transform-write pipeline. Typed SDK calls are easier to test, retry, and reason about than an agent deciding which tool to call. Choose LangChain's native model, retriever, vector-store, or middleware integrations when you need in-process AI plumbing rather than an external capability boundary.
MCP earns its place when several agent hosts need the same governed tool surface, tools change independently of the agent, or a remote vendor exposes MCP as its supported interface. Even then, I would keep business-critical writes deterministic and use the agent for selection, summarization, and exception handling. The trade-off is simple: MCP improves portability and discovery, but direct code gives tighter control. For production LangChain MCP, prefer the smallest tool catalog that satisfies the workflow—not every server you can connect.