Show HN: PolyMCP – open-source toolkit to expose MCP tools and run agents | Hacker News Reader

Show HN: PolyMCP – open-source toolkit to expose MCP tools and run agents

1 pointjustvugg2 comments

Hi HN — I’m the author of PolyMCP (MIT).

PolyMCP is a toolkit/runtime for the Model Context Protocol (MCP): it helps you build MCP tool servers (expose Python functions as tools over HTTP/stdio), connect multiple MCP servers, and run agents that orchestrate them with deploy-friendly guardrails.

Latest update is mostly reliability work: - OAuth2 (RFC 6749): client credentials + authorization code flows, refresh handling, basic retries - Docker executor cleanup fixes (Windows + Unix) - Better skills/tool matching + stdio server support - CodeAgent async handling + error recovery - Health checks, structured logging, and rate limiting

Repo: https://github.com/poly-mcp/Polymcp

If you’ve deployed MCP/agent systems: what tends to bite you first (auth, rate limits, observability, sandboxing)? I’m especially interested in OAuth2 edge cases and container lifecycle issues.

Nice work - the "deploy-friendly guardrails" framing resonates. Too many MCP tools assume local dev only.

To your question about what bites first: in our experience at keypost.ai, the order is usually:

1. *Auth* - OAuth token refresh edge cases, especially when agents run long tasks that span token expiry 2. *Rate limits* - not having them, then having them but too coarse (per-tool vs per-endpoint vs per-argument) 3. *Observability* - specifically, correlating agent intent with actual tool calls when debugging why something failed 4. *Sandboxing* - usually comes up after the first "oops" moment

One pattern we've found useful: separating "can this identity call this tool" (auth) from "should this specific call be allowed" (policy). They're often conflated but have different failure modes and different owners (security team vs product team).

Curious how you're handling policy in PolyMCP - is it config-driven or code-driven?

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?

Reply on news.ycombinator.com