This server provides read-only access to Azure DevOps Classic Release data and optional controlled operations (plan/review/deploy/rollback) with a local approval panel.
Read-only tools (always available): list configured/organizations, list projects, list release definitions, get release definition metadata, list release environments, get release variables (secrets hidden).
Release queries (without catalog): list releases, get release by ID, get latest release (by definition or latest successful deployment).
Operations tools (when AZDO_OPERATIONS_FILE is set): list operations, plan an operation, get status, list executions, open review, plan rollback.
Catalog-driven planning uses YAML to target releases/environments by name or ID, with strict validation.
Review workflow requires explicit local approval before any write; supports variable updates and redeploys, with rollback capability.
Approval tracking and restoration of previous values, with optional Azure approval permissions.
Safety defaults: writes disabled unless configured; downstream policies restricted; no secret or task body exposure.
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 Classic MCP show me the release variables for the Prod environment in release WebApp"
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 TypeScript para consultar Classic Releases y gestionar operaciones recurrentes de variables y redeploy con revisión local obligatoria. Complementa al MCP oficial de Microsoft. Genérico para cualquier organización de Azure DevOps Services; sin datos corporativos ni secretos embebidos.
La versión 0.2 añade un catálogo YAML, planes ligados a un release concreto, un panel local, seguimiento de aprobaciones y restauración. Las siete herramientas de lectura originales siguen disponibles y se añaden tres consultas de instancias de release sin necesidad de catálogo. Las escrituras están deshabilitadas por defecto. Estado: preview; verificar integración en un release de prueba antes de producción.
Node 22.13+ o 24 LTS; para Inspector y certificados del sistema recomendamos Node 24 LTS.
npm ci
npm run check
npm run demoAbre la URL impresa para probar el panel con datos sintéticos, sin Azure ni PAT. Revisa un cambio, aplícalo y prepara su restauración.
Para uso real:
cp .env.example .env
cp examples/operations.yaml operations.local.yaml
npm run catalog:validate -- operations.local.yaml
npm run build
node --env-file=.env dist/index.jsEdita .env y el catálogo antes de conectar. Los ejemplos tienen nombres e IDs ficticios. No se cargan archivos .env automáticamente. Consulta la guía completa de operaciones para configuración, permisos, restricciones y recuperación. La configuración de lectura original se documenta en READ_ONLY.md; sus referencias a solo lectura describen ese módulo original.
Related MCP server: MCP Server for Azure DevOps
El repositorio incluye .vscode/mcp.json. Abre la carpeta raíz del proyecto en VS Code, crea y configura .env a partir de .env.example y ejecuta npm ci y npm run build.
Abre .vscode/mcp.json y pulsa Start, o usa MCP: List Servers desde la paleta de comandos para iniciar azure-devops-classic. Acepta la confianza del servidor cuando VS Code la solicite. En Copilot Chat, selecciona el modo Agent y habilita las herramientas del servidor. Puedes probar con: «Lista los proyectos disponibles en Azure DevOps».
La configuración usa Node desde el PATH y carga el .env local; no contiene credenciales. Si usas Node portable en Windows, asegúrate de que VS Code herede su PATH (cierra todas sus ventanas y vuelve a abrirlo después de cambiarlo). Alternativamente, configura el servidor en tu perfil de usuario con la ruta absoluta a node.exe; evita guardar rutas personales en el archivo compartido y no inicies ambas configuraciones a la vez.
Reinicia el servidor después de recompilar o cambiar .env. Para las operaciones YAML, consulta la guía de operaciones. No ejecutes Inspector y Copilot simultáneamente contra el mismo directorio de estado.
Esta configuración corresponde a Copilot en VS Code; Copilot CLI utiliza su propia configuración. Referencia: administrar servidores MCP en VS Code.
La forma recomendada evita buscar IDs manualmente:
definition:
name: Example Application
environment:
name: Deploy CertificationLa forma avanzada sigue siendo compatible:
definitionId: 123
environment:
definitionEnvironmentId: 456
expectedName: Deploy CertificationUsa una sola forma para cada referencia. Durante la planificación, el gateway resuelve nombres exactos (incluidas mayúsculas y espacios) y rechaza resultados ausentes o ambiguos. El plan guarda IDs concretos; ejecución, seguimiento y restauración no vuelven a resolver nombres. Cambiar el catálogo invalida un plan pendiente.
examples/operations.yaml muestra nombres; examples/operations.ids.yaml muestra IDs. catalog:validate comprueba ambos formatos sin conectarse a Azure. La existencia se verifica al planificar. Consulta los pasos para Windows.
Módulo | Alcance |
Lectura | Organizaciones, proyectos, definiciones Classic, environments y variables |
Catálogo | YAML estricto, modos permitidos, variables globales/de stage y targets configurables |
Selección | Último creado activo, historial de despliegues exitosos o release explícito |
Plan | IDs fijos, diff no secreto, artefactos, caducidad y huella del catálogo y release |
Revisión | Interfaz local protegida, decisión explícita, estado e historial |
Ejecución | Actualizar variables de la instancia y solicitar redeploy del environment |
Aprobaciones | Espera externa; decisión explícita opcional con permisos de Azure |
Restauración | Valores anteriores y ausencia original, mismo release, revisión y nuevo redeploy |
No ejecuta una task interna aislada. No modifica definiciones, Library o secretos. Por defecto rechaza dependencias de stages; downstreamPolicy: allow permite dependencias conocidas con advertencia, sin modificarlas. Git Flow y trunk-based usan el mismo motor con destinos explícitos.
Disponibles incluso sin AZDO_OPERATIONS_FILE:
ado_list_releases: página de releases ordenados del más reciente al más antiguo, con top, continuationToken, filtros por definición, estado y rama.
ado_get_release: metadata de una instancia por releaseId.
ado_get_latest_release: último release activo por definitionName exacto o definitionId; usa latestCreated por defecto. latestSuccessfulDeployment exige environmentName y consulta el historial de despliegues exitosos.
Organización y proyecto son opcionales si están configurados en .env. Las respuestas incluyen fechas, stages, intentos cuando estén disponibles y referencias de artefactos permitidas. No exponen variables, tareas, logs, URLs de descarga ni campos arbitrarios. Si un campo no está disponible, se omite. La selección del último release se comparte con el motor de operaciones.
Ejemplo: «Usa ado_get_latest_release para consultar el último release de Example Catalog Service». No hace falta crear una operación para consultar.
ado_list_operations, ado_plan_operation, ado_get_operation_status, ado_list_operation_executions, ado_open_operation_review, ado_plan_operation_rollback.
Se registran únicamente si AZDO_OPERATIONS_FILE está configurado. Copilot prepara y devuelve un enlace de revisión; la escritura se autoriza en el panel. Inspector puede usar las mismas herramientas. Una sola instancia de producción por directorio de estado.
npm run typecheck
npm run lint
npm test
npm run build
npm run format:checknpm run format aplica formato. npm run check reúne tipos, lint, pruebas y build. CI ejecuta Node 22 y 24. Las pruebas usan datos sintéticos y no acceden a Azure.
El proyecto usa el SDK oficial MCP y las APIs REST de Azure DevOps. El servidor MCP oficial de Microsoft se configura separadamente en el cliente para repositorios, PRs, Boards y Test Plans. No lo importamos ni ejecutamos como subproceso.
Las comprobaciones previas no eliminan la ventana entre GET y PUT frente a cambios de otros equipos. No hay transacción distribuida ni coordinación entre máquinas. Un error de escritura puede significar que Azure la aplicó: se registra como incierto y no se repite. El registro local está cifrado, pero su clave vive en el mismo perfil del usuario. El enlace de revisión es privado y no prueba presencia humana frente a procesos con acceso al mismo usuario.
La integración real con Azure, preservación de secretos no editados y políticas corporativas debe verificarse antes de habilitar escritura. Ningún PAT se incluye en el repositorio. private: true evita publicación accidental en npm; el código es publicable en GitHub bajo MIT.
deployment:
strategy: environmentRedeploy
downstreamPolicy: allow
redeployWhenUnchanged: trueAmbas opciones son opt-in: por defecto son reject y false. Con allow, Azure puede disparar stages posteriores según su configuración; el panel muestra los dependientes directos y el seguimiento se limita al stage elegido. No se modifican dependencias ni se permiten triggers desconocidos. Con redeployWhenUnchanged: true, los valores iguales aparecen como «Sin cambios» y se puede solicitar redeploy sin ejecutar un PUT de variables.
Consulta examples/operations.services.yaml para un catálogo genérico de dos servicios y la guía de prueba con Copilot. El panel indica si las escrituras están habilitadas y desactiva el botón cuando no lo están; el backend siempre vuelve a validar ese permiso.
Read safe Classic Release metadata without task bodies or variable values.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| definitionId | Yes | ||
| organization | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds the valuable behavioral disclosure that task bodies and variable values are intentionally omitted from the result, which is not covered by annotations. 'Safe' aligns with read-only but adds no new info; the exclusion does.
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, front-loaded sentence states the purpose first and the exclusion second. There is zero wasted text, and it is structured for rapid comprehension.
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 parameters, no output schema, and no return-format description, the one-liner is insufficient. It does not explain what metadata is actually returned (e.g., name, id, stages), nor does it describe parameter constraints or usage context, leaving critical gaps for an agent to call it correctly.
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 0% and the description mentions none of the three parameters (project, definitionId, organization). Even the required definitionId is unexplained, leaving the agent without any hint about what values to supply or what each parameter represents.
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 uses a specific verb ('Read') and resource ('Classic Release metadata') and clarifies scope by excluding 'task bodies or variable values'. This clearly distinguishes it from sibling list tools and the variable getter, with no 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?
The exclusion of task bodies and variable values implies when to use this tool (when those are not needed), but it does not name alternatives or explicitly state 'use this instead of list_release_definitions or get_release_variables'. Guidance is implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read direct variables at definition scope or a selected environment. Secret or unspecified secrecy values are always hidden. Does not resolve variable groups or merge scopes.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| definitionId | Yes | ||
| organization | No | ||
| environmentId | No | ||
| includeValues | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavior beyond these: 'Secret or unspecified secrecy values are always hidden' and 'Does not resolve variable groups or merge scopes.' These details disclose important security and scope behaviors that are not captured in the annotations, enriching the agent's understanding without contradicting the structured hints.
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 three concise sentences. The first sentence front-loads the core purpose, and the next two add critical behavioral caveats. There is no redundancy, filler, or repetition. Every sentence earns its place, making it highly efficient.
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 read-only tool with no output schema, the description covers the main scope and limitations adequately. However, it fails to explain parameter semantics (especially includeValues) and does not clarify how 'selected environment' maps to environmentId or what values each parameter expects. The description is enough for a basic call but leaves gaps that could lead to incorrect invocation, particularly around the optional 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 0%, so the description must compensate, but it does not. It mentions 'definition scope or a selected environment,' which hints at definitionId and environmentId, but entirely omits explanations for includeValues, project, and organization. The most ambiguous parameter, includeValues, has no description at all, leaving the agent to guess its purpose (likely controlling whether values are returned). This is a significant gap for a tool with five 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 the action ('Read') and the resource ('direct variables') with a specific scope ('at definition scope or a selected environment'). It is distinct from siblings like get_release_definition (which retrieves the definition itself) and list_release_environments (which lists environments). The verb is specific and resource is unambiguous.
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 a clear context for what the tool reads (direct variables) and a limitation ('Does not resolve variable groups or merge scopes'), which implies situations where this tool should not be used. However, it does not explicitly name alternative tools or state 'use this when X, otherwise use Y'. The guidance is implied rather than explicit, so it falls short of a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List locally configured organizations; does not discover memberships or verify access.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds that it does not discover memberships or verify access, which is useful behavioral context beyond the annotations about scope and reliability.
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 with no redundancy, front-loading the core action and immediately followed by key limitations. Every word contributes.
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 read-only list tool, the description covers what it returns and its limitations. It does not specify output format, but no output schema exists and the tool is simple enough that this is not a critical omission.
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?
There are no parameters and schema coverage is 100%, so the baseline of 4 applies. The description adds no parameter detail because none 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 states a specific verb and resource: list locally configured organizations. The qualifier 'locally configured' and the negative clause 'does not discover memberships or verify access' clearly differentiate this tool from siblings like ado_list_organizations.
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 negative clause provides an explicit when-not: it does not discover memberships or verify access, signaling that this tool is only for local configuration listing. However, it does not name alternative sibling tools or explicitly state when to prefer this one over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read Azure DevOps Accounts for an explicit member UUID using the Accounts API. Requires compatible identity credentials/profile permissions; may not work with organization-scoped PATs. Results filtered by organization allowlist.
| Name | Required | Description | Default |
|---|---|---|---|
| memberId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it warns about credential limitations (organization-scoped PATs may not work) and mentions that results are filtered by an organization allowlist. This is useful operational behavior not visible in the schema.
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?
Three sentences, each earning its place: the first states the action and scope, the second warns about credential compatibility, the third notes allowlist filtering. No filler or repetition of schema details.
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 read-only tool with one parameter and no output schema, the description covers the essential context: what it reads, for whom, credential caveats, and filtering behavior. It doesn't describe the return format, but with no output schema and a simple list operation, this is a minor 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 description coverage is 0%, so the description must compensate. The description explains that memberId is an explicit member UUID and that the call reads accounts for that member, which adds meaning beyond the raw schema field. It doesn't detail the UUID format beyond the schema's format field, but for a single-parameter tool this 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 ('Read'), the resource ('Azure DevOps Accounts'), and the specific scope ('for an explicit member UUID using the Accounts API'). It also distinguishes itself from sibling tools by naming the API and the member-based scope, so an agent can tell it apart from ado_list_configured_organizations and ado_list_projects.
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 clear context: it reads accounts for a specific member UUID and notes credential requirements ('Requires compatible identity credentials/profile permissions; may not work with organization-scoped PATs'). It does not explicitly name alternative tools or state when not to use it, but the context is sufficient for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of accessible projects.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| organization | No | ||
| continuationToken | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description is not responsible for those. It adds behavioral context with 'one page' (indicating pagination behavior) and 'accessible' (implying a filter on user permissions). However, it does not explain what happens with continuation tokens or how many results are returned beyond the default, leaving gaps that annotations do not cover.
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 front-loads the action ('Read') and scope ('one page of accessible projects'). It is free of extraneous detail and reads clearly. While it is under-specified in terms of parameter information, it is appropriately concise for a simple read operation, though it could include a bit more 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?
For a tool with three parameters and no schema descriptions, this description is incomplete. It lacks any explanation of pagination semantics, required inputs, or output characteristics. The agent knows it reads projects but cannot determine correct invocation without additional information. Annotations cover safety, but not operational details, so this falls short of a complete description.
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 0%, so the description must compensate by explaining the parameters. It does not mention 'top', 'organization', or 'continuationToken' at all. The phrase 'one page' vaguely hints at pagination but provides no concrete meaning for the parameters, leaving them entirely undocumented for the agent.
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 'read', the resource 'projects', and the scope 'one page of accessible projects'. This distinguishes it from sibling list tools like ado_list_organizations and ado_list_release_definitions, which target different resources. The phrase 'one page' also hints at pagination, further clarifying its scope.
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 gives no guidance on when to use this tool versus alternatives. It does not mention any conditions or exclusions, nor does it reference sibling tools. An agent must infer from the name that this is for projects, but there is no explicit direction about when other list tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one page of Classic Release definitions.
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | ||
| project | No | ||
| searchText | No | ||
| organization | No | ||
| continuationToken | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey that this is readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds minimal behavioral value by noting 'one page' (pagination) and 'Classic' scope, but it does not explain how pagination continues or what the returned page contains.
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 six words and contains no filler: it specifies the action, resource, variant type, and pagination behavior. Every phrase earns its place, and the core information is front-loaded.
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 paginated list tool with five parameters, no output schema, and 0% parameter documentation, this one-line description is too thin to be complete. It omits how continuationToken is used, whether project or organization must be provided contextually, and what a page of release definitions looks like. The annotations cover safety but not invocation semantics.
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 0%, and the description does not compensate by explaining any of the five parameters. While names like project and searchText are somewhat self-explanatory, top is ambiguous without page-size context, continuationToken's role in paging is not stated, and the relationship between organization and project is left undefined.
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 (Read) and resource (Classic Release definitions), and the phrase 'one page' communicates that this is a paginated listing operation. It does not explicitly differentiate from sibling tools like ado_get_release_definition or ado_list_release_environments, but the resource and verb are specific enough to be unambiguous.
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 instead of ado_get_release_definition or the other sibling list tools. There are no alternatives, exclusions, prerequisites, or context cues beyond the tool's name and brief resource reference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read environments within a Classic Release definition, not YAML environments.
| Name | Required | Description | Default |
|---|---|---|---|
| project | No | ||
| definitionId | Yes | ||
| organization | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world, and non-destructive behavior, so the description does not need to repeat that. It adds the useful scoping detail that the operation targets Classic Release definitions rather than YAML environments, but it does not describe pagination, output shape, or auth requirements.
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 tight sentence that front-loads the action and resource. The 'not YAML environments' clause is meaningful disambiguation, not filler.
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 read-only list tool, the required definitionId and optional project/organization are reasonably inferable from the schema, and the description supplies the important Classic-vs-YAML distinction. The absence of any output format or return-value note is a minor gap, but it does not make invocation ambiguous.
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 0% description coverage, so the description must compensate. It clarifies that the definition referenced is a Classic Release definition, which helps with the required definitionId parameter, but it provides no guidance on the project or organization parameters or how they affect the lookup.
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 uses a specific verb, 'Read,' and a specific resource, 'environments within a Classic Release definition.' The final clause explicitly excludes YAML environments, which helps distinguish this tool from related release-definition or YAML-scoped 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?
The intended use case is clear: use this when you need environments from a Classic Release definition. It also provides a when-not by stating it is not for YAML environments, though it does not name alternative sibling tools or spell out routing conditions.
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.
v0.1.0ado_get_release_definitionado_get_release_variablesado_list_configured_organizationsado_list_organizationsado_list_projectsado_list_release_definitionsado_list_release_environmentsScored across 7 tools
Most tools are clearly separated by resource type and action, but ado_list_organizations and ado_list_configured_organizations are easy to confuse at a glance despite their distinct descriptions. The remaining release-related tools have clear boundaries.
All tools follow a consistent ado_ prefix with a predictable list_* or get_* verb pattern. Naming is uniform, snake_case throughout, and easy to navigate.
Seven tools is a well-scoped size for a focused Azure DevOps Classic Release inspection server. Each tool covers a distinct step in the discovery flow without unnecessary redundancy.
The set provides a coherent read-only path from organization discovery to project listing to release definitions, environments, and variables. It lacks write operations and actual release run history, but that appears intentionally out of scope.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
Read-only MCP access to a documented IT fleet: state, changes, posture. 15 tools.
Read-only MCP access to sessions, funnels, campaigns, errors, live visitors, and anomalies.
Public read-only MCP for products, frameworks, guides, methodology, and blog metadata.
