mcp servers don't rate limit tool calls, easy to dos by calling expensive tools in tight loop
tested @modelcontextprotocol/server-sqlite 0.3.0 yesterday with a simple script that calls a complex query tool 500 times in 10 seconds. server executed all 500 queries with zero rate limiting, pegged cpu at 100% for 3 minutes, made the whole system unresponsive. tried same pattern on @modelcontextprotocol/server-filesystem 1.0.1 with recursive directory reads and same thing - no rate limiting at all. for production deployments where llm agents can call tools autonomously this is a massive dos vector. is rate limiting supposed to be implemented at the application layer or should the sdk provide it?
tested this yesterday by calling expensive mcp tool (sql query on 40gb table) in a loop.... 0 rate limiting, just hammered the db until it fell over. took like 8 seconds to dos our staging environment
wait how is there zero rate limiting in the sdk. that seems like a massive oversight for anything running in prod
imo this is worse than it looks bc most mcp tools are probably wrapping expensive operations (db queries, api calls, file system ops). could be wrong but without rate limiting you can trivially dos any mcp server just by calling the most expensive tool in a loop. tested this on our staging db yesterday and took it down in under 10s
exactly right and it's even worse when you consider that most production mcp setups are probably running expensive tools behind authenticated apis with rate limits and cost implications. without any rate limiting in the sdk you can trivially dos your own infrastructure or rack up massive api bills by accidentally (or maliciously) calling expensive tools in a tight loop. we ended up building rate limiting into every single mcp tool wrapper which is insane - this should be table stakes in the sdk with configurable limits per tool and global limits per client.
yeah and it gets worse when you consider multi-tenant setups where one agent can dos shared mcp resources for everyone else. saw this at work last year with a different agent framework - one bad workflow hammered a shared db tool and took down 6 other teams' agents
ship per-tool rate limits yesterday