de en es ja ko ru zh

Sentry MCP

Name: Sentry MCP
Author: getsentry

Official

by getsentry

Overview Schema Related Servers Score Discussions

TypeScript

Hybrid

sentry-mcp

El servicio MCP de Sentry está diseñado principalmente para agentes de codificación con intervención humana (human-in-the-loop). Nuestra selección de herramientas y prioridades se centran en los flujos de trabajo de los desarrolladores y en casos de uso de depuración, en lugar de proporcionar un servidor MCP de propósito general para toda la funcionalidad de Sentry.

Este servidor MCP remoto actúa como middleware para la API de Sentry, optimizado para asistentes de codificación como Cursor, Claude Code y herramientas de desarrollo similares. Se basa en el trabajo de Cloudflare hacia MCPs remotos.

Introducción

Encontrarás todo lo que necesitas saber visitando el servicio desplegado en producción:

https://mcp.sentry.dev

Si buscas contribuir, aprender cómo funciona o ejecutar esto para una instancia de Sentry autohospedada, continúa leyendo.

Plugin de Claude Code

Instálalo como un plugin de Claude Code para la delegación automática de subagentes:

claude plugin marketplace add getsentry/sentry-mcp
claude plugin install sentry-mcp@sentry-mcp

Esto proporciona un subagente sentry-mcp al que Claude delega automáticamente cuando preguntas sobre errores, problemas, trazas o rendimiento de Sentry.

Para variantes de herramientas y características futuras:

claude plugin install sentry-mcp@sentry-mcp-experimental

Stdio vs Remoto

Aunque este repositorio se centra en actuar como un servicio MCP, también admitimos un transporte stdio. Esto sigue siendo un trabajo en progreso, pero es la forma más fácil de adaptar y ejecutar el MCP contra una instalación de Sentry autohospedada.

Nota: Las herramientas de búsqueda impulsadas por IA (search_events, search_issues, etc.) requieren un proveedor de LLM (OpenAI o Anthropic). Estas herramientas utilizan procesamiento de lenguaje natural para traducir consultas a la sintaxis de búsqueda de Sentry. Sin un proveedor configurado, estas herramientas específicas no estarán disponibles, pero todas las demás funcionarán normalmente.

Para utilizar el transporte stdio, necesitarás crear un Token de Autenticación de Usuario en Sentry con los alcances necesarios. Al momento de escribir esto, es:

org:read
project:read
project:write
team:read
team:write
event:write

Lanza el transporte:

npx @sentry/mcp-server@latest --access-token=sentry-user-token

¿Necesitas conectarte a un despliegue autohospedado? Añade --host (solo el nombre de host, p. ej., --host=sentry.example.com) cuando ejecutes el comando.

Algunas características (como Seer) pueden no estar disponibles en instancias autohospedadas. Puedes desactivar habilidades específicas para evitar que se expongan herramientas no compatibles:

npx @sentry/mcp-server@latest --access-token=TOKEN --host=sentry.example.com --disable-skills=seer

Variables de entorno

SENTRY_ACCESS_TOKEN=         # Required: Your Sentry auth token

# LLM Provider Configuration (required for AI-powered search tools)
EMBEDDED_AGENT_PROVIDER=     # Required: 'openai' or 'anthropic'
OPENAI_API_KEY=              # Required if using OpenAI
ANTHROPIC_API_KEY=           # Required if using Anthropic

# Optional overrides
SENTRY_HOST=                 # For self-hosted deployments
MCP_DISABLE_SKILLS=          # Disable specific skills (comma-separated, e.g. 'seer')

Importante: Configura siempre EMBEDDED_AGENT_PROVIDER para especificar explícitamente tu proveedor de LLM. La detección automática basada solo en claves API está obsoleta y se eliminará en una futura versión. Consulta docs/embedded-agents.md para ver opciones de configuración detalladas.

Ejemplo de configuración de MCP

{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": ["@sentry/mcp-server"],
      "env": {
        "SENTRY_ACCESS_TOKEN": "your-token",
        "EMBEDDED_AGENT_PROVIDER": "openai",
        "OPENAI_API_KEY": "sk-..."
      }
    }
  }
}

Si dejas la variable host sin configurar, la CLI apunta automáticamente al servicio SaaS de Sentry. Solo establece la anulación cuando operes un Sentry autohospedado.

Para instancias autohospedadas que no admiten Seer:

{
  "mcpServers": {
    "sentry": {
      "command": "npx",
      "args": ["@sentry/mcp-server"],
      "env": {
        "SENTRY_ACCESS_TOKEN": "your-token",
        "SENTRY_HOST": "sentry.example.com",
        "MCP_DISABLE_SKILLS": "seer"
      }
    }
  }
}

Inspector MCP

MCP incluye un Inspector para probar fácilmente el servicio:

pnpm inspector

Introduce la URL del servidor MCP (http://localhost:5173) y pulsa conectar. Esto debería activar el flujo de autenticación para ti.

Nota: Si tienes problemas con tu flujo OAuth al acceder al inspector en 127.0.0.1, intenta usar localhost visitando http://localhost:6274.

Related MCP server: Sentry MCP Server

Desarrollo local

Para contribuir con cambios, necesitarás configurar tu entorno local:

Configurar el entorno y las habilidades del agente:
```
make setup-env  # Creates .env files and installs shared agent skills
```
Esto también ejecuta npx @sentry/dotagents install para instalar habilidades compartidas desde getsentry/skills en .agents/skills/ (vinculadas simbólicamente en .claude/skills y .cursor/skills). Si necesitas actualizar las habilidades más tarde, ejecútalo directamente:
```
npx @sentry/dotagents install
```
Crear una aplicación OAuth en Sentry (Configuración => API => Aplicaciones):
- URL de inicio: http://localhost:5173
- URIs de redirección autorizadas: http://localhost:5173/oauth/callback
- Anota tu ID de cliente y genera un secreto de cliente
Configurar tus credenciales:
- Edita .env en el directorio raíz y añade tu OPENAI_API_KEY
- Edita packages/mcp-cloudflare/.env y añade:
  - SENTRY_CLIENT_ID=tu_id_de_cliente_sentry_de_desarrollo
  - SENTRY_CLIENT_SECRET=tu_secreto_de_cliente_sentry_de_desarrollo
  - COOKIE_SECRET=mi-super-secreto-cookie
Iniciar el servidor de desarrollo:
```
pnpm dev
```

Verificar

Ejecuta el servidor localmente para que esté disponible en http://localhost:5173

pnpm dev

Para probar el servidor local, introduce http://localhost:5173/mcp en el Inspector y pulsa conectar. Una vez que sigas las instrucciones, podrás "Listar herramientas".

Pruebas

Se incluyen tres conjuntos de pruebas: pruebas unitarias, evaluaciones y pruebas manuales.

Las pruebas unitarias se pueden ejecutar usando:

pnpm test

Las evaluaciones requieren un archivo .env en la raíz del proyecto con algo de configuración:

# .env (in project root)
OPENAI_API_KEY=  # Also required for AI-powered search tools in production

Nota: El archivo .env raíz proporciona valores predeterminados para todos los paquetes. Los paquetes individuales pueden tener sus propios archivos .env para anular estos valores durante el desarrollo.

Una vez hecho esto, puedes ejecutarlas usando:

pnpm eval

Pruebas manuales (preferidas para probar cambios en MCP):

# Test with local dev server (default: http://localhost:5173)
pnpm -w run cli "who am I?"

# Test agent mode (use_sentry tool only)
pnpm -w run cli --agent "who am I?"

# Test against production
pnpm -w run cli --mcp-host=https://mcp.sentry.dev "query"

# Test with local stdio mode (requires SENTRY_ACCESS_TOKEN)
pnpm -w run cli --access-token=TOKEN "query"

Nota: La CLI utiliza http://localhost:5173 por defecto. Anula con --mcp-host o establece la variable de entorno MCP_URL.

Guías de pruebas integrales:

Pruebas Stdio: Consulta docs/testing-stdio.md para obtener una guía completa sobre cómo construir, ejecutar y probar la implementación stdio (IDEs, Inspector MCP)
Pruebas remotas: Consulta docs/testing-remote.md para obtener una guía completa sobre cómo probar el servidor remoto (OAuth, interfaz web, cliente CLI)

Notas de desarrollo

Revisión de código automatizada

Este repositorio utiliza herramientas de revisión de código automatizadas (como Cursor BugBot) para ayudar a identificar posibles problemas en las solicitudes de extracción (pull requests). Estas herramientas proporcionan comentarios y sugerencias útiles, pero no recomendamos hacer que estas comprobaciones sean obligatorias, ya que la precisión aún está evolucionando y puede producir falsos positivos.

Las revisiones automatizadas deben tratarse como:

✅ Sugerencias útiles a considerar durante la revisión del código
✅ Puntos de partida para la discusión y mejora
❌ No son requisitos bloqueantes para fusionar PRs
❌ No son reemplazos para la revisión de código humana

Al abordar los comentarios automatizados, céntrate en las preocupaciones subyacentes en lugar de seguir estrictamente cada sugerencia.

Documentación para colaboradores

¿Buscas contribuir o explorar el mapa completo de documentación? Consulta CLAUDE.md (también disponible como AGENTS.md) para conocer los flujos de trabajo de los colaboradores y el índice completo de documentos. La carpeta docs/ contiene las guías por tema y los archivos .md integrados en las herramientas.

Available Tools

7 tools

create_projectB

Create a new project in Sentry, giving you access to a new SENTRY_DSN.

Use this tool when you need to:

Create a new project in a Sentry organization

ParametersJSON Schema

Name	Required	Description
`name`	Yes	The name of the project to create. Typically this is commonly the name of the repository or service. It is only used as a visual label in Sentry.
`organizationSlug`	No	The organization's slug. This will default to the first org you have access to.
`platform`	No	The platform for the project (e.g., python, javascript, react, etc.)
`teamSlug`	Yes	The team's slug. This will default to the first team you have access to.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the outcome ('giving you access to a new SENTRY_DSN') but doesn't disclose behavioral traits such as required permissions, rate limits, whether the operation is idempotent, or error handling. This is a significant gap for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized with two sentences and a bullet point, front-loaded with the main purpose. It avoids redundancy, though the bullet point could be integrated more smoothly for better flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., permissions, side effects) and return values, leaving gaps for an AI agent to operate effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all 4 parameters. The description adds no parameter-specific information beyond what's in the schema, resulting in a baseline score of 3 as it doesn't compensate but doesn't detract either.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('Create') and resource ('new project in Sentry'), specifying it provides access to a new SENTRY_DSN. However, it doesn't explicitly differentiate from sibling tools like 'create_team' beyond mentioning the resource type, missing a direct comparison.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a bullet point stating 'Use this tool when you need to: - Create a new project in a Sentry organization,' which implies context but lacks explicit guidance on when to use alternatives (e.g., 'list_projects' for viewing existing ones) or prerequisites like required permissions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

create_teamB

Create a new team in Sentry.

Use this tool when you need to:

Create a new team in a Sentry organization

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	The name of the team to create.
`organizationSlug`	No	The organization's slug. This will default to the first org you have access to.

TDQS

B3.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states it 'creates' a new team. It lacks details on permissions required, whether the operation is idempotent, what happens on duplicate names, or error conditions. For a mutation tool with zero annotation coverage, this is insufficient behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief and front-loaded with the main purpose, followed by a usage guideline. Both sentences are relevant, though the second sentence could be more efficiently integrated. There's minimal waste, but it's not perfectly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given this is a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., team ID, success confirmation), error handling, or dependencies like required permissions. For a create operation, this leaves significant gaps for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents both parameters ('name' and 'organizationSlug') adequately. The description adds no additional parameter information beyond what's in the schema, meeting the baseline for high coverage but not enhancing understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Create a new team') and resource ('in Sentry'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'create_project' beyond mentioning 'team' vs 'project', which is implicit but not explicit about when to choose one over the other.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a bullet point stating 'Use this tool when you need to: Create a new team in a Sentry organization', which gives basic context. However, it doesn't specify when NOT to use it or mention alternatives like 'list_teams' for checking existing teams, leaving some ambiguity about usage scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_error_detailsA

Retrieve error details from Sentry for a specific Issue ID, including the stacktrace and error message. Either issueId or issueUrl MUST be provided.

Use this tool when you need to:

Investigate a specific production error
Access detailed error information and stacktraces from Sentry

ParametersJSON Schema

Name	Required	Description
`issueId`	No	The Issue ID. e.g. `PROJECT-1Z43`
`issueUrl`	No	The URL of the issue to retrieve details for.
`organizationSlug`	No	The organization's slug. This will default to the first org you have access to.

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation ('Retrieve'), which is helpful. However, it doesn't mention important behavioral aspects like authentication requirements, rate limits, error handling, or what happens when neither issueId nor issueUrl is provided despite stating one MUST be provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is perfectly structured with a clear purpose statement followed by a bulleted list of usage scenarios. Every sentence earns its place, with no redundant information. The constraint about required parameters is efficiently integrated into the first sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 3 parameters, no annotations, and no output schema, the description provides adequate but incomplete coverage. It clearly explains the purpose and usage scenarios, but lacks details about authentication, error responses, rate limits, and the format/structure of the returned error details. The absence of an output schema means the description should ideally provide more information about what the tool returns.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description adds the critical constraint that 'Either issueId or issueUrl MUST be provided,' which provides important semantic context beyond the schema. However, it doesn't explain the relationship between these parameters or provide additional context about the organizationSlug default behavior beyond what's in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific action ('Retrieve error details'), resource ('from Sentry'), and scope ('for a specific Issue ID'). It explicitly mentions what information is included ('stacktrace and error message'), distinguishing it from sibling tools like search_errors_in_file which appears to search rather than retrieve details for a specific issue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage scenarios ('when you need to investigate a specific production error' and 'access detailed error information and stacktraces from Sentry'), giving good context for when to use this tool. However, it doesn't explicitly state when NOT to use it or directly compare it to alternatives like search_errors_in_file, which would be needed for a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_organizationsB

List all organizations that the user has access to in Sentry.

Use this tool when you need to:

View all organizations in Sentry

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It mentions the scope ('all organizations that the user has access to'), which is useful, but lacks details on behavioral traits like pagination, rate limits, authentication needs, or response format. For a tool with zero annotation coverage, this is insufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the main purpose in the first sentence, followed by a bullet point for usage. It's efficient with minimal waste, though the bullet point could be integrated more seamlessly into the flow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations, no output schema, and 0 parameters, the description is adequate for a simple list tool but lacks completeness. It doesn't explain what the return value looks like (e.g., list of objects with fields) or any constraints, which could hinder agent effectiveness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here, but since there are no params, it doesn't compensate for any gaps. Baseline is 4 as per rules for 0 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('List') and resource ('organizations'), specifying that it returns all organizations the user has access to in Sentry. It distinguishes from siblings like 'list_projects' and 'list_teams' by focusing on organizations, but doesn't explicitly contrast with them in the text.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a usage scenario ('when you need to view all organizations in Sentry'), which gives implied context. However, it doesn't explicitly state when NOT to use this tool or name alternatives (e.g., when to use 'list_projects' instead), leaving some guidance gaps.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_projectsB

Retrieve a list of projects in Sentry.

Use this tool when you need to:

View all projects in a Sentry organization

ParametersJSON Schema

Name	Required	Description	Default
`organizationSlug`	No	The organization's slug. This will default to the first org you have access to.

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden for behavioral disclosure. While it indicates this is a retrieval/read operation, it doesn't mention important behavioral aspects like pagination, rate limits, authentication requirements, or what happens when organizationSlug isn't provided. The description is insufficient for a tool with no annotation coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately concise with two sentences that directly address purpose and usage. It's front-loaded with the core purpose and follows with specific usage scenarios. There's minimal wasted verbiage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no annotations and no output schema, the description is incomplete. It doesn't explain what the return format looks like, whether results are paginated, or what authentication context is required. Given the lack of structured metadata, the description should provide more operational context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents the single parameter. The description doesn't add any additional semantic context about the parameter beyond what's in the schema. This meets the baseline expectation when schema coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Retrieve' and resource 'list of projects in Sentry', making the purpose unambiguous. However, it doesn't explicitly distinguish this tool from sibling tools like 'list_organizations' or 'list_teams' beyond mentioning projects specifically.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool ('when you need to view all projects in a Sentry organization'), which is helpful. However, it doesn't mention when NOT to use it or provide alternatives for more specific project queries that might be needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_teamsA

List all teams in an organization in Sentry.

Use this tool when you need to:

View all teams in a Sentry organization

ParametersJSON Schema

Name	Required	Description	Default
`organizationSlug`	No	The organization's slug. This will default to the first org you have access to.

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic action ('List all teams') without mentioning behavioral traits like pagination, rate limits, authentication needs, or what happens if no organization slug is provided (defaulting to the first org). This leaves significant gaps for a tool that likely interacts with an API.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded, with the core purpose stated first followed by concise usage guidelines in bullet points. Every sentence earns its place without redundancy, making it efficient and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is minimally complete for a basic list operation. However, it lacks details on output format, error handling, or dependencies (e.g., needing an organization slug from 'list_organizations'), which could be helpful for an agent in this context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, with the parameter 'organizationSlug' clearly documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, so it meets the baseline of 3 for high schema coverage without compensating value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('List') and resource ('all teams in an organization in Sentry'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_organizations' or 'list_projects' beyond the resource type, which prevents a perfect score.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines with bullet points specifying when to use this tool ('View all teams in a Sentry organization'), which gives clear context. However, it doesn't mention when not to use it or name alternatives (e.g., using 'list_organizations' first to get the organization slug), so it falls short of a perfect score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_errors_in_fileA

Search for errors recently occurring in a specific file. This is a suffix based search, so only using the filename or the direct parent folder of the file. The parent folder is preferred when the filename is in a subfolder or a common filename.

Use this tool when you need to:

Search for production errors in a specific file
Analyze error patterns and frequencies
Find recent or frequently occurring errors.

ParametersJSON Schema

Name	Required	Description	Default
`filename`	Yes	The filename to search for errors in.
`organizationSlug`	No	The organization's slug. This will default to the first org you have access to.
`sortBy`	No	Sort the results either by the last time they occurred or the count of occurrences.	last_seen

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context about the search being 'suffix based' and preferring parent folders for subfolders/common filenames, which helps the agent understand how to structure queries. However, it doesn't mention rate limits, authentication needs, or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear opening sentence explaining the tool's function, followed by a usage guidelines section. It's appropriately sized and front-loaded, though the bulleted list could be slightly more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (3 parameters, no output schema, no annotations), the description provides good contextual completeness. It explains the search behavior and usage scenarios well, though it could benefit from mentioning what the output looks like since there's no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema, maintaining the baseline score of 3 where the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('search for errors') and resources ('in a specific file'), and distinguishes it from siblings by focusing on file-based error searching rather than project/team management or general listing operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage guidelines with a bulleted list of when to use this tool ('search for production errors in a specific file', 'analyze error patterns', 'find recent/frequent errors'), though it doesn't explicitly state when not to use it or name alternatives among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0

Disambiguation4/5

Most tools have distinct purposes, such as create_project vs. list_projects, but get_error_details and search_errors_in_file could potentially overlap in error investigation scenarios, which might cause slight confusion. Overall, the boundaries are clear with only minor ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun naming pattern using snake_case, such as create_project, list_organizations, and search_errors_in_file. This uniformity makes the tool set predictable and easy to understand.

Tool Count4/5

With 7 tools, the count is reasonable for a Sentry-focused server, covering core operations like project, team, and error management. However, it feels slightly thin as it lacks update or delete operations, which are common in such domains.

Completeness3/5

The tool set covers creation and listing for projects, teams, and organizations, plus error retrieval and search, but it has notable gaps. Missing update/delete tools for projects and teams, and no error resolution or comment features, limit full lifecycle coverage for Sentry's domain.

Maintenance

ActivityActive

ResponsivenessResponsive

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Telnyx A
com.telnyx.api
The Telnyx MCP server is an official implementation of the Model Context Protocol that enables AI clients (like Claude Desktop, Cursor, and OpenAI Agents) to interact with Telnyx's telephony, messaging, and AI assistant APIs. It provides comprehensive capabilities including making and managing phone calls, sending SMS/MMS messages, purchasing and configuring phone numbers, creating AI assistants with custom instructions, managing cloud storage buckets, scraping and embedding website content, and handling integration secrets. The server exists as both a local implementation and a remotely hosted version, allowing developers to integrate real-world communication infrastructure directly into AI applications.
Communication Cloud Platforms Cloud Storage
62
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216

Related MCP Servers

MCP Sentry
Monitoring Databases
MCP-100
F
license
B
quality
D
maintenance
A Model Context Protocol server that retrieves and analyzes Sentry.io issues, allowing users to inspect error reports, stacktraces, and debugging information from their Sentry account.
Updated a year ago (2025-07-18 09:02 UTC)
2
22
Sentry MCP Server
Monitoring Project Management Observability
codyde
F
license
B
quality
F
maintenance
A Model Context Protocol server that enables AI assistants to interact with Sentry for error tracking and monitoring, allowing retrieval and analysis of error data, project management, and performance monitoring through the Sentry API.
Updated a year ago (2025-03-18 23:39 UTC)
11
21
MCP Server Sentry
Monitoring Observability
Zzzccs123
F
license
Not graded
quality
D
maintenance
A TypeScript implementation of a Model Context Protocol server that connects to Sentry error tracking service, allowing AI models to query and analyze error reports and events.
Updated a year ago (2025-03-19 09:38 UTC)
31
Sentry MCP Server
Monitoring Developer Tools Autonomous Agents
FaureAlexis
A
license
Not graded
quality
D
maintenance
A TypeScript server that allows AI agents to access, retrieve, and analyze Sentry error data through the Modern Context Protocol.
Updated 2 years ago (2025-03-03 11:12 UTC)
44
2
MIT

Appeared in Searches

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/getsentry/sentry-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server