mcp-use joins server building, clients, agents, and MCP views
Most MCP libraries choose one side of the connection. mcp-use covers both. Its main README presents a TypeScript server framework with typed tools, structured results, React views, a browser inspector, a command-line client, screenshots, tunnels, and deployment. The Python package can create servers, connect to several servers, and give their tools to a LangChain model. That breadth is the reason to consider it and the reason to define which half you need.
The TypeScript path is aimed at an MCP application rather than a bare tool endpoint. A generated project serves its MCP route and an inspector, and a tool can bind structured output to an interactive view. Developers can invoke tools from the terminal and capture a view screenshot before connecting ChatGPT or Claude. The Python path is more agent-oriented: configure stdio or HTTP servers, choose a tool-calling model, and let MCPAgent select tools over several steps.
The Python client saves glue code but still runs other people's tools
A Python client can load the familiar mcpServers configuration, spawn local commands, or connect to HTTP endpoints. The agent wrapper then turns discovered tools into a LangChain-compatible loop. Streaming exposes messages and tool actions as they happen. This removes adapter work for teams already committed to LangChain, especially when one agent needs a browser server and a second domain-specific server in the same session.
That convenience does not make an MCP server safe. A configuration may run npx, uvx, or another executable with inherited environment values. Remote servers can call outside systems. The Python README documents allow and deny lists for tools, but issue 1257 describes a missing per-tool authorization hook at the server's agent boundary. A production design still needs identity, least privilege, logs, and explicit approval for destructive operations.
What happened when we ran it
Our sandbox installed the Python project from libraries/python/ at commit 5865e5c in 40 seconds. It added 87 packages and used 111 MB in a fresh Python 3.12 Debian container with 3 CPUs and 8 GB of RAM. The build completed in 12 seconds. Pip-audit reported 0 known vulnerabilities in that installed environment, a clean result for the dependency versions resolved during our run.
Pytest finished after 23 seconds with exit 1. Of 337 cases, 159 passed, 135 failed, and 43 ended in collection or setup errors. The tail named several conformance tests for initialization, tools, resources, prompts, elicitation, and error handling. This was not a minor single assertion at the edge of the suite, so we would not ship a Python integration based only on a successful import and build.
The most specific setup message concerned test_server_conformance_via_runner: pytest said the test requested an async fixture named conformance_server, but no plugin or hook handled it. The remaining listed conformance tests ended in assertion errors. The log does not expose enough context to decide whether one fixture configuration cascaded into all 135 failures. It does establish that the repository's installed test command did not produce a passing development environment in our sandbox.
Model credentials and server permissions are part of setup
The Python agent is not bundled with a model provider. Its README asks users to install a LangChain integration such as the OpenAI or Anthropic package, choose a model that supports tool calls, and place the corresponding API key in the environment. Local clients also need every configured MCP command available. HTTP clients need reachable endpoints and any authentication those servers require. A six-line agent example is therefore the last layer of setup, not the whole system.
TypeScript users get a more contained first loop through create-mcp-use-app, local development, and the inspector. Even there, a fresh server-only scaffold has a visible wart: issue 2297 reproduces 4 React dependency warnings on the first build despite the template having no views. The reporter says the build exits successfully. Treat it as confusing output, not a build failure, and check the issue before teaching newcomers to ignore warnings.
Version 2 moves quickly and asks users to migrate
The repository was pushed on 2026-08-25, the same date as release mcp-use 2.3.2. It had 10,526 stars, 64 open issues and pull requests, 26 CI workflow files, and an MIT license when fetched. The release entry itself contains only its name, so it offers no basis for claiming particular fixes. The README directs version 1 users to a version 2 migration guide, evidence that the public framework shape has changed materially.
Protocol conformance is a stated focus, yet its reporting deserves scrutiny. Issue 2266 says the conformance summary checks observed failures against an expected-failure list but never reports entries that have become obsolete. According to the issue, an old allowlist entry could later hide a regression in that scenario. This is a precise limitation in CI accounting, and it pairs uncomfortably with our many Python conformance failures.
Choose it for its opinions, not just MCP compatibility
The official TypeScript and Python SDKs are better fits when a team wants direct access to protocol primitives and will build its own application structure. FastMCP is the clearer comparison for concise Python server development. mcp-use earns its extra surface when typed TypeScript views, inspection, screenshots, multi-server clients, and a LangChain agent belong in the same engineering workflow.
Our result argues for a controlled adoption. Start with one non-destructive server, pin the mcp-use and provider versions, and write tests around the exact tools the model may call. The successful 12-second build and clean dependency audit remove two concerns. The 135 failed tests and 43 errors add a larger one, so a team should reproduce the relevant client and conformance cases in its own environment before making mcp-use the shared gateway to sensitive systems.