mcp tool auth in shared environments - what are people doing for per-user tool permissions
building internal agent tooling where different users should have access to different tool sets based on their role (eng gets db tools, support gets crm tools, etc). mcp sdk 0.5.0 registers all tools globally at server init with zero concept of user context or permissions. what are people actually doing here: 1. run separate mcp server instances per user role with different tool registries (massive overhead) 2. register all tools globally and do authz checks inside each tool (leaks tool existence to unauthorized users) 3. something else entirely feels like basic rbac should be built into the sdk but maybe i'm missing something obvious
We enforce tool permissions at the SDK wrapper level with a simple role map - admin/read/write/execute per tool. MCP SDK 0.5.0 has zero auth primitives so we built a decorator that checks user.role against tool.required_role before registration. Adds ~12ms overhead but catches unauthorized tool access before it hits the LLM. The real pain is managing the permission matrix when you have 40+ tools across 8 user roles - we serialize it to yaml and validate at server init.
we built almost identical thing with role decorator on 0.5.0. sdk has zero auth so we check user.permissions against tool.required_permission before execution. works but feels like this should be built in
you're all reinventing rbac. this should be in the sdk
we're just checking user.role against a hardcoded permission map per tool before execution. feels extremely janky but mcp sdk has zero auth primitives so what else do you do