Route stdio MCP tool calls to the stored account that knows the org

Abierto
  • ¿Algo no está bien?
#1,756 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
node.js, typescript
Área
api, authentication, cli

Línea de trabajo

Start with the dependency-direction rule in AGENTS.md, then read ServerContext in packages/mcp-core/src/types.ts, apiServiceFromContext(), and the CLI host in packages/cli/src/lib/mcp.ts. Trace selectAccountForOrg in packages/cli/src/lib/db/auth.ts and region handling in packages/cli/src/lib/region.ts and internal/tool-helpers/resolve-region-url.ts. Run the relevant MCP and CLI tests; done means org-scoped calls use the owning account safely, cross-org tools merge results, and hosted/static-token behavior remains unchanged.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

The CLI stores several accounts and picks the right one for each command based on the targeted organization (selectAccountForOrg in packages/cli/src/lib/db/auth.ts, called from resolveOrgRegion in packages/cli/src/lib/region.ts). The stdio MCP server (@sentry/mcp-server and sentry mcp, which share the CLI's credential store after #1731) does not.

The server resolves one effective account at startup and uses it for every tool call. A token refresh after a 401 stays on that same account. Asking about an org that belongs to another stored login fails. The only workarounds are sentry auth switch plus a restart, or configuring a second MCP server with a different SENTRY_HOST or a static SENTRY_ACCESS_TOKEN.

Why it doesn't work today

  • ServerContext in mcp-core carries a single accessToken: string (packages/mcp-core/src/types.ts). All tools build their API client with apiServiceFromContext() (about 63 call sites), and the region cache (internal/tool-helpers/resolve-region-url.ts) reads the same token.
  • MCP tools use mcp-core's API client, not the CLI's, so the CLI's org-based selection never runs.
  • mcp-core must not import the CLI (see the dependency-direction rule in AGENTS.md), and the hosted MCP has one OAuth grant per session. So this has to be an optional capability that only the stdio host provides.

Proposed approach

  1. mcp-core: add an optional resolver to ServerContext, e.g. resolveCredential({ organizationSlug }) => Promise<{ accessToken, sentryHost, sentryProtocol }>. apiServiceFromContext() takes the org and uses the resolver when present; otherwise it uses accessToken. Key the region cache by the resolved credential. The hosted MCP stays unchanged.
  2. CLI host (packages/cli/src/lib/mcp.ts): implement the resolver with the selectAccountForOrg rules, running each call inside withStoredAccount(). That function already isolates account scope per call through withEnv and AsyncLocalStorage, so overlapping tool calls are safe. Refresh-on-401 targets the account that made the call. An unknown org falls back to the active account. One tool call never mixes identities.
  3. Cross-org tools (find_organizations, whoami): query every usable account and merge the results, as sentry org list does with listUsableAccountsInScope(). The CLI already records which account saw each org in the regions cache (packages/cli/src/lib/db/regions.ts), so later calls route automatically.
  4. Opt-outs and pins: --access-token / SENTRY_ACCESS_TOKEN disables routing. --organization-slug picks the account once at startup. An explicit server (SENTRY_HOST/SENTRY_URL) limits candidates to accounts on that server, matching the CLI.

An alternative would route inside an injected fetch by parsing /organizations/{slug}/ from request URLs. It touches fewer files, but it is implicit and misses endpoints whose paths do not include the org. The explicit resolver is preferred.

Scope

  • First version: route only between accounts on the same server.
  • Later: mixing self-hosted and sentry.io accounts in one server needs a host per account and the region-URL validation (validateRegionUrl) checked against the right server.

Acceptance

  • With two stored sentry.io accounts that each own a different org, one running stdio server can call org-scoped tools on both orgs without auth switch or a restart.
  • find_organizations lists orgs from all usable accounts.
  • A 401 refreshes only the account that made the call.
  • The hosted MCP and static-token setups behave as before.
  • Tests cover concurrent tool calls for different orgs and verify that each call sends its own account's token.

Related

  • #1731: @sentry/mcp-server as a slim bundle that shares CLI auth (prerequisite)
  • #1669: shared API layer proposal; task group 11 (task 11.4, CLI capabilities injected into mcp-core) is the natural home
  • #1396: CLI multi-account mode (done)
  • #845: earlier --profile request for the stdio transport, closed as not planned; this approach needs no per-process profiles

via BYK.

--

View Session in Sentry

Lenguaje dominante
TypeScript
Estrellas
949
Forks
171
Merge medio
1 d 2 h
PR fusionados (30 d)
261

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getsentry/toolkit

Todos los issues de getsentry/toolkit

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.