Click on "Install 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 Multi-Organization MCP Server list recent builds for project 'web-app' in org-1"
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.
This is a specialized Model Context Protocol (MCP) server for Azure DevOps, designed to overcome the limitations of single-organization bindings found in standard implementations.
The primary value of this implementation is Multi-Organization Support and Context Optimization.
Feature | Standard / Official AzDO MCP | This Implementation | User Value |
Scope | Single Organization (bound via | Multi-Organization (Dynamic Routing) | Seamlessly work across |
Authentication | Single PAT in | Multiple PATs in | Securely manages distinct credentials for different organizations. |
Context Usage | Returns raw, verbose API responses | LLM-Optimized Responses | Aggressively flattens and simplifies JSON output (e.g., removing huge log objects from list views) to prevent "Maximum Length" errors in Claude. |
Tool Signature |
|
| Explicit control over the target organization for every action. |
Related MCP server: Azure DevOps MCP Server
Instead of initializing a single connection at startup, this server uses a ConnectionManager class.
Lazy Loading: Connections to Azure DevOps are established only when a tool is requested.
Caching: Authenticated connections are cached to ensure performance for subsequent requests.
Routing: Every tool schema includes an organization argument. The manager uses this to look up the corresponding Personal Access Token (PAT) from config.json.
Tools are organized into separate modules for maintainability:
tools/organizations.ts: Organization and project discovery tools
tools/pipelines.ts: CI/CD pipeline operations (builds, definitions, runs, logs)
tools/repositories.ts: Git repository and pull request management
tools/common.ts: Shared utilities for enum handling and type conversions
tools/index.ts: Central registration orchestrator
Standard Azure DevOps API responses are extremely verbose, often containing full orchestration plans, logs, and deep nesting. This implementation intercepts these responses in tools like pipelines_get_builds and pipelines_get_build_definitions to:
Limit Results: Defaults to top 20/50 items instead of hundreds.
Flatten Objects: Maps complex objects to simple key-value pairs (e.g., { requestedFor: { displayName: "User" } } becomes just the display name).
Strip Noise: Removes unused URLs, large configuration blobs, and system metadata.
Stdio Transport: For local usage with Claude Desktop and VS Code (default)
SSE Transport: For cloud deployment with HTTP endpoints (activated via PORT env var)
Node.js (v18 or higher)
Azure DevOps Personal Access Tokens (PAT) with appropriate permissions:
Code (Read): For repository and pull request operations
Build (Read & Execute): For pipeline and build operations
Project and Team (Read): For organization and project listing
config.jsonCreate a config.json file in the root directory. This file maps your Organization names (as they appear in the URL, e.g., dev.azure.com/{org}) to their PATs.
{
"org-1": "your-pat-token-here",
"org-2": "another-pat-token-here"
}npm install
npm run buildAdd the server to your claude_desktop_config.json for local usage:
{
"mcpServers": {
"azure-devops-multi": {
"command": "node",
"args": [
"/absolute/path/to/mcp-server-azure-devops-multi/dist/index.js"
]
}
}
}Add the server to your VS Code settings for use with GitHub Copilot Chat:
Open VS Code Settings (JSON)
Add to github.copilot.chat.mcp.servers:
{
"github.copilot.chat.mcp.servers": {
"Azure DevOps Multi": {
"command": "node",
"args": [
"/absolute/path/to/mcp-server-azure-devops-multi/dist/index.js"
]
}
}
}The server supports SSE (Server-Sent Events) transport for cloud deployment:
docker build -t azdo-mcp-server .
docker run -p 3000:3000 -v /path/to/config.json:/app/config.json azdo-mcp-serveraz containerapp create \
--name azdo-mcp-server \
--resource-group <your-rg> \
--environment <your-env> \
--image <your-acr>.azurecr.io/azdo-mcp-server:latest \
--target-port 3000 \
--ingress external \
--env-vars PORT=3000The server automatically switches to SSE transport when PORT environment variable is set, exposing:
GET /sse - SSE connection endpoint
POST /messages - Message handling endpoint
list_organizations: View all configured organizations in config.json.
list_projects: List all projects within a specific organization.
pipelines_get_builds: List recent builds with filtering options (optimized for context).
pipelines_get_build_definitions: List build definitions with query options (optimized for context).
pipelines_get_build_status: Get detailed report for a specific build.
pipelines_get_build_log: Retrieve logs for a specific build.
pipelines_get_build_timeline: Get timeline entries for a build.
pipelines_run_pipeline: Trigger a new pipeline run with parameters and variables.
pipelines_get_run: Get details for a specific pipeline run.
pipelines_list_runs: List pipeline runs with filtering options.
pipelines_get_run_stage: Get information about a specific stage in a pipeline run.
pipelines_get_run_log: Get log content for a specific pipeline run.
pipelines_update_build_stage: Update a stage in a build (placeholder - not yet implemented).
pipelines_get_definition: Get a specific build definition by ID.
pipelines_get_definition_yaml: Get the YAML content of a pipeline definition.
git_list_repositories: List all Git repositories in a project.
git_get_repository: Get details for a specific repository.
git_get_pull_requests: Search and list pull requests with filtering options.
git_create_pull_request: Create a new pull request with title, description, and reviewers.
git_get_item: Get file or folder content from a repository with version control options.
Creates a new pull request in a repository
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name | |
| repositoryId | Yes | The repository ID or name | |
| sourceRefName | Yes | Source branch name (e.g. refs/heads/feature/my-feature) | |
| targetRefName | Yes | Target branch name (e.g. refs/heads/main) | |
| title | Yes | Title of the pull request | |
| description | No | Description of the pull request | |
| isDraft | No | Create as a draft PR |
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 'creates' implies a write/mutation operation, it doesn't specify permissions required, whether it's idempotent, what happens on conflicts, or what the response contains. For a creation tool with 8 parameters and no annotation coverage, this is insufficient 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?
The description is a single, clear sentence that states the core functionality without unnecessary words. It's front-loaded with the essential action and resource, making it highly efficient and easy to parse.
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 creation tool with 8 parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what happens after creation, potential error conditions, or the return format. Given the complexity and lack of structured data, more context about the operation's behavior and outcomes is needed.
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%, meaning all parameters are documented in the schema itself. The description adds no additional parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.
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 ('creates') and resource ('new pull request in a repository'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like git_get_pull_request or git_get_pull_requests, which would require explicit comparison to achieve 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.
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 doesn't mention prerequisites (e.g., needing existing branches), when not to use it, or how it differs from related tools like git_get_pull_request (which retrieves rather than creates). This leaves the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets a file or folder from a Git repository with optional content and version control
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name | |
| repositoryId | Yes | The repository ID or name | |
| path | Yes | Path to the file or folder | |
| scopePath | No | Scope path to filter items | |
| recursionLevel | No | Recursion level (None, OneLevel, Full, OneLevelPlusNestedEmptyFolders) | |
| includeContentMetadata | No | Include content metadata | |
| latestProcessedChange | No | Include latest commit that changed this item | |
| download | No | Set Content-Disposition header for download | |
| versionDescriptor | No | Version descriptor | |
| includeContent | No | Include file content (text only) | |
| resolveLfs | No | Resolve LFS pointer files to actual content | |
| sanitize | No | Sanitize HTML content |
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 mentions 'optional content and version control' which hints at read-only behavior and versioning capabilities, but fails to specify critical details: whether this is a read-only operation, what happens with large files or binary content, error conditions, rate limits, authentication requirements, or the format of returned data. For a tool with 13 parameters and no output schema, this leaves significant gaps in understanding how it behaves.
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 that states the core purpose upfront. Every word earns its place: 'Gets' (action), 'a file or folder' (target), 'from a Git repository' (context), 'with optional content and version control' (key capabilities). There's no redundancy or unnecessary elaboration, making it easy for an agent to parse quickly.
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 (13 parameters, nested objects, no output schema, and no annotations), the description is insufficiently complete. It doesn't explain what the tool returns (file content, metadata, structure), how errors are handled, what authentication is required, or how the many optional parameters interact. For a tool that retrieves Git repository items with numerous configuration options, the description should provide more operational context to help an agent use 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 100%, so the schema already documents all 13 parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'optional content and version control' which loosely relates to includeContent, includeContentMetadata, latestProcessedChange, and versionDescriptor parameters. However, it doesn't provide additional context about parameter interactions, default behaviors, or practical usage examples that would help an agent understand how to combine these parameters effectively.
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 ('Gets') and resource ('a file or folder from a Git repository') with additional context about optional content and version control. It distinguishes from siblings like git_get_pull_request or git_list_repositories by focusing on repository items rather than pull requests or repository lists. However, it doesn't explicitly differentiate from potential overlapping tools like pipelines_get_build_log which also retrieves 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 mentions optional features but doesn't specify scenarios where this tool is preferred over siblings like git_get_pull_request for code retrieval or pipelines_get_build_log for build-related content. There's no mention of prerequisites or constraints beyond what's implied by the parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a specific pull request by ID
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name | |
| pullRequestId | Yes | The ID of the pull request |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states it 'Gets details' which implies a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, error handling, or what 'details' include (e.g., status, comments, files). This is inadequate 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It is front-loaded and appropriately sized for a simple retrieval tool, making it easy for an agent to parse quickly.
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 annotations, no output schema, and a read operation with three parameters, the description is incomplete. It doesn't explain what 'details' are returned, potential errors, or usage context, leaving significant gaps for the agent to understand the tool's behavior and output.
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 schema fully documents the three parameters (organization, project, pullRequestId). The description adds no additional meaning beyond the schema, such as format examples or constraints, but the high coverage justifies the 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 clearly states the action ('Gets details') and resource ('a specific pull request by ID'), making the purpose unambiguous. However, it doesn't differentiate from sibling 'git_get_pull_requests' (plural) which likely lists multiple pull requests, so it misses explicit sibling distinction.
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. The description doesn't mention sibling tools like 'git_get_pull_requests' for listing multiple pull requests or 'git_get_item' for other Git items, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets a list of pull requests in a repository with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name | |
| repositoryId | Yes | The repository ID or name | |
| status | No | Filter by PR status (Active, Abandoned, Completed, All) | |
| creatorId | No | Filter by creator ID | |
| reviewerId | No | Filter by reviewer ID | |
| sourceRefName | No | Filter by source branch name (e.g. refs/heads/feature/1) | |
| targetRefName | No | Filter by target branch name (e.g. refs/heads/main) | |
| top | No | Number of results to return |
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 mentions 'filtering options' but doesn't describe key behaviors like pagination (the 'top' parameter suggests limited results), authentication requirements, rate limits, error handling, or the format of returned data. For a read operation with multiple parameters, this leaves significant gaps.
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 that front-loads the core purpose ('Gets a list of pull requests') and adds a key feature ('with filtering options'). There is no wasted language, and it's appropriately sized for the tool's complexity.
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's complexity (9 parameters, no annotations, no output schema), the description is incomplete. It doesn't address behavioral aspects like pagination, authentication, or data format, and while the schema covers parameters, the lack of output schema means the description should ideally hint at return values. For a list operation with filtering, more context is needed.
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 schema already documents all 9 parameters with descriptions and enums. The description adds minimal value beyond the schema by mentioning 'filtering options' generically, but doesn't provide additional context like parameter interactions or examples. Baseline 3 is appropriate when the schema does the heavy lifting.
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's purpose: 'Gets a list of pull requests in a repository with filtering options.' It specifies the verb ('Gets'), resource ('pull requests'), and scope ('in a repository'), but doesn't explicitly differentiate it from sibling tools like 'git_get_pull_request' (singular) or 'git_list_repositories'.
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 doesn't mention sibling tools like 'git_get_pull_request' (for a single PR) or 'git_list_repositories' (for listing repositories), nor does it specify prerequisites or exclusions. Usage is implied by the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all Git repositories in a project
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name | |
| includeHidden | No | Include hidden repositories |
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. While 'Lists' implies a read-only operation, the description doesn't mention important behavioral aspects like whether this requires authentication, what format the output takes, whether results are paginated, or any rate limits. For a tool with 3 parameters and no annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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 that gets straight to the point with zero wasted words. It's appropriately sized for a simple listing operation and front-loads the core functionality without unnecessary elaboration. Every word earns its place in conveying the essential 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?
Given the tool has 3 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't address what the tool returns, how results are structured, or important behavioral constraints. For a tool that interacts with Azure DevOps (implied by parameter names), more context about authentication, error conditions, or typical use patterns 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?
The input schema has 100% description coverage, with all parameters clearly documented in the schema itself. The description doesn't add any parameter-specific information beyond what's already in the schema descriptions. According to the scoring rules, when schema_description_coverage is high (>80%), the baseline is 3 even with no param info in the description, which applies here.
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 ('Lists') and resource ('all Git repositories in a project'), making the purpose immediately understandable. It distinguishes from siblings like git_create_pull_request or git_get_item by focusing on repository listing rather than creation or retrieval of specific items. However, it doesn't explicitly differentiate from list_organizations or list_projects, which are conceptually similar listing operations.
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 doesn't mention when to use git_list_repositories versus other listing tools like list_projects, or when to use it versus git_get_item for retrieving specific repository details. There's no context about prerequisites, constraints, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available Azure DevOps organizations from the configuration
| 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 the full burden of behavioral disclosure. It mentions 'from the configuration', hinting at data source, but fails to describe critical traits like authentication needs, rate limits, pagination, or response format. This is inadequate for a tool with zero 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without any fluff. It is front-loaded and appropriately sized, making it easy for an agent to parse quickly.
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's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks depth. It does not explain return values or behavioral aspects, which could be important for integration. However, for a basic list operation, it meets the minimum viable threshold.
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 tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description appropriately does not discuss parameters, aligning with the schema's completeness. A baseline of 4 is applied as it compensates for the lack of parameters by not adding unnecessary information.
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 'Lists' and the resource 'Azure DevOps organizations from the configuration', making the purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like 'list_projects', which might cause confusion about scope differentiation.
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, such as 'list_projects' or other sibling tools. It lacks context about prerequisites, timing, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all projects in an Azure DevOps organization
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization |
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. While 'Lists' implies a read-only operation, it doesn't specify whether this requires authentication, what permissions are needed, whether results are paginated, or what the output format looks like. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 that directly states the tool's purpose without unnecessary words. It's front-loaded with the core functionality, making it easy to parse quickly.
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's simplicity (1 parameter, no output schema, no annotations), the description is minimally adequate but lacks completeness. It doesn't address authentication requirements, output format, or how it fits with sibling tools, leaving the agent to infer these aspects. For a basic list operation, it meets the minimum threshold but could be more informative.
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 schema description coverage is 100%, with the single parameter 'organization' clearly documented in the schema. The description doesn't add any additional meaning beyond what's in the schema, such as explaining what constitutes a valid organization name or providing examples. With high schema coverage, the 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 action ('Lists') and resource ('all projects in an Azure DevOps organization'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_organizations' or 'git_list_repositories' by specifying what distinguishes a project from other Azure DevOps 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., authentication), when not to use it, or how it relates to sibling tools like 'list_organizations' or 'git_list_repositories' that might list different resource types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the code changes (commits) associated with a build
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to get the build changes for | |
| buildId | Yes | ID of the build to get changes for | |
| continuationToken | No | Continuation token for pagination | |
| top | No | Number of changes to retrieve, defaults to 100 | |
| includeSourceChange | No | Whether to include source changes in the results, defaults to false |
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 but only states the basic operation. It doesn't mention pagination behavior (implied by 'continuationToken'), rate limits, authentication needs, error conditions, or what 'code changes' entails (e.g., commit details, diff information), which is insufficient for a read operation with multiple parameters.
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 that front-loads the core purpose without unnecessary words. It earns its place by clearly stating what the tool does, making it appropriately sized and well-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?
Given no annotations and no output schema, the description is incomplete for a tool with 6 parameters and a read operation. It lacks details on return values (e.g., format of changes), behavioral traits like pagination, and context for sibling differentiation, leaving significant gaps for an agent to use it effectively.
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 schema fully documents all 6 parameters. The description adds no additional parameter semantics beyond implying 'buildId' is required, which is already in the schema. This meets the baseline of 3 for high schema coverage without extra value.
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 ('Gets') and resource ('code changes (commits) associated with a build'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'pipelines_get_builds' or 'pipelines_get_build_status', which reduces clarity about its specific role in the toolset.
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 doesn't mention prerequisites (e.g., needing a build ID), exclusions, or compare it to sibling tools like 'pipelines_get_builds' for broader build information, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the revision history of a build definition
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to get the build definition revisions for | |
| definitionId | Yes | ID of the build definition to get revisions for |
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. While 'Gets' implies a read-only operation, it doesn't specify authentication requirements, rate limits, pagination behavior, or what format the revision history returns. For a tool with zero annotation coverage, this leaves significant gaps.
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 zero wasted words. It's appropriately sized for a straightforward retrieval tool and front-loads the core purpose immediately.
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's moderate complexity (retrieving revision history), lack of annotations, and no output schema, the description is minimally adequate but incomplete. It states what the tool does but omits behavioral details and output expectations that would help an agent use 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 100%, so the schema already documents all three parameters (organization, project, definitionId). The description doesn't add any additional meaning about these parameters beyond what the schema provides, meeting the baseline for high coverage.
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 ('Gets') and resource ('revision history of a build definition'), making the purpose unambiguous. However, it doesn't differentiate from sibling tools like 'pipelines_get_build_definitions' or 'pipelines_get_build_changes', 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.
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. There are multiple sibling tools for retrieving build-related information (e.g., 'pipelines_get_build_definitions', 'pipelines_get_builds'), but no indication of when revision history is needed versus other build data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets a list of build definitions (pipeline configurations) in a project
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to get build definitions for | |
| repositoryId | No | Repository ID to filter build definitions | |
| repositoryType | No | Type of repository to filter build definitions | |
| name | No | Name of the build definition to filter | |
| path | No | Path of the build definition to filter | |
| queryOrder | No | Order in which build definitions are returned | |
| top | No | Maximum number of build definitions to return | |
| continuationToken | No | Token for continuing paged results | |
| minMetricsTime | No | Minimum metrics time to filter build definitions (ISO 8601 string) | |
| definitionIds | No | Array of build definition IDs to filter | |
| builtAfter | No | Return definitions that have builds after this date (ISO 8601 string) | |
| notBuiltAfter | No | Return definitions that do not have builds after this date (ISO 8601 string) | |
| includeAllProperties | No | Whether to include all properties in the results | |
| includeLatestBuilds | No | Whether to include the latest builds for each definition | |
| taskIdFilter | No | Task ID to filter build definitions | |
| processType | No | Process type to filter build definitions | |
| yamlFilename | No | YAML filename to filter build definitions |
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 states it 'Gets a list' but lacks critical details: whether it's paginated (implied by 'continuationToken' in schema but not described), rate limits, authentication requirements, error handling, or output format. For a tool with 18 parameters and no annotations, this is a significant gap in transparency.
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 zero waste. It's front-loaded with the core purpose ('Gets a list of build definitions') and includes essential context ('pipeline configurations', 'in a project'). No extraneous details 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 complexity (18 parameters, no annotations, no output schema), the description is inadequate. It doesn't cover behavioral aspects (pagination, errors), output format, or usage context. For a list/query tool with many filtering options, more guidance is needed to help an agent use it effectively.
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 schema fully documents all 18 parameters. The description adds no parameter-specific information beyond the generic 'in a project' context. It doesn't explain how parameters interact (e.g., filtering logic) or provide examples. Baseline 3 is appropriate as the schema does the heavy lifting, but the description adds minimal value.
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 ('Gets a list') and resource ('build definitions/pipeline configurations') with context ('in a project'). It distinguishes from siblings like 'pipelines_get_build_definition_revisions' (specific revisions) and 'pipelines_get_builds' (actual builds vs definitions), though not explicitly named. However, it doesn't fully differentiate from all siblings (e.g., 'pipelines_list_runs' is similar but for runs).
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 doesn't mention prerequisites (e.g., authentication), compare to sibling tools like 'pipelines_get_builds' (for builds) or 'pipelines_get_build_definition_revisions' (for revisions), or specify scenarios (e.g., filtering vs listing all). Usage is implied by the name but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the list of log files for a build
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to get the build log for | |
| buildId | Yes | ID of the build to get the log for |
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 states a read operation ('Gets') but doesn't cover critical aspects like authentication needs, rate limits, pagination, error handling, or the format of returned log files. This leaves significant gaps for an agent to understand how to use it effectively.
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 that directly states the tool's purpose without unnecessary words. It is front-loaded and wastes no space, making it easy to parse quickly.
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 of a build log tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'log files' entail, how they are structured, or any behavioral traits, leaving the agent with incomplete context for proper invocation.
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 input schema fully documents the three parameters (organization, project, buildId). The description adds no additional meaning beyond implying a relationship to 'build' and 'log files', which is already inferred from the schema. This meets the baseline for high schema coverage.
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 ('Gets') and resource ('list of log files for a build'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'pipelines_get_build_log_by_id' or explain what distinguishes 'log files' from other build data, missing full sibling differentiation.
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 'pipelines_get_build_log_by_id' or other build-related tools. The description lacks context about prerequisites, timing, or exclusions, offering minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the content of a specific build log file by ID
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to get the build log for | |
| buildId | Yes | ID of the build to get the log for | |
| logId | Yes | ID of the log to retrieve | |
| startLine | No | Starting line number for the log content, defaults to 0 | |
| endLine | No | Ending line number for the log content, defaults to the end of the log |
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 'gets' content without disclosing behavioral traits like whether it's a read-only operation, authentication requirements, rate limits, error conditions, or pagination behavior. It mentions line range defaults but doesn't explain return format or potential 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 that front-loads the core purpose without unnecessary words. Every part of the sentence earns its place by specifying the action, resource, and key identifier.
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 6 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the return value format, error handling, or operational context, leaving significant gaps in understanding how to effectively use this tool beyond basic parameter passing.
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%, providing clear documentation for all 6 parameters. The description adds no additional parameter semantics beyond implying retrieval by ID, so it meets the baseline of 3 where the schema does the heavy lifting without compensating for gaps.
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 ('Gets') and resource ('content of a specific build log file by ID'), making the purpose unambiguous. However, it doesn't explicitly differentiate from its sibling 'pipelines_get_build_log' (which appears to get logs without specifying a log ID), missing full sibling distinction.
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 like 'pipelines_get_build_log' or other pipeline tools. It lacks context about prerequisites, such as needing a specific build and log ID, or when line range filtering is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets a list of builds (pipeline runs) with filtering options
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to get builds for | |
| definitions | No | Array of build definition IDs to filter builds | |
| queues | No | Array of queue IDs to filter builds | |
| buildNumber | No | Build number to filter builds | |
| minTime | No | Minimum finish time to filter builds (ISO 8601 string) | |
| maxTime | No | Maximum finish time to filter builds (ISO 8601 string) | |
| requestedFor | No | User ID or name who requested the build | |
| reasonFilter | No | Reason filter for the build (see BuildReason enum) | |
| statusFilter | No | Status filter for the build (see BuildStatus enum) | |
| resultFilter | No | Result filter for the build (see BuildResult enum) | |
| tagFilters | No | Array of tags to filter builds | |
| properties | No | Array of property names to include in the results | |
| top | No | Maximum number of builds to return | |
| continuationToken | No | Token for continuing paged results | |
| maxBuildsPerDefinition | No | Maximum number of builds per definition | |
| deletedFilter | No | Filter for deleted builds (see QueryDeletedOption enum) | |
| queryOrder | No | Order in which builds are returned | QueueTimeDescending |
| branchName | No | Branch name to filter builds | |
| buildIds | No | Array of build IDs to retrieve | |
| repositoryId | No | Repository ID to filter builds | |
| repositoryType | No | Type of repository to filter builds |
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. While 'Gets a list' implies a read-only operation, it doesn't address important behavioral aspects like pagination (implied by 'continuationToken' parameter but not explained), rate limits, authentication requirements, or what happens when filters return no results. The description is too minimal for a tool with 22 parameters.
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 extremely concise at just one sentence with 9 words. It's front-loaded with the core purpose and wastes no words. Every element of the description ('Gets a list of builds', 'pipeline runs', 'filtering options') serves a clear purpose in communicating the tool's function.
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 complex tool with 22 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what the tool returns (build objects with what properties?), how results are structured, pagination behavior, or error conditions. The agent would struggle to use this tool effectively without significant trial and error or external documentation.
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 schema description coverage is 100%, meaning all parameters are documented in the schema itself. The description adds minimal value beyond the schema by mentioning 'filtering options', which aligns with the many filter parameters in the schema. However, it doesn't provide additional context about parameter interactions or usage patterns that would help an agent understand how to effectively use these filters together.
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 ('Gets a list of builds') and the resource ('pipeline runs'), making the purpose immediately understandable. However, it doesn't differentiate this tool from sibling tools like 'pipelines_list_runs' or 'pipelines_get_build_status', which appear to serve similar functions in the same domain.
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 mentions 'with filtering options' which implies some context for usage, but provides no explicit guidance on when to use this tool versus alternatives like 'pipelines_list_runs' or 'pipelines_get_build_status'. There's no mention of prerequisites, performance considerations, or specific scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets the status report for a build
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to get the build status for | |
| buildId | Yes | ID of the build to get the status for |
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 'Gets the status report', implying a read-only operation without details on authentication needs, rate limits, error handling, or what the status report includes. It lacks behavioral context crucial for a tool with no output 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?
The description is a single, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core action without unnecessary elaboration.
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 no annotations and no output schema, the description is insufficient. It fails to explain what the status report contains, how it differs from other build-related tools, or any behavioral traits, leaving significant gaps for an agent to use it effectively in context.
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 schema description coverage is 100%, so parameters are well-documented in the schema. The description adds no additional meaning beyond implying it retrieves status for a specific build, which aligns with the schema but doesn't enhance understanding of parameter usage or interactions.
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 ('Gets') and resource ('status report for a build'), making the purpose understandable. However, it does not differentiate from sibling tools like 'pipelines_get_builds' or 'pipelines_get_build_log', which also retrieve build-related information, so it lacks specificity in distinguishing its exact 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 provides no guidance on when to use this tool versus alternatives, such as 'pipelines_get_builds' for listing builds or 'pipelines_get_build_log' for logs. It also omits prerequisites or context for usage, leaving the agent to infer based on parameter names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Gets details of a specific pipeline run
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to run the build in | |
| pipelineId | Yes | ID of the pipeline to run | |
| runId | Yes | ID of the run to get |
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 states this is a read operation ('Gets'), but doesn't mention any behavioral traits like authentication requirements, rate limits, error conditions, or what details are returned. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.
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 that states the core purpose without any wasted words. It's appropriately sized for a simple retrieval tool and front-loads the essential information. Every word earns its place.
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 lack of annotations and output schema, the description is incomplete. It doesn't explain what details are returned, potential error conditions, or authentication requirements. For a tool with 4 required parameters and no structured output documentation, the description should provide more context about the operation's behavior and results.
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 description adds no parameter semantics beyond what's already in the schema, which has 100% coverage with clear descriptions for all 4 parameters. The baseline score of 3 is appropriate since the schema adequately documents the parameters, and the description doesn't need to compensate for any gaps.
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 ('Gets') and resource ('details of a specific pipeline run'), making the purpose immediately understandable. It distinguishes from sibling tools like 'pipelines_list_runs' by specifying retrieval of a single run rather than listing multiple runs. However, it doesn't explicitly differentiate from other get tools like 'pipelines_get_builds' beyond the resource name.
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 doesn't mention prerequisites like needing a specific run ID, nor does it contrast with similar tools like 'pipelines_get_builds' or 'pipelines_list_runs'. The agent must infer usage solely from the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all runs for a specific pipeline
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to run the build in | |
| pipelineId | Yes | ID of the pipeline to run |
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 states it's a list operation, implying it's read-only, but doesn't mention any behavioral traits like pagination, rate limits, authentication needs, or what the output format looks like (e.g., JSON array of runs). This leaves significant gaps for an agent to use it effectively.
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 that directly states the tool's purpose without any fluff. It's front-loaded and appropriately sized for a simple list operation, with every word contributing to clarity.
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 (a list operation with 3 required parameters), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral aspects (e.g., output format, pagination) and usage context, which are crucial for an agent to invoke this tool correctly without trial and error.
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, clearly documenting each parameter (organization, project, pipelineId). The description adds no additional semantic context beyond what the schema provides, such as explaining relationships between parameters or usage examples. This meets the baseline for high schema coverage.
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 ('Lists') and resource ('all runs for a specific pipeline'), making the purpose immediately understandable. However, it doesn't distinguish this tool from sibling tools like 'pipelines_get_builds' or 'pipelines_get_run', which also deal with pipeline runs but with different scopes or details.
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. For example, it doesn't clarify if this is for listing all runs versus filtered runs, or how it differs from 'pipelines_get_builds' or 'pipelines_get_run' in the sibling list, leaving the agent to guess based on tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Triggers a new pipeline run with optional parameters and variables
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to run the build in | |
| pipelineId | Yes | ID of the pipeline to run | |
| pipelineVersion | No | Version of the pipeline to run. If not provided, the latest version will be used. | |
| previewRun | No | If true, returns the final YAML document after parsing templates without creating a new run. | |
| resources | No | A dictionary of resources to pass to the pipeline. | |
| stagesToSkip | No | A list of stages to skip. | |
| templateParameters | No | Custom build parameters as key-value pairs | |
| variables | No | A dictionary of variables to pass to the pipeline. | |
| yamlOverride | No | YAML override for the pipeline run. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions 'triggers a new pipeline run' which implies a write/mutation operation, but doesn't disclose critical traits like authentication requirements, rate limits, whether it's asynchronous, what happens on failure, or if it returns a run ID. The optional 'previewRun' parameter hints at a dry-run capability, but this isn't explained in the description.
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 that gets straight to the point with zero wasted words. It's appropriately sized for a tool with comprehensive schema documentation and is front-loaded with the core action.
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 complex mutation tool with 10 parameters, nested objects, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after triggering (e.g., returns a run ID, is asynchronous), error conditions, or operational constraints. The agent would struggle to use this tool effectively without trial and error.
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 schema fully documents all 10 parameters. The description adds minimal value beyond the schema, mentioning 'optional parameters and variables' which loosely references some parameters but doesn't provide additional context about their purpose or relationships. Baseline 3 is appropriate when the schema does the heavy lifting.
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 ('Triggers a new pipeline run') and mentions optional parameters and variables, which gives a good sense of scope. However, it doesn't explicitly differentiate this tool from sibling pipeline tools like 'pipelines_get_builds' or 'pipelines_list_runs', which are read operations versus this write operation.
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 doesn't mention prerequisites (e.g., needing a pipeline ID), when not to use it (e.g., for read-only operations), or refer to sibling tools for related tasks like checking pipeline status or listing runs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Updates the status of a build stage (cancel or retry)
| Name | Required | Description | Default |
|---|---|---|---|
| organization | Yes | The name of the Azure DevOps organization | |
| project | Yes | Project ID or name to update the build stage for | |
| buildId | Yes | ID of the build to update | |
| stageName | Yes | Name of the stage to update | |
| status | Yes | New status for the stage | |
| forceRetryAllJobs | No | Whether to force retry all jobs in the stage. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions 'cancel or retry' actions but doesn't disclose permissions needed, whether changes are reversible, rate limits, or what happens to dependent stages. For a mutation 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for the tool's complexity and front-loads the core functionality.
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 mutation tool with 6 parameters, no annotations, and no output schema, the description is inadequate. It doesn't explain what happens after the update, error conditions, or important behavioral aspects like whether forceRetryAllJobs affects previously completed jobs. The context signals indicate significant complexity that isn't addressed.
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%, providing good documentation for all parameters. The description adds minimal value beyond the schema, mentioning 'cancel or retry' which aligns with the status enum values. No additional parameter context or usage examples are provided.
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 ('Updates the status') and resource ('build stage'), with specific status options mentioned ('cancel or retry'). It distinguishes from sibling tools like pipelines_get_builds (read) and pipelines_run_pipeline (initiate), but doesn't explicitly differentiate from all siblings like pipelines_get_build_status.
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 is provided. The description doesn't mention prerequisites, appropriate contexts, or exclusions. For example, it doesn't clarify if this should be used instead of restarting the entire build or when stage cancellation is permissible.
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. Dates show when Glama detected each change.
git_create_pull_requestgit_get_itemgit_get_pull_requestgit_get_pull_requestsgit_list_repositorieslist_organizationslist_projectspipelines_get_build_changespipelines_get_build_definition_revisionspipelines_get_build_definitionspipelines_get_build_logpipelines_get_build_log_by_idpipelines_get_build_statuspipelines_get_buildspipelines_get_runpipelines_list_runspipelines_run_pipelinepipelines_update_build_stageMost tools have distinct purposes, with clear separation between Git operations (pull requests, repositories) and pipeline operations (builds, runs, logs). However, some pipeline tools could cause confusion: 'pipelines_get_build_log' and 'pipelines_get_build_log_by_id' overlap in purpose, and 'pipelines_get_builds' vs 'pipelines_list_runs' might be ambiguous without careful reading of descriptions. Overall, the descriptions help clarify, but there is minor overlap in the pipeline logging and listing areas.
Tool names follow a highly consistent pattern throughout. Git tools use 'git_' prefix with verb_noun format (e.g., 'git_create_pull_request'), pipeline tools use 'pipelines_' prefix with verb_noun format (e.g., 'pipelines_get_builds'), and organizational tools use 'list_' prefix (e.g., 'list_organizations'). All names use snake_case consistently, with clear and predictable structures that enhance readability and agent usability.
With 18 tools, the count is slightly high but reasonable for covering Azure DevOps operations across Git, pipelines, and organizations. It provides comprehensive functionality without being overwhelming. The tools are well-scoped to the server's purpose, though it borders on the heavier side (16-25 range), which is acceptable given the domain complexity.
The tool set offers strong coverage for Git and pipeline operations, including create, get, list, update, and run actions. However, there are minor gaps: for Git, tools like update or delete for pull requests or repositories are missing, and for pipelines, operations like creating or deleting definitions might be lacking. These gaps are not critical but could limit some agent workflows, making the surface mostly complete with room for enhancement.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
The MCP server for Azure DevOps, bringing the power of Azure DevOps directly to your agents.
One PAT, any MCP agent: Vercel, GitHub, Cloudflare, Supabase, GCP — unified dev infra gateway.
Manage WeInc AI website builder orgs: projects, publishing, custom domains, and previews.
Manage translation projects, phrases and locales with secure organization-scoped tools and views.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nikydobrev/mcp-server-azure-devops-multi'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
