Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@azure-devops-mcp-server show me my active bugs"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Servidor MCP (Model Context Protocol) para Azure DevOps, implementado sobre stdio nativo —
sin SDK de MCP ni dependencias externas más allá de dotenv. Expone Azure Boards, Azure
Repos y Azure Pipelines como tools invocables por Claude.
pnpm install # instalar dependencias
pnpm start # iniciar servidor MCP
pnpm dev # iniciar con recarga automática (node --watch)Variables de entorno requeridas (.env, ver .env.example):
Variable | Descripción |
| Personal Access Token de Azure DevOps |
| Nombre de la organización (ej. |
| (Opcional) usuario para |
Related MCP server: Azure DevOps MCP Server
src/boards/index.jsTool | Qué hace | Ejemplo básico |
| Lista los bugs activos asignados al usuario configurado en |
|
| Obtiene un work item por ID (título, estado, descripción, repro steps, discussion, etc.). |
|
| Ejecuta una consulta WIQL y devuelve |
|
| Cambia el estado de un work item. |
|
| Crea un work item ( |
|
src/repos/index.jsTool | Qué hace | Ejemplo básico |
| Lista los repositorios de un proyecto (id, nombre, rama por defecto). |
|
| Busca texto en el código vía Azure DevOps Code Search (wildcards, AND/OR/NOT). |
|
| Lee el contenido de un archivo de un repo en una rama dada. |
|
| Crea una rama nueva desde otra existente. |
|
| Hace commit de un archivo modificado en una rama existente. |
|
| Abre un PR entre dos ramas. |
|
| Consulta estado ( |
|
src/pipelines/index.jsTool | Qué hace | Ejemplo básico |
| Lista los pipelines del proyecto. |
|
| Últimas ejecuciones de un pipeline (estado, resultado, fechas). |
|
src/services/index.jsTool | Qué hace | Ejemplo básico |
| Hook de cierre: persiste un reporte en |
|
Todos los tools de proyecto (Repos/Pipelines/create_work_item) aceptan project — si se
omite, usar el nombre exacto del proyecto Azure DevOps (no hay default global, cada llamada
project-scoped lo exige). Los tools de Boards de solo-lectura/escritura de work items
(get_work_item, query_work_items, update_work_item_state) son org-scoped: el ID de
work item es único a nivel organización, no requieren project.
Tarea | Agente | Qué hace |
Resolver/investigar un bug por ID |
| Lee el work item, investiga el código ( |
Ejecutar el fix y abrir el PR |
| Recibe el plan de |
Verificar pipeline y cerrar el bug tras mergear el PR |
| Verifica el resultado del pipeline post-merge; si pasó, cierra el work item y comenta la traza completa (duraciones, tokens). |
Crear una historia de usuario o tarea nueva, con detalle profesional |
| Investiga el código fuente relevante (repo Azure DevOps y/o ruta local), redacta introducción/objetivo/alcance/criterios de aceptación, y crea el work item directamente con |
Desglosar una User Story existente en Tasks |
| Lee la historia, investiga el repositorio asociado, propone/completa Tasks con |
Ver CLAUDE.md para el flujo paso a paso de cada uno (bugs: diagnóstico → fix/PR →
verificación de pipeline; historias: confirmación de contexto → story-writer; desglose de
tareas: confirmación de contexto → task-writer).
Crea una rama nueva desde otra existente
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) | |
| branchName | Yes | Nombre de la nueva rama | |
| repositoryId | Yes | ID o nombre del repositorio | |
| sourceBranch | Yes | Rama de origen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It states 'creates' (a mutation), but does not disclose required permissions, side effects (e.g., no checkout), or error conditions. The description is too minimal to inform safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but lacks structure and sufficiently detailed information. It could be improved by front-loading key information and adding more context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four parameters, no output schema, and no annotations, the description should provide more detail about return values, possible errors, or the creation process. The current text is too brief to be fully actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all four parameters, so the schema itself already explains each parameter. The description adds no additional meaning beyond what is in the schema, meriting a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'creates' and the resource 'branch' clearly, and it distinguishes from sibling tools like create_pull_request and create_work_item by indicating that it creates a branch from an existing one. However, it could be more specific about the context (e.g., Azure DevOps Git branch).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like push_commit or update_work_item_state. The description lacks any context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea un Pull Request entre dos ramas
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Título del PR | |
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) | |
| description | No | Descripción opcional | |
| repositoryId | Yes | ID o nombre del repositorio | |
| sourceBranch | Yes | Rama con los cambios | |
| targetBranch | Yes | Rama destino (ej: main) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must bear the burden. It provides no details on side effects, authorization needs, rate limits, or what happens on conflict. Merely stating 'creates' 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence. It is well-structured for its minimal length, though it could include more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no behavioral details. The description lacks information about return values, error handling, or prerequisites, making it incomplete for a tool with 6 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description adds no value beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Crea un Pull Request entre dos ramas' clearly states the verb (creates) and the resource (pull request between two branches), which is specific and distinguishes it from siblings like get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_branch or get_pull_request. The description does not specify context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Crea un work item (User Story, Task, Bug, etc.) en Azure Boards
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Tags separados por ";" (opcional) | |
| type | No | Tipo de work item (default: User Story) | |
| title | Yes | Título del work item | |
| project | Yes | Proyecto Azure DevOps (ej: movii-business-line) | |
| activity | No | Actividad de un Task: Deployment | Design | Development | Documentation | Requirements | Testing (opcional) | |
| areaPath | No | Area Path exacto, ej: proyecto\Equipo (opcional) | |
| parentId | No | ID del work item padre a enlazar como Hierarchy-Reverse, ej. la User Story (opcional) | |
| startDate | No | Fecha de inicio ISO 8601, ej: 2026-07-10 (opcional) | |
| assignedTo | No | Email o nombre del responsable asignado (opcional) | |
| finishDate | No | Fecha de fin ISO 8601 (opcional) | |
| description | No | Descripción en HTML | |
| customFields | No | Campos personalizados adicionales requeridos por el proceso del proyecto, mapa reference-name -> valor, ej: {"Custom.Fechainicio": "2026-06-30", "Custom.FechaFin": "2026-06-30"} (opcional) | |
| iterationPath | No | Iteration Path exacto (opcional) | |
| originalEstimate | No | Estimación original en horas, solo para Task (opcional) | |
| acceptanceCriteria | No | Criterios de aceptación en HTML (opcional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description solely responsible. Only says 'creates a work item' without mentioning permissions, side effects, limitations, or return behavior. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler. Could be slightly more structured, but efficiently communicates core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 15 parameters (many optional) and no output schema. Description omits return value, error handling, or integration context. Inadequate for complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters, so baseline 3 applies. Description adds no extra parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states clear verb 'Crea' (creates) and resource 'work item' with examples of types. Not explicitly differentiated from siblings but verb alone distinguishes from query/update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use, when-not-to-use, or alternative tool guidance provided. Only states what it does, not when to choose it over update_work_item_state or query_work_items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lee el contenido de un archivo en un repositorio
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Ruta del archivo (ej: /src/app.js) | |
| branch | No | Rama (default: main) | |
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) | |
| repositoryId | Yes | ID o nombre del repositorio |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits, but it only states the basic action. Missing details on read-only nature, permissions, size limits, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose. It is efficient, though it could incorporate more useful details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too brief. It fails to explain return format, encoding, or behavior for errors/missing files. A more complete description would benefit agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description. The tool description adds no extra semantic value beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Lee/Reads) and resource (contenido de un archivo en un repositorio), which is distinct from sibling tools that deal with branches, PRs, or work items. However, it lacks any additional context about scope or variations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like search_code. The description does not mention any preconditions or situations where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene ejecuciones recientes de un pipeline
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Cantidad máxima de resultados (default: 10) | |
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) | |
| pipelineId | Yes | ID del pipeline |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only states the basic action (get) without indicating whether it is read-only, idempotent, or has any side effects. The 'recent' qualifier is vague and lacks detail on criteria like ordering or time window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous content. It is efficiently structured but could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain what the return value contains (e.g., list of run objects, fields). It does not, and it also fails to clarify the meaning of 'recent' (e.g., most recent by run ID? date?). This leaves significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters (top, project, pipelineId). The tool description adds no additional semantic context beyond these schema descriptions. Baseline score of 3 is appropriate since the schema already fully documents parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves recent runs of a pipeline, which distinguishes it from siblings like 'get_pipelines' (list pipelines) or 'get_work_item'. However, it does not clarify what 'recent' means in terms of time or ordering, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need runs of a specific pipeline. No explicit when-to-use or when-not-to-use guidance is provided, nor are alternatives mentioned. The sibling list suggests other retrieval tools, but no contrasts are drawn.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todos los pipelines del proyecto
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It only states 'list all pipelines' and does not mention whether it is read-only, requires permissions, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no unnecessary words. It is front-loaded and immediately conveys the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description is adequate but does not clarify behavior when the project parameter is omitted or the environment variable is unset. Some additional context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional meaning beyond the schema. The baseline of 3 is appropriate as the schema already documents the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' (list) and the resource 'pipelines' with scope 'del proyecto' (of the project). It is specific and distinctly differentiates from sibling tools like create_branch or get_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene el estado actual de un Pull Request
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) | |
| repositoryId | Yes | ID o nombre del repositorio | |
| pullRequestId | Yes | ID del Pull Request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read operation by stating 'gets current status', but does not explicitly confirm non-destructive behavior or mention any permissions, prerequisites, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extra words. Efficiently conveys the core purpose without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no nested objects, no enums, no output schema) and annotations absent, the description is minimally complete. However, it lacks details on return format or error scenarios, which would be expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all parameters having descriptions. The tool description adds no further meaning beyond the schema, but the schema is adequate, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'obtiene' (gets) and the resource 'estado actual de un Pull Request' (current status of a Pull Request), with no ambiguity. It distinguishes from sibling tools like create_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_pull_request or update_work_item. The description does not provide context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista todos los repositorios del proyecto
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic function. It does not disclose authentication needs, rate limits, pagination behavior, or output format (e.g., whether it returns names, URLs, or metadata).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every part of the description contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool, the description is adequate but incomplete. It does not describe the output (e.g., list of repository IDs and names), behavior when no project is specified, or any constraints. No output schema exists to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description adds no parameter information beyond what the schema already provides; it does not mention the optional 'project' parameter or its default from an environment variable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' (lists) and the resource 'repositorios' (repositories), specifying the scope 'del proyecto' (of the project). This effectively distinguishes the tool from siblings like create_branch or get_file_content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or context for its use, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Obtiene un work item de Azure Boards por ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work item ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it gets a work item, which implies a read operation. However, it does not disclose any additional traits such as required permissions, rate limits, or what happens if the ID is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. Every word is necessary; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description is adequate for a simple getter. However, the lack of output schema details means the agent must infer the return format, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for the single parameter 'id' with a clear description. The description's 'por ID' adds no extra meaning beyond the schema. Baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (obtiene), resource (work item de Azure Boards), and method (por ID). It distinguishes from sibling tools like query_work_items which are for searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by ID but does not provide explicit guidance on when to use this tool versus alternatives like query_work_items. No exclusions or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hook de cierre: persiste reporte y finaliza la tarea
| Name | Required | Description | Default |
|---|---|---|---|
| status | Yes | Estado final: success | partial | failed | |
| taskId | Yes | ID del bug o work item resuelto | |
| summary | Yes | Resumen de todas las acciones realizadas |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It mentions persisting a report and finalizing the task, but does not disclose side effects, permissions required, or whether any notification is sent. The name suggests notification, which is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single phrase, but the Spanish phrasing is somewhat ambiguous. Front-loads the purpose but could be clearer in English or more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With three required parameters, no output schema, and no annotations, the description is too sparse. It does not clarify return values, error cases, or the expected outcome of 'finalizing the task'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all three parameters with descriptions. The tool description adds minimal context ('persists report' hints at summary usage) but does not meaningfully enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states this is a closing hook that persists a report and finalizes the task, clearly indicating the action and resource. However, it does not differentiate from sibling tools like update_work_item_state, and the name 'notify' conflicts with the described persistence behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as update_work_item_state. The description implies it is a finalization step, but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hace commit de un cambio en un archivo dentro de una rama existente
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | Contenido completo del archivo modificado | |
| message | Yes | Mensaje del commit | |
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) | |
| filePath | Yes | Ruta del archivo a modificar (ej: /src/app.js) | |
| branchName | Yes | Nombre de la rama donde commitear | |
| repositoryId | Yes | ID o nombre del repositorio |
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. It only states 'hace commit' (makes a commit), implying a write operation, but fails to disclose side effects, required permissions, idempotency, or whether the action is reversible. This is insufficient 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (9 words) with no wasted words. It efficiently conveys the core purpose, though it could be expanded to include critical usage details without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, 5 required, no output schema, no annotations), the description is incomplete. It does not explain what the tool returns, how errors are handled, or prerequisites like branch existence. Critical context for reliable invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no parameter-specific details beyond what the schema already provides, such as explaining the role of 'content' (full file content) or 'message' (commit message). It neither improves nor harms parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a commit on a file in an existing branch. It identifies the verb 'commit' and resource 'file in branch', though it lacks precision about whether the commit is pushed to remote or just local. It is not a tautology and distinguishes adequately from other tools like create_branch or create_pull_request.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as create_branch or create_pull_request. The description does not specify prerequisites (e.g., branch must exist) or exclusions, leaving the agent to infer usage context without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lista los bugs activos asignados al usuario configurado en ASSIGNED_TO
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly describes a read operation (listing bugs), so destructive behavior is not expected, but it does not explicitly state read-only or safety guarantees. The behavior is implied but not explicitly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the core action, and contains no extraneous wording. Every word is necessary to convey the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter query tool with no output schema, the description adequately specifies what it returns (active bugs for a configured user). It is complete enough given the tool's simplicity, though it could mention the output structure or lack of filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema description coverage is 100% (empty set). Per guidelines, 0 parameters result in a baseline of 4; no additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists active bugs assigned to a specific user (configured in ASSIGNED_TO), which is a specific verb-resource combination (list bugs) with a scope filter (assigned to user). It distinguishes from sibling tools like query_work_items which likely query all work items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving bugs assigned to the configured user, but does not explicitly state when to use this tool versus alternatives like query_work_items or get_work_item. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Consulta work items usando WIQL
| Name | Required | Description | Default |
|---|---|---|---|
| wiql | Yes | Consulta en lenguaje WIQL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits such as read-only nature, result limits, or performance considerations. Only states the action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action, no wasted words. However, it is in Spanish which may reduce effectiveness for English-speaking agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description is minimal and does not explain WIQL, output format, or constraints. Lacks completeness for a tool with no output schema and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter with description 'Consulta en lenguaje WIQL'. Schema coverage is 100%, but description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool queries work items using WIQL, which is a specific verb and resource. Distinguishes from sibling tools like query_my_bugs and get_work_item by mentioning the query language.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not explain when WIQL is appropriate or contrast with other query methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Busca texto en los archivos de un repositorio usando Azure DevOps Code Search
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Número máximo de resultados (default: 10) | |
| branch | No | Rama donde buscar (default: development) | |
| project | No | Proyecto Azure DevOps (default: AZURE_PROJECT env var) | |
| searchText | Yes | Texto a buscar (soporta wildcards, AND, OR, NOT) | |
| repositoryName | No | Nombre del repositorio (opcional, filtra resultados) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but fails to disclose behavioral traits like search algorithm, result behavior, or authentication needs. It only repeats what the parameter descriptions already state (wildcard support).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence in Spanish is concise and front-loaded, but the brevity sacrifices some completeness. It earns its place but could be slightly expanded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not mention return format or pagination. For a search tool with 5 parameters, this is a gap, but the core functionality is sufficiently defined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no additional meaning beyond what the parameter descriptions already provide, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (search text), the resource (repository files), and the method (Azure DevOps Code Search), making it distinct from sibling tools which focus on creation or retrieval of entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_file_content or search-specific siblings. The context signals list no direct search siblings, but the description lacks usage context entirely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Actualiza el estado de un work item en Azure Boards
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Work item ID | |
| state | Yes | Nuevo estado (ej: Active, Resolved, Closed) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states the tool updates state, omitting details about mutability, permission requirements, error conditions, or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no extraneous information. It is front-loaded and efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple update tool with two parameters and no output schema, the description is minimally adequate but lacks context on behavior (e.g., return values, error handling, or state transition rules).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds minimal value beyond restating the purpose; it does not clarify parameter syntax or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates the state of a work item in Azure Boards. It uses a specific verb (actualiza) and resource (estado de un work item), distinguishing it from sibling tools like get_work_item or create_work_item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for state changes but provides no explicit guidance on when to use this tool versus alternatives (e.g., updating other fields), nor does it mention prerequisites or conditions like allowed state transitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0create_branchcreate_pull_requestcreate_work_itemget_file_contentget_pipeline_runsget_pipelinesget_pull_requestget_repositoriesget_work_itemnotify_task_completedpush_commitquery_my_bugsquery_work_itemssearch_codeupdate_work_item_stateScored across 15 tools
Most tools target distinct resources/actions. However, query_my_bugs overlaps with query_work_items as a specific case, potentially causing agent confusion.
Uses verb_noun pattern consistently except for notify_task_completed (verb_noun_past) and mixing get/query verbs for similar operations.
15 tools cover the major Azure DevOps domains without being excessive. Each tool serves a clear purpose within git, work items, pipelines, and searching.
Missing update/delete for pull requests and branches, and no delete for work items. The surface covers core workflows but has notable gaps that may force workarounds.
Crie épicos, features, histórias e tasks no Azure DevOps a partir de uma conversa.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
Agentic CI operations for build inspection, failure diagnosis, and runner troubleshooting.
