Thanks for the suggestion and for the comment! I will try to implement more and more things as soon as the usage becomes hopefully wider!

Hi thanks for the comment https://github.com/poly-mcp/PolyMCP

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?

Makes sense — execution boundary is the right place.

I'd prioritize audit logs + correlation IDs, and short-lived creds per tool call. Do you expose tool capabilities to the planner without exposing creds?

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.

None of this came across in what you wrote in your Show HN.

because I wanted to introduce this part of PolyMCP that can take you from code with only functions to an MCP.

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.

How do you do policy at keypost.ai?

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’m working on PolyMCP a simple and efficient way to interact with MCP servers using custom agents

Hi HN,

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.

Repo: https://github.com/poly-mcp/Polymcp PyPI: https://pypi.org/project/polymcp/

I’d love feedback, especially from people already experimenting with MCP, inspectors, or multi-tool agents.

Hi HN,

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!