Hi thanks for the comment,
Skills don’t map to LangGraph subgraphs; they just scope tool schemas per task.
Latency gains come from smaller prompts (no large MCP schema serialization); if you already filter tools manually, the main benefit is simpler, reusable orchestration.
Hi Thanks for the comment,
The unified agent doesn’t execute untrusted code — it orchestrates.
Side effects only happen at explicit execution boundaries (remote tools or the CodeAgent). The CodeAgent is sandboxed in Docker; the planner/router isn’t, because it never executes arbitrary code. Least-privilege and auditing are enforced at the execution boundary, not per function.
Do you have any suggestions for making PolyMCP better?
Hi thanks for the comment,
I’m not trying to replace FastMCP (or anything else), and I’m not really comparing on the “basic MCP server” use case.
PolyMCP, beyond creating MCP servers over HTTP and stdio, WASM (Pyodide) bundle to run tools in the browser/edge with an “MCP-style” tool interface,provides unified agent/orchestration across multiple MCP servers, plus an Inspector UI and production guardrails (budgets, logging, redaction, allowlists, retries).
The goal is to be a single, end-to-end toolkit for developers: tool exposure + debugging + governance + orchestration.
Sorry for the late response.
Thanks a lot for your suggestion! Policy now: config-driven allow/deny lists + metadata constraints + budgets/redaction. Auth separate (OAuth2 auto-refresh). Planning hooks.
Haha, yes, AI gave me a hand here and there , but I wrote the code myself and made all the key design decisions — the focus of PolyMCP is on making MCP server management and LLM agent orchestration clear, modular, and reliable.
I’ve been working on Polymcp, an open-source toolkit for building MCP agents that can discover, inspect, and orchestrate tools across multiple MCP servers (HTTP, stdio, or in-process).
A few things that might be interesting to this crowd:
• Tool Inspector: a built-in inspector that lets you see exactly which tools are exposed by each MCP server, their schemas, inputs/outputs, and how the agent is reasoning about using them. It’s meant to make MCP setups debuggable instead of opaque.
• Unified agent: one agent can talk to multiple MCP servers at once (local Python tools, remote HTTP servers, stdio MCPs like Playwright, etc.).
• Code-mode execution: instead of iterative “LLM → tool → LLM → tool” loops, the agent can generate a single Python script that executes the full tool plan. This is faster, cheaper in tokens, and easier to audit.
• Minimal boilerplate for servers: you can expose plain Python functions as MCP tools with almost no glue code.
• CLI + registry: manage MCP servers, configs, and agents from the CLI; servers can be added/removed without touching agent code.
The goal is to make MCP setups feel more like a composable systems tool than a black-box agent framework.
I’ve released an update to PolyMCP, a Python framework for interacting with MCP servers using custom agents.
A common issue in MCP projects is that too many tools get loaded at once, wasting tokens and confusing agents. This update fixes that at a structural level.
What’s new (Python-only for now):
• Skills system: tools are grouped into skills and loaded only when relevant to a request
• Lower token usage and better accuracy thanks to smaller tool contexts
• More ways to run MCP servers in Python: beyond HTTP, you can now use stdio and WASM
PolyMCP aims to make MCP usage simpler, modular, and closer to real developer workflows.
Feedback, critiques, or ideas for improvement are very welcome!
JavaScript/Node.js support already! TypeScript compiles to standard JavaScript, so anyone can use the library with both TypeScript and pure JavaScript. No special setup required.
I’m excited to share PolyMCP, a toolkit for creating MCP servers and agents that can call them. It works in Python via HTTP, stdio, or in-process for zero-latency calls, and supports almost any model.
There’s also PolyMCP-TS, a TypeScript version, so everything you can do in Python can now run in TypeScript as well.
PolyMCP makes it easy to build modular, agent-driven architectures without having to write a lot of glue code.
Feedback, suggestions, or bug reports are very welcome!
Hi, thanks for the question! The project works exclusively through official APIs for interacting with models like ChatGPT and Claude. It requires API access with valid keys and does not support non-API usage like logging into ChatGPT Plus via the web interface or similar methods.
If you want to use it, you’ll need to have API credentials from the providers.