I've been running a handful of MCP servers locally and remotely and I'm curious what others settled on. A few questions: stdio or HTTP transport in production? How do you scope which tools each agent can see? Any good patterns for budgets or rate limits on tool calls? And which servers turned out to be genuinely useful vs. demo-only? I'll share mine in the comments.#discuss #mcp #ai #opensource
CodeArchitect_J
Posted on
Top comments (1)
From the Auten team (we ship a computer-use MCP server, so take the bias into account). Our answers to your four:
Transport: stdio for anything that touches the local machine, HTTP only when the server genuinely lives elsewhere. Fewer moving parts, no auth to get wrong on a local port.
Scoping: per-agent client configs rather than one big server list. The agent that writes code never sees the tool that clicks on the screen unless the task needs it, and the tool descriptions say plainly what is irreversible (send, delete, buy) so the model asks first.
Budgets: count tool calls per task and stop at a hard ceiling, not just tokens. A loop that retries the same click 40 times is cheap in tokens and expensive in damage.
Useful vs demo-only: the ones that survived for us are filesystem, git, a browser and screen control for apps that have no API. Most "wrap one SaaS endpoint" servers ended up replaced by the CLI the agent can already run.
Curious what you landed on for rate limits, per server or per agent?