Building multi-sentry-mcp: Multi-Org Sentry Monitoring for AI-Assisted Development
How I solved cross-organization Sentry isolation for a venture studio managing multiple startups
When you're running a venture studio, you don't have one codebase. You have five, ten, sometimes more, each belonging to a different portfolio company, each with its own Sentry organization, its own error landscape, and its own team that needs to be kept in the loop without seeing the others' data. At IdeaCrafters, I manage the technical oversight for multiple startups simultaneously. Claude Code became a core part of that workflow through MCP (the Model Context Protocol), but the official Sentry MCP server had a hard limitation: one organization per instance. For a single-product team, that's fine. For a venture studio, it's a dealbreaker. So I built multi-sentry-mcp, a configuration generator that spawns isolated Sentry MCP sessions per organization, with zero cross-org token leakage.
The Problem: One Org Per Instance
Sentry's official @sentry/mcp-server is well-built. It gives Claude Code the ability to search issues, analyze errors with Seer, triage bugs, and manage projects, all through natural conversation. But it takes a single --organization-slug flag at startup. If you need access to three Sentry organizations, you need three manually configured MCP server entries, each with its own token, its own environment variables, and its own set of enabled skills. Maintaining that by hand across Claude Desktop, Claude Code, and Cursor configurations is tedious and error-prone.
The real risk isn't inconvenience. It's security. A misconfigured token in the wrong server entry means one company's error data is accessible through another company's session. In a venture studio where portfolio companies may be competitors, or where exit and handoff processes require clean separation, that kind of leakage isn't just a bug. It's a breach of trust.
The Solution: A Registry-Driven Config Generator
Rather than forking or wrapping the official Sentry MCP server, I built a tool that generates the correct multi-org configuration from a single registry file. The approach is deliberately simple: define your portfolio once, validate it, and output everything needed to run isolated MCP sessions.
The registry is a JSON file that describes your portfolio:
1{ 2 "portfolio": [ 3 { 4 "id": "acme-web", 5 "display_name": "Acme Web", 6 "sentry_org_slug": "acme-web", 7 "sentry_project_slug": "acme-web-app", 8 "token_env_var": "SENTRY_TOKEN_ACME_WEB", 9 "ai_search": true, 10 "active": true, 11 "skills": ["inspect", "seer", "triage"] 12 }, 13 { 14 "id": "widgets-inc", 15 "display_name": "Widgets Inc", 16 "sentry_org_slug": "widgets-inc", 17 "token_env_var": "SENTRY_TOKEN_WIDGETS_INC", 18 "ai_search": false, 19 "active": true 20 } 21 ], 22 "shared": { 23 "anthropic_key_env_var": "ANTHROPIC_API_KEY", 24 "embedded_agent_provider": "anthropic" 25 } 26}
Running npm run generate produces three artifacts: a mcp-servers.json block you paste into your Claude config, a .env.template listing every token variable you need to fill, and optionally, standalone handoff packages for individual companies.
Design Decisions
Wrapping vs. Generating
The first design decision was whether to build a custom MCP server that proxies requests to Sentry, or to generate configuration for the official server. I chose generation for three reasons.
First, the official @sentry/mcp-server already handles the Sentry API correctly, including AI-powered search with Seer. Reimplementing that would be duplicating effort and introducing bugs. Second, generating config means every org gets its own process with its own token, enforcing isolation at the OS level rather than in application code. Third, when Sentry updates their MCP server (new tools, new skills, bug fixes), every organization in the portfolio gets the update automatically through @sentry/mcp-server@latest.
Per-Company Skill Control
Not every portfolio company needs the same level of access. An early-stage startup might only need inspect to search issues. A company approaching a compliance audit might need triage to update issue status, but shouldn't have project-management enabled. The registry supports an optional skills array per company that maps directly to the official server's skill system:
| Skill | What It Enables |
|---|---|
inspect | Search issues, events, releases, projects |
seer | AI-powered issue analysis |
triage | Update issue status and assignments |
docs | Search Sentry documentation |
project-management | Create/update projects, teams, DSNs |
If no skills array is specified, the official defaults apply. This gives the venture lead fine-grained control without requiring the portfolio companies to understand the MCP skill system.
Handoff Packages
Venture studios have exits. When a portfolio company graduates, gets acquired, or spins off, they need to take their tooling with them. The --handoff flag generates a standalone package for a single company: its own mcp-config.json, its own .env.template, and a step-by-step README explaining how to set up Sentry MCP independently. No reference to the parent registry, no shared keys, no dependency on IdeaCrafters infrastructure.
1npm run generate -- --handoff acme-web
This produces a output/handoff/sentry-mcp-acme-web/ directory that the departing team can drop into their own setup. It's a small feature, but it reflects a reality of venture studio operations that most developer tools don't account for.
Implementation Highlights
Zero Dependencies
The entire tool is built with TypeScript and nothing else. No runtime dependencies, only @types/node and typescript as dev dependencies. The validator, generator, and CLI are all plain TypeScript compiled to ES2022. This was intentional: a configuration generator should be trivial to audit and have no supply chain surface area.
Validation Before Generation
The validator runs a comprehensive check before any files are written. It catches duplicate organization slugs, duplicate token variable names, malformed token patterns (must match SENTRY_TOKEN_[A-Z_]+), missing required fields, and logical inconsistencies like enabling AI search without configuring an Anthropic key. Errors are fatal; warnings (like a missing display_name) are logged but don't block generation. This prevents partial or broken configs from ever reaching the output directory.
Environment Variable References
The generated config uses ${VARIABLE_NAME} syntax rather than inlining actual tokens. MCP clients resolve these references at runtime from the user's environment. This means the generated mcp-servers.json can be committed to a shared repo or config management system without exposing secrets. Tokens live in .env files, secrets managers, or CI/CD variables, never in the config itself.
What It Looks Like in Practice
With multi-sentry-mcp configured, a typical debugging session in Claude Code looks like this:
"Check the Sentry issues for Acme Web, anything critical in the last 24 hours? Also look at Widgets Inc, they reported a payment flow regression yesterday."
Claude Code routes each request to the correct MCP server instance. The Acme Web query hits sentry-acme-web with its own token. The Widgets Inc query hits sentry-widgets-inc with a completely separate token. No org can see the other's data, and the assistant doesn't need to be told which token to use. It's handled by the config.
For triage, it goes further. If Acme Web has triage enabled in its skills, the assistant can update issue status directly: "Mark that Acme Web payment timeout as resolved, the fix shipped in yesterday's release." If Widgets Inc only has inspect, the assistant can search and report but can't modify anything. The skill boundaries are enforced at the MCP level, not by hoping the LLM respects a system prompt.
Open Source and What's Next
I open-sourced multi-sentry-mcp under the IdeaCrafters GitHub organization because the multi-org problem isn't unique to venture studios. Agencies, consultancies, and freelancers managing multiple client Sentry accounts hit the same wall. The tool is MIT-licensed and designed to be useful out of the box with a single npm run generate command.
There are clear directions for extension. A watch mode that regenerates config when the registry changes would streamline the workflow for growing portfolios. Integration with secrets managers like 1Password or Vault could automate token provisioning. And as the MCP ecosystem matures, there may be opportunities to build similar multi-org generators for other single-tenant MCP servers.
If you manage multiple Sentry organizations and use Claude Code, Claude Desktop, or Cursor, the tool is ready to use. Contributions, issues, and feedback are welcome on GitHub.