MCP

Purpose and Scope

Model Context Protocol, usually shortened to MCP, is the protocol LangChain uses in managed agent deployments to let an agent call tools that live outside the agent process. In the LangSmith Managed Deep Agents flow, an MCP server can expose capabilities such as GitHub operations, internal service calls, or third-party API actions. The important design point is that MCP tools are not the same thing as local Python functions registered directly on an agent. They are remote, protocol-addressable tools managed as workspace resources, with authentication and connection lifecycle handled outside the agent code.

LangChain’s broader repository positions the project as an agent engineering platform, where agents compose models, tools, streaming, persistence, and deployment infrastructure. MCP fits into that platform at the tool connectivity boundary: it lets a deployed agent reach systems that already speak MCP instead of requiring every capability to be packaged as an in-process LangChain tool. In Managed Deep Agents, LangSmith manages each MCP server connection, including per-user OAuth when required, so agent authors can reference the exposed tools without writing custom OAuth client code in their agent implementation.

The supplied repository source path for this page is not an MCP endpoint; it is a LangChain Classic compatibility module that dynamically re-exports a JavaScript language parser from langchain_community. It still illustrates an important repository convention for integration-facing surfaces: compatibility wrappers keep older import paths working while moving implementations into more appropriate packages. MCP usage follows the same product-level principle of separating public authoring surfaces from implementation and provider-specific details, although the actual MCP server behavior described here comes from the official Managed Deep Agents and Agent Server API documentation. Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py

Relevant Source Files

• libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py — Shows a compatibility module that defines a deprecated lookup for JavaScriptSegmenter, delegates attribute access through create_importer, and exports the compatibility symbol through __all__. For this MCP page, it provides repository-grounded evidence for LangChain’s pattern of maintaining stable public entry points while implementation details move across packages. Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py

Core Primitives

An MCP setup has three practical primitives: the server, the connection, and the tool entries consumed by the agent. The MCP server is the remote service that speaks the protocol and exposes callable tools. The connection is the LangSmith-managed relationship between a workspace and that server, including static headers or OAuth credentials when the server requires authentication. The tool entries are the concrete tool definitions copied into the agent project configuration, such as tools.json, so the deployed agent knows which remote operations it may call.

This separation matters because it changes where responsibility lives. With local tools, the developer typically owns Python code, argument schemas, runtime execution, and any secrets needed to reach external systems. With MCP in Managed Deep Agents, the server owns the external capability, LangSmith owns the workspace-level registration and connection lifecycle, and the agent deployment references the resulting tools. That makes MCP especially useful for shared services, organization-managed APIs, and tools that need user-specific OAuth rather than one global service credential.

MCP is also distinct from OpenAPI-style integration. An OpenAPI integration describes HTTP operations through a schema and lets tooling derive calls from that description. MCP is an interactive protocol for tool discovery and invocation, and the Agent Server API exposes it through a JSON-RPC endpoint. The official API documentation shows POST /mcp/ accepting JSON-RPC 2.0 payloads such as initialize, while GET /mcp/ returns 405 GET method not allowed; streaming not supported. The POST request must use Content-Type: application/json, and its Accept header must include both application/json and text/event-stream.

Managed Deep Agents Workflow

The recommended setup starts before deployment. MCP servers are workspace-level resources, so the server must be registered or connected before an agent that references it is deployed. In LangSmith, those resources are visible under Settings > MCP Servers. The official quickstart assumes a project created by deepagents init, then uses the CLI to register a server, inspect its tools, paste tool definitions into tools.json, and deploy the agent. That sequence keeps infrastructure setup explicit and makes the deployed project configuration reflect the remote tools it depends on.

A static-header server can be added with the CLI command deepagents mcp-servers add --url https://example.com/mcp --name my-tools. After registration, deepagents mcp-servers tools my-tools lists the available tools and prints a tools.json snippet. The manual copy step is intentional in the documented flow: it gives the agent author a chance to review exactly which remote tools are being granted to the agent. Once tools.json contains the desired entries, deepagents deploy publishes the agent with those MCP-backed tools available at runtime.

OAuth servers add one extra step. After registering the server, run deepagents mcp-servers connect <id|name|url> before listing tools. That connect step completes OAuth so LangSmith can manage per-user authentication for the server. The agent author still follows the same review-and-deploy pattern afterward: list tools, copy the selected entries, and deploy. The operational advantage is that the agent code does not need to embed browser redirects, token refresh logic, or provider-specific OAuth handling just to call a remote tool.

Use the CLI for most setups because it matches the documented quickstart and keeps the workspace state, tool listing, and deployment steps close together. Use the Python managed-deepagents SDK or the TypeScript @langchain/managed-deepagents SDK when registration and deployment need to be automated from another system. Use the REST API when you need direct control over request payloads or when you are integrating a custom client with the Agent Server API. The same primitives still apply regardless of client: register, connect if needed, discover tools, configure the agent, and deploy.

API and Protocol Behavior

At the Agent Server API layer, MCP traffic is JSON-RPC over the /mcp/ endpoint. The documented initialization request uses a JSON body with jsonrpc: "2.0", an id, method initialize, and params containing clientInfo, protocolVersion, and capabilities. The example protocol version is 2024-11-05. A successful POST /mcp/ response is documented as HTTP 200 with an object response body. This is the low-level interface beneath higher-level CLI and SDK workflows, and it is useful when testing connectivity or building a custom MCP client.

The header requirements are important for troubleshooting. The official API reference says the Accept header must include both application/json and text/event-stream; sending only one media type can produce behavior that differs from a working CLI or SDK request. The body is an application/json JSON-RPC 2.0 request, notification, or response object. By contrast, GET /mcp/ is not the streaming interface in the documented endpoint; it returns a 405 response stating that GET is not allowed and streaming is not supported. If a client attempts to open MCP by issuing GET, check the client transport assumptions before debugging the server itself.

The compatibility source selected for this page reinforces a repository-level implementation pattern rather than MCP protocol details. The module imports create_importer, declares a DEPRECATED_LOOKUP mapping for JavaScriptSegmenter, builds _import_attribute, and implements __getattr__ to resolve attributes dynamically. That pattern keeps a public name available while delegating the implementation to langchain_community.document_loaders.parsers.language.javascript. When designing MCP-backed tools for agents, apply the same stability mindset: keep the agent-facing tool names and schemas stable even if the remote server implementation or provider credentials change. Sources: libs/langchain/langchain_classic/document_loaders/parsers/language/javascript.py

Implementation Guidance

Treat MCP server registration as infrastructure, not as ad hoc application code. A server URL, static headers, OAuth settings, and workspace registration should be reviewed in the same way you review deployment configuration. The agent project should then contain only the tool entries it is allowed to use. This reduces accidental capability exposure: an MCP server may provide many tools, but a particular agent should receive the subset appropriate for its task, risk level, and human-review policy.

When introducing MCP to an existing LangChain agent, start by identifying which local tools are really remote integration concerns. Operations such as repository management, enterprise API access, internal workflow triggers, and SaaS actions are good candidates for MCP when there is already an MCP server or when authentication needs to be managed per user. Keep simple deterministic helpers local when they do not need shared infrastructure or external credentials. The boundary is not about whether a tool is powerful; it is about where execution, authentication, and ownership should live.

For production deployments, test the connection before deploying the agent and test the deployed agent after tool entries are added. The CLI flow gives a practical smoke test because mcp-servers tools must successfully discover server tools before tools.json can be populated. If using the REST API, validate that POST /mcp/ accepts a JSON-RPC initialize request with the correct headers. If OAuth is involved, confirm that the connect step has been completed for the workspace and user context that will run the agent.

Troubleshooting and Next Steps

Most MCP setup failures fall into a few categories: the server was not registered at the workspace level, OAuth was not completed before tool discovery, the agent was deployed before tools.json included the MCP tool entries, or a custom client used the wrong HTTP method or headers. Work through the setup in order instead of debugging the agent first. If GET /mcp/ returns 405, that matches the documented API behavior; switch to a JSON-RPC POST request or use the supported CLI or SDK client.

Next, read the agent authoring pages that explain how tools are selected and invoked inside LangChain agents, then read the connections and OpenAPI pages to compare MCP with other integration strategies. MCP is the right choice when a remote server exposes tools through the protocol and LangSmith should manage workspace-level connections or per-user OAuth. Local tools remain the simplest path for in-process Python behavior, and OpenAPI remains useful when the external surface is best represented as an HTTP schema.