If you want people to adopt your tool, you may need to explain any advantage this has over fastmcp.
It's already easy to expose a python function as an MCP server. From the fastmcp docs:
from fastmcp import FastMCP
mcp = FastMCP("Demo ")
@mcp.tool
def add(a: int, b: int) -> int:
"""Add two numbers"""
return a + b
if __name__ == "__main__":
mcp.run()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.
How do you handle side-effectful tools and secrets? Least-privilege and auditing seem hard once any Python function can become a tool (scoped creds, revocation, logs).
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?