azure-devops-local-mcp

by Laonnda

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation5/5
Each tool has a distinct resource and action, clearly separated by domain prefixes (projects, workitems, git, pipelines, wiki, testplans, testsuites, testcases). Even similar operations like list_recent vs query are well-differentiated in their descriptions, leaving no ambiguity for model selection.
Naming Consistency5/5
All tools follow a consistent `ado_<domain>_<action>` pattern using snake_case. Actions are uniformly descriptive (list, get, create, update, query, trigger, etc.), and even compound actions like `add_to_suite` and `create_pr_comment` maintain the same style, making the naming pattern predictable and easy to infer.
Tool Count4/5
At 30 tools, the server is on the higher end for an MCP server, but the coverage spans multiple Azure DevOps domains (projects, work items, Git, pipelines, wiki, test management). Each tool serves a clear purpose without redundancy, so the count is slightly heavy yet well-justified for a comprehensive integration.
Completeness4/5
The tool surface covers core workflows across the main Azure DevOps areas: work item CRUD and linking, Git PR viewing and commenting, pipeline listing and triggering, wiki management, and test plan/suite/case management. Minor gaps exist (e.g., no PR creation, no pipeline definition creation, no wiki deletion), but these are typically secondary and can be worked around via existing tools.
Average 4.3/5 across 30 of 30 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- Last stable release on September 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, covering the read-only and exploratory nature. The description adds the requirement 'Requires vso.build PAT scope,' which is a critical authentication constraint not present in annotations, and it specifies the exact fields returned. This goes beyond the annotation baseline.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, each serving a distinct purpose: stating the action, listing return fields, and noting the auth requirement. It is front-loaded with the main purpose and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Since there is no output schema, the description must describe the return shape, which it does by listing fields. It also covers the auth requirement. Pagination behavior is implied through the 'top' parameter in the schema. Minor gaps like error handling or project-not-found behavior are not covered, but for a read-only, open-world listing tool, the description is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters (top and project) are fully documented in the schema. The tool description does not add any additional parameter-level meaning or syntax beyond what the schema already provides, which aligns with the baseline score for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pipeline definitions for an Azure DevOps project, which is a specific verb-resource combo. It also enumerates returned fields (id, name, folder, revision, URLs) and is easily distinguished from sibling tools like ado_pipelines_list_runs by the 'definitions' vs 'runs' distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any exclusions, prerequisites, or refer to sibling tools. The description only states what it does, leaving usage context to be inferred from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is a read-only operation, and the description adds meaningful behavioral details: output is truncated to 10 KB to prevent context overflow and the tool requires the vso.build PAT scope. It does not cover empty results or pagination, but the key behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then adds return behavior and authentication needs. Every sentence contributes a distinct and useful piece of information without repeating schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter input, read-only annotations, and no output schema, the description covers the return shape, the 10 KB truncation, what to do to get full log content, and the required token scope. It is largely complete, though it does not explain how to obtain a relevant buildId when not already known.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both project and buildId. The description adds the pipeline-run context but does not provide additional parameter meaning, format details, or guidance beyond what the schema already gives.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action and resource: getting build log references for an Azure DevOps pipeline run. It also tells the agent the result shape (list of log entries with id, type, url, lineCount) and distinguishes this from sibling tools like ado_pipelines_get_run or ado_pipelines_trigger.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool returns and instructs the agent to follow each log URL for full content, which is useful. However, it does not explicitly say when to choose this tool over related pipeline tools or when not to use it, leaving most selection guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, but the description adds meaningful context by requiring vso.build PAT scope (an authentication requirement not present in annotations) and by listing the returned fields (state, result, timestamps, URL). This goes beyond what annotations capture and clarifies the tool's behavior for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point: it first states the core function, then what the user gets, then the auth requirement. Each sentence is informative, and there is no filler or duplication. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a straightforward query with three required parameters and read-only annotations, the description covers purpose, output, and authentication. It does not mention error cases or how to obtain the run ID, but for a simple retrieval endpoint this is adequate. The presence of an output schema is not required because the description already indicates the return fields, which is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, all three parameters are already documented. The description merely repeats that the run is addressed by pipeline ID and run ID, not adding new semantics or guidance on parameter relationships. It stays at the baseline neutral level because it neither enriches nor is necessary for understanding the params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description is explicit: 'Get details of a single Azure DevOps pipeline run by pipeline ID and run ID.' This clearly identifies the verb and resource and differentiates itself from sibling tools that list or trigger runs by emphasizing a single run and specifying return fields. The mention of 'single' distinguishes it from listing operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used when you have a specific pipeline ID and run ID to request details, but it does not provide explicit guidance on when to use this versus alternatives like listing runs or fetching logs. It lacks exclusions or comparative routing, which keeps it at a basic 'implied usage' level rather than a clear 'use this when' statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already supply readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds value by disclosing the vso.build PAT scope requirement, which is not available elsewhere, and characterizing results as 'recent' runs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences with zero filler. The first sentence states the purpose, the second lists the parameters and their roles, and the third gives the authorization requirement. Each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with 5 optional parameters and no output schema, the description covers purpose, filtering, pagination, and auth. It does not describe return format or default project behavior, but those are reasonably inferable or documented in the schema, and the annotations cover the safety profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with every parameter already documented. The description adds modest relational meaning by linking pipelineId to 'pipeline definition', statusFilter to 'status', and clarifying that top and continuationToken form a pagination mechanism — useful framing but not deep new semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'List recent pipeline runs' for an Azure DevOps project, with concrete filtering options. This inherently distinguishes it from siblings like ado_pipelines_list (lists definitions), ado_pipelines_get_run (single run), and ado_pipelines_trigger (starts runs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys usage context — optional filters and pagination — but never states when to prefer it over alternatives or when not to use it. An agent cannot tell from the description whether to call this vs ado_pipelines_get_run for a specific run without inferring from the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe read operation without side effects. The description adds value by listing the returned fields, including the root suite ID, which gives an agent insight into the response content. However, it doesn't disclose error handling, pagination, or auth requirements. Since the annotations cover the safety profile, a 3 is appropriate—the description contributes some context but not extensive behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no filler. The first sentence states the purpose and identifies the resource; the second lists return fields and gives a pointer to the sibling tool. Information is front-loaded and every word earns its place. This is an example of efficient, well-structured documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with 2 parameters and no output schema, the description is fairly complete. It specifies the return fields and how to obtain the plan ID, which covers the core need. It doesn't mention response format details or edge cases, but given the tool's simplicity and the annotations indicating read-only behavior, these omissions are minor. The description is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both parameters have meaningful descriptions. planId is described as 'Test plan ID' and project as 'Project that owns the plan. Uses default if omitted.' The description adds no additional parameter-level information beyond the schema, but since the schema already documents them well, the baseline of 3 is correct. It doesn't need to compensate for gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves details of a single test plan by ID, which is a specific verb and resource. It lists the returned fields (name, area path, iteration, state, start/end dates, root suite ID), making its scope unambiguous. It also distinguishes itself from the sibling ado_testplans_list, which is for discovering IDs, so an agent can tell them apart without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage hint: 'Use ado_testplans_list to discover plan IDs.' This tells the agent when this tool is appropriate (when a specific plan ID is needed) and points to a sibling for the discovery case. It lacks an explicit 'do not use when' clause, but the context is clear and the alternative is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's read-only nature is not new. However, it adds valuable context beyond annotations: the required PAT scope (vso.wiki) and the exact returned fields (Markdown, URL, last updated, version). This enriches the agent's understanding without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences clearly front-load the purpose and key details. Zero fluff, no repetition of schema information. The auth requirement and output structure are compactly included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation, the description covers the essential aspects: what it fetches, how to identify the page (path), the required auth scope, and the return fields. It does not mention error handling or edge cases, but these are not critical for a straightforward GET. The output schema is absent, but the description compensates by listing the return contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and all parameters (path, wikiId, project) are well-documented in the schema. The description does not add extra parameter-level semantics beyond what the schema provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Fetch'), a definite resource ('a single Azure DevOps wiki page'), and the key discriminator ('by its path'). It also lists what is returned (content, URL, date, version), clearly distinguishing it from sibling tools like ado_wiki_list_pages or ado_wiki_update_page, which are list/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a specific page's content or metadata is needed, given a known path. It does not explicitly state alternatives or when not to use it (e.g., 'use ado_wiki_list_pages to enumerate pages'). The context is clear but the guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the return-value shape, which is useful, but it does not disclose potential behavioral traits such as pagination, size limits, or authentication needs. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of two trimmed sentences: the first states the action and scope, the second covers return context and a downstream pointer. Every word adds value, and the core purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter, no output schema, and read-only annotation, this description is sufficient. It states the input parameter, what will be returned (ID, name, default branch, size), and why the output is useful (use the ID in other tools), so an agent can call it correctly without missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the sole parameter 'project' is 'Project to list repositories from' and schema coverage is 100%, so the parameter is already documented. The tool's description adds no extra parameter-level meaning, making baseline 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb 'List' with a clear resource 'Git repositories in an Azure DevOps project' and explicitly lists the returned fields (ID, name, default branch, size). It distinguishes itself from sibling tools that handle PRs, work items, or pipelines without needing to open any schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit 'use instead of' is present, but there is no competing tool for listing repositories among the siblings. The sentence 'Use the repository ID in other git tools (PRs, search)' gives useful context for when to call this tool, so agents are not left without a reason to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already in annotations, the description adds value by stating what the return fields are (PR ID, title, status, branches, creator, reviewers) and clarifying the project/repository scope. It does not contradict the annotations and provides output behavior useful for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences: first asserts the main action, second lists filters and returned fields, third points to the sibling for deeper detail. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a list tool with complete schema descriptions, annotations, and no output schema, this description is nearly complete: it states return fields, naming the scope, and the sibling to use for detailed metadata. The only minor gap is not explicitly mentioning pagination, but the 'top' parameter is already documented in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for all five parameters, so the baseline of 3 is appropriate. The description mentions 'filter by status and creator' and 'specific repository', which maps to schema fields but adds no additional semantic meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource ('List pull requests') and clearly scopes the tool to a project or specific repository. It also names the sibling 'ado_git_get_pr' for full details, immediately distinguishing this list tool from the detail tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to use this tool and points directly to the sibling 'ado_git_get_pr' when full details on a specific PR are needed. It could be more explicit about when not to use other sibling tools, but the primary alternative is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, but the description adds substantial behavioral context: it explicitly labels the operation as WRITE, states it 'immediately queue[s] a run,' and warns that it 'consume[s] build minutes.' This goes beyond the annotation by disclosing the side effect and resource cost, plus the vso.build_execute PAT scope requirement. The description does not detail idempotency or run lifecycle, but for a trigger tool with readOnlyHint=false, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, highly efficient, and front-loaded with the primary action. It packs essential information—write nature, immediate effect, cost, optional overrides, and auth scope—without any fluff or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, a nested variables object, and an array of stagesToSkip), the description covers the key behavioral aspects: the write action, the immediate queueing, the cost, and the required scope. It does not explain how to obtain pipelineId or project names, but those are operational details likely visible in sibling tools. No output schema exists, so return values are not expected. The description is adequate for an agent to correctly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all five parameters with clear descriptions (project, pipelineId, branch, variables, stagesToSkip), achieving 100% coverage. The description only paraphrases the optional parameters ('override the branch, set pipeline variables, or skip stages') without adding new semantic detail, such as examples, defaults, or cross-parameter constraints. With full schema coverage, the baseline is 3, and the description does not elevate it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb and resource: 'Queue a new pipeline run' with the target being Azure DevOps. It explicitly identifies itself as a WRITE operation, which distinguishes it from sibling read/list tools like ado_pipelines_list_runs and ado_pipelines_get_run. The mention of optional branch/variable/stage overrides further specifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description establishes the primary use case (triggering a new pipeline run) and implicitly differentiates it from read-only siblings by emphasizing the write nature and cost (consuming build minutes). It also notes the required PAT scope, which is a prerequisite. However, it does not explicitly name alternative tools or state when NOT to use this tool, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by specifying the exact return fields, which is beyond what annotations provide. It does not mention pagination behavior or edge cases, but for a read-only list tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero redundancy. The primary action and resource are front-loaded, followed by a usage directive and a concise list of return fields. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list operation with full schema coverage and annotations, the description covers purpose, usage context, and return fields. It does not mention authentication or error handling, but these are not expected for such a straightforward tool and are likely covered at the environment level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with both 'top' and 'skip' parameters clearly described in the schema. The description does not add extra parameter-level semantics beyond what the schema already provides, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'projects in the Azure DevOps organization', and lists the returned fields (name, ID, description, state, url, lastUpdateTime). It is specific and distinguishable from sibling tools that operate on work items, pipelines, or git.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'Use this first to discover available projects before using other tools', giving clear context for when to invoke it. It does not explicitly state when not to use it or mention alternatives, but the context implies it is the discovery entry point and other tools are for specific resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the description carries a lighter burden. It adds meaningful context beyond the annotations: it states the required PAT scope (vso.wiki), describes the automatic resolution of the default project wiki, and explains pagination behavior. No contradiction with annotations is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight three-sentence block. It leads with the core purpose, then details pagination and the fallback, and ends with the auth requirement. Every sentence contributes essential information, with no filler or repeated content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only listing tool with four optional parameters and no output schema, the description covers the essential operational details: response content (paths, URLs, metadata), pagination, the default-wiki auto-resolve, and the auth scope. It does not specify the exact response format, but that is not necessary given the absence of an output schema and the simplicity of the tool. It appears complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters with descriptions (coverage 100%), including the meaning of wikiId, top, and continuationToken. The description adds only a re-statement of some behavior (e.g., 'use top to limit results' and 'pass the returned continuationToken'), which repeats the schema. It does not introduce new semantic information beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List pages') and a clear resource ('pages in an Azure DevOps wiki'), and it distinguishes itself from sibling tools like ado_wiki_list (for discovering wikis) and ado_wiki_get_page (for a single page) via context. It is unambiguous which action this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool (listing pages) and provides guidance for pagination via the continuation token. It also mentions the fallback to ado_wiki_list when auto-resolve of the default wiki fails, which helps route to an alternative. It does not enumerate all 'when not to use' cases, but the primary alternative is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, implying a write operation. The description adds beyond annotations by disclosing the required PAT scope ('Requires vso.work_write PAT scope') and the return behavior ('Returns the created work item with its ID'). It also clarifies that it creates a new item, not a modification. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, both highly informative. The first sentence states the action and required specification; the second covers the return and the prerequisite scope. No filler words or redundant details; it's front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description appropriately mentions the return value (created work item with ID). It also covers the key permission requirement. With 10 parameters, the schema descriptions provide the necessary per-parameter details, and the description offers the high-level usage context. The tool's complexity is moderate, and the description is sufficient, though it could optionally mention handling custom fields via 'additionalFields'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides full descriptions for all 10 parameters (100% coverage), so the description does not need to repeat them. The description only mentions 'project, type, and fields' and lists example types ('Bug, Task, User Story, Epic, Feature, etc.'), which adds marginal context beyond the schema. Since schema coverage is complete, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Create a new work item in Azure DevOps.' It identifies the required inputs (project, type, fields) and the result (returns the created work item with its ID). This distinguishes it from siblings like ado_workitems_update, ado_workitems_query, and ado_workitems_get, which focus on modifying or reading existing items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the purpose explicit: to create a new work item. It does not explicitly call out when not to use it or suggest alternatives like ado_workitems_update for existing items, but the context of sibling tools and the tool name itself make the usage scenario clear. It gives minimal but sufficient guidance for an agent to select it over read/query/update tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=false and openWorldHint=true, the description still adds useful behavioral context by stating it updates existing items and requires the vso.work_write PAT scope. It does not contradict the annotations. It could go further by mentioning side effects like revision creation or invalid field handling, but it is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, action-oriented, and front-loaded. The common fields list is a bit long, but each sentence contributes useful information about the call, the inputs, or the authentication scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers how to perform an update and what permission is needed. Missing, though, is any explanation of the response, validation behavior, or side effects like work item revisions. Since there is no output schema, a bit more return-value context would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all parameters at 100% coverage, so the baseline is 3. The description adds extra value by naming common field reference names like System.State and System.AssignedTo, which the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Update fields'), the resource ('an existing work item'), and the required input pattern (work item ID + field map). It is clearly distinguished from sibling tools like create, query, get, link, and unlink by emphasizing it modifies an existing item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: when updating fields on an existing work item. It even lists common fields, which helps the agent construct useful payloads. However, it does not explicitly mention when not to use it or name alternative siblings such as create or link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description does not need to repeat that it is a safe read. The description adds field-level detail but not additional behavioral context (e.g., permissions, rate limits). Since the annotation covers the primary behavioral aspect, a neutral score is appropriate; the description neither contradicts nor significantly extends the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the primary purpose and fields listed first, followed by a routing instruction. Every word earns its place; there is no redundant or extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
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 all three parameters documented and no output schema, the description provides sufficient detail: it states what the tool does, what it returns, and when to use an alternative. Agents have everything needed to decide and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (project, repositoryId, pullRequestId) have complete descriptions in the schema (100% coverage). The tool description adds no additional parameter semantics, and the schema already explains their meaning. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('pull request'), and enumerates the returned fields (title, description, reviewers, branches, status). It also explicitly differentiates from a sibling tool (ado_git_get_pr_threads) by saying to use that for comments/discussions, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage directive: use this tool for full PR details and use ado_git_get_pr_threads for comments/discussions. This explicit conditional routing directly addresses when to use this tool versus an alternative, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark the tool as readOnlyHint, so the safety profile is covered. The description adds that it returns inline code comments with file paths and line numbers, but it does not mention pagination, response shape, or any additional behavior. With the readOnly annotation in place, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences: the first front-loads the read-me purpose and what it returns; the second promptly routes to the relevant writer sibling. There is no filler, and the most important info appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with fully documented parameters and no output schema, the description tells the agent what it returns (threads, inline comments, file paths, line numbers) and which sibling handles writes. Critical aspects like the resource identifiers are already in the schema, so no essential detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a clear description for all three required parameters with 100% coverage (e.g., 'Repository ID or name', 'Pull request ID'), so the agent has what it needs. The tool description does not add anything meaningful about parameter semantics beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Get all comment threads on a pull request', which is distinct from the sibling tools: it reads threads rather than creates comments. It also names the exact sibling for the complementary write action, so an agent can immediately tell this tool apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly says 'Use ado_git_create_pr_comment to reply to a thread or add a new comment,' which tells the agent when not to use this read-only tool and directs it to the correct alternative. This is a clear when/alternative condition, matching the get_calls calibration example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnlyHint, openWorldHint) by detailing the return fields and highlighting the root suite ID's role in creating child suites. It does not contradict the annotations and adds practical behavioral context about the output's downstream use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action and return fields, the second explains the significance of one field. No redundancy, and the most critical information is front-loaded. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with two optional, well-documented parameters and no output schema, the description is complete. It specifies the returned fields and provides a downstream usage pointer, covering what an agent needs to decide whether to call it and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage of both parameters ('top' with max results and 'project' with default), so the description does not need to add parameter details. It adds no extra meaning beyond the schema, matching the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List test plans') and the resource ('in an Azure DevOps project'), and specifies the returned fields. It is immediately distinguishable from siblings like ado_testplans_get (which presumably retrieves a single plan) and ado_testplans_create (which creates plans).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case: the root suite ID is needed for creating child suites with ado_testsuites_create. This implies when to use it (when you need plan IDs or root suite IDs for downstream operations), but it does not explicitly mention alternatives or when not to use it. The context is clear enough for common scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=false and openWorldHint=true, so the description carries the behavioral burden. It discloses that dynamic suites have read-only membership (changes depend on the WIQL query), that static tests are added manually, and that the operation requires vso.test_write PAT scope. These facts extend beyond the annotations with concrete behavioral and auth detail. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One dense paragraph with a front-loaded purpose statement followed by necessary specifics; every sentence earns its place with suite-type rules, parent placement, and auth scope. It could be mildly improved by bulleting the three suite types, but it is far from bloated and reads efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its 7 parameters (all schema-documented), absence of an output schema, and moderate complexity, the description is nearly complete: it covers all suite types, their required fields, parent placement guidance, and PAT scope. It omits explicit return-value expectations, but with no output schema and schema covering params, that is an acceptable minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so a baseline 3 applies; the description earns a 4 by articulating cross-parameter dependencies (suiteType ↔ requirementId/queryString) and by explaining parentSuiteId semantics ('Use the plan's rootSuiteId... attach directly under root'), which complements the schema's per-parameter text. The schema already echoes some dependency info in the suiteType description, but the description consolidates it into an actionable rule.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Create a new suite inside a test plan') and enumerates the three suite types with their distinguishing characteristics, which separates it cleanly from the sibling ado_testsuites_list (which reads) and ado_testcases_add_to_suite (which adds cases rather than suites). An agent can infer exactly what the tool does and what it does not do.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use context by conditioning each suiteType on its required companion parameter (requirementId, queryString) and by cross-referencing ado_testplans_create/get for obtaining rootSuiteId. It does not explicitly name sibling exclusions (e.g., 'use ado_testcases_add_to_suite for existing cases'), but the type-specific requirements effectively route the agent through the correct setup path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by specifying the exact fields returned, which informs the agent about the output structure. It does not contradict annotations and provides useful context beyond what the schema states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The core action is front-loaded, return fields are listed clearly, and the cross-reference to ado_testplans_list is placed at the end. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with complete schema documentation and readOnlyHint annotation, the description covers all essential aspects: what it lists, what it returns, and how to obtain the required plan ID. No critical information is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters (planId, top, project) are documented. The description does not add any parameter-specific meaning beyond what the schema already provides; it only mentions plan IDs indirectly. Hence, the score aligns with the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all suites') and the resource ('a test plan'), and specifies the return fields (ID, name, type, state, test case count, parent suite ID). It distinguishes itself from the sibling ado_testplans_list by explicitly pointing to that tool for finding plan IDs, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite: 'Use ado_testplans_list to find plan IDs.' This guides the agent on how to obtain a required parameter. However, it does not explicitly contrast with other list tools (e.g., ado_testcases_list) or state when not to use this tool, so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=false, openWorldHint=true), the description discloses a non-obvious side effect (ADO auto-creates a root suite), the response containing rootSuiteId, and the required vso.test_write PAT scope. These add real behavioral value beyond the structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose, non-obvious side effect plus next step, and auth requirement. The most critical operation is front-loaded, and no filler or redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no output schema, the description covers the main purpose, side effects, the important returned field, and the required scope. It could be slightly more complete by stating what the response contains besides rootSuiteId, but given the low complexity and the presence of sibling guidance, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents all parameters. The description adds a connection between the return value (rootSuiteId) and a further tool call, which gives the rootSuiteId context beyond the schema. However, it does not add detail about individual parameters themselves, so a baseline of 4 with this small extra is fair.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Create a new test plan in Azure DevOps.' It also distinguishes itself from sibling reads like ado_testplans_list/get and related create-like tools by describing the automatic root suite creation, which is a unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear usage context by describing the follow-up workflow: 'Pass rootSuiteId as parentSuiteId when calling ado_testsuites_create to add child suites.' It also mentions the required PAT scope. It lacks an explicit 'when not to use' but the siblings are sufficiently different and the context makes the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds the vso.wiki PAT scope requirement and the empty-result meaning, both of which go beyond annotation information. This enriches the agent's understanding without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the main action, and every sentence carries essential guidance. There is no fluff or repetition, and the structure is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter, the description covers purpose, return fields, auth scope, and the edge case of empty results. It lacks pagination details, but for a list of wikis that is unlikely to be a concern, so the completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully describes the sole parameter (project) with a clear description and the omission behavior. The description echoes this but doesn't add new meaning beyond the schema. Since schema coverage is 100%, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (list), resource (wikis), and scope (project or organisation). It explicitly differentiates from sibling tools by noting it is the discovery entry point before using ado_wiki_get_page or ado_wiki_list_pages, so an agent can clearly identify when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to call this first to discover wikiId values, giving a clear when-to-use directive. It also explains the empty result interpretation, which helps avoid confusion. While it doesn't list explicit exclusions, the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, covering the safety profile. The description adds valuable behavioral context beyond that: it discloses that the search returns character offsets rather than matched text, and tells the user to fetch the file separately. This is a meaningful addition that helps the agent set correct expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no fluff. It front-loads the purpose, then explains the return behavior, then provides usage and exclusion guidance. Every sentence earns its place, and it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description adequately covers what the agent can expect (files, paths, repository names, character offsets). It also explains the limitation (no matched text) and directs the agent to a follow-up action. With all parameters documented in the schema and this description covering output and exclusions, nothing essential is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters already have definitions. The description reinforces the optional scoping of project and repositoryName but does not add new semantic details beyond what the schema provides. It meets the baseline for high coverage, neither adding nor detracting significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for code across Azure DevOps repositories, specifies the return format (matching files with paths, repository names, and character offsets), and explicitly distinguishes itself from work item and wiki search by naming the sibling tool ado_workitems_query. This leaves no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it tells the agent it can optionally scope to a project or repository, instructs the agent to fetch the file via the repository API to read matched text, and explicitly states what the tool does NOT do (search work items/wiki) while naming the alternative tool. This is comprehensive and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by disclosing the exact return content (work item ID and title) and hints at the limitation by pointing to a more detailed tool. It doesn't cover pagination or ordering, but those are less critical for a simple list tool with a 'top' parameter 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The action and return value are front-loaded, followed by a single, useful redirect to a sibling tool. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a readOnlyHint annotation and fully documented parameters, the description covers the purpose, the return format, and the primary alternative. Nothing essential is missing; an agent can invoke it correctly using the schema and this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters have descriptions in the schema. The description does not add any additional parameter semantics beyond what the schema already provides, so it earns the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'test cases assigned to a suite,' and explicitly notes what it returns (work item ID and title). It also differentiates itself from ado_workitems_get, which provides full details, so there is no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the alternative tool (ado_workitems_get) and specifies the condition for using it ('for full test case details including steps'), making the usage context clear. It implies this tool is for listing test cases in a suite, which is self-evident from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already indicate readOnlyHint, the description adds behavioral detail about the project validation error and the inclusion of relations, which are not captured in structured data. It does not contradict annotations and provides helpful context for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with no redundancy. The main purpose is front-loaded, and the usage guidance is placed efficiently. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only single-item tool, the description covers what the agent needs: what is retrieved, how to obtain the ID, the project validation edge case, and the relationship to sibling tools. There is no output schema, but the description sufficiently hints at the return contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not need to elaborate on parameters. It does repeat the project error behavior already present in the schema, but adds no new semantic value. Baseline 3 is appropriate given the schema's thorough parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'work item by its ID', and the specific contents ('all fields, description, tags, and relations'). It distinguishes itself from sibling search/list tools by focusing on a single item retrieval, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly directs the agent to use ado_workitems_query or ado_workitems_list_recent to find IDs first, establishing a clear prerequisite and routing. It also discloses the error behavior when a project is supplied and mismatched, which informs correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already flag this as a mutating tool (readOnlyHint=false), so the description adds value by disclosing the required 'vso.work_write' PAT scope and the board-nesting effect of the 'parent' link. It does not contradict the annotations; instead, it enriches the behavioral context with operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: it states the purpose, gives a typical scenario, lists the alternative link types, and notes the scope requirement — all in three sentences. There is no redundant wording, and the most important information (linking action) is placed first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 parameters, all well-documented in schema) and no output schema, the description covers the essentials: core action, typical usage, all link type variants, and the PAT scope prerequisite. There is no missing information that would prevent correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are already described in the schema (100% coverage), but the description adds a concrete example (fromId=Task, toId=Feature) and clarifies that linkType is from fromId's perspective, including what 'parent' means. This goes beyond the schema's generic descriptions and helps the agent avoid direction mistakes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Link' and the resource 'two work items', and immediately distinguishes it from sibling tools like unlink by describing the link creation action. It lists all supported link types and a typical use case, leaving no ambiguity about the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete typical use (setting a Feature as parent of a Task) and enumerates the alternate link types, which helps an agent decide when to call this tool. The prerequisite PAT scope is also stated. However, it does not explicitly contrast with the sibling 'unlink' tool, though the name and context make the distinction clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavior beyond that: results are ordered by last changed date (newest first), which is not stated in the schema. It also implies a non-exhaustive, open-world result set. These are valuable additions, though it does not mention pagination or result shape—but with annotations and a simple listing purpose, a 4 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero filler. The core purpose and ordering behavior are front-loaded, and the usage distinction is given briefly. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with a clear schema (all params documented) and annotations covering safety, the description provides everything an agent needs to invoke it correctly—purpose, ordering behavior, and when to choose an alternative. No output schema is present, but the description doesn't need to explain return values for such a straightforward tool. The only minor gap is pagination, which the 'top' parameter already addresses in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so every parameter (top, type, state, project, assignedTo) is already documented. The description only reiterates that filters are optional and lists type/state/assignee, which adds marginal context but no new semantic details beyond what the schema provides. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List'), the resource ('recently updated work items in a project'), and distinguishes itself from ado_workitems_query by contrasting 'quick overviews' with 'complex filtering'. This gives an agent a precise understanding of what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool ('quick overviews') and when to use an alternative ('use ado_workitems_query for complex filtering'). This direct routing to a sibling leaves no ambiguity and is more than sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description adds useful behavioral detail: the returned fields (ID, title, state, type, assignee) and a WIQL example. It does not describe pagination or error behavior, but read-only safety is covered by the annotation and the description is consistent with it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Measured in three sentences: purpose, example, and return + alternative. Every part earns its place; the example is concrete and the alternative routing is concise. No verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool whose schema covers all parameters, the description is complete: it states the action, gives a full example, lists the return fields, and routes to the appropriate sibling. There is nothing an agent needs to invoke the tool correctly that is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters (query, top, project) are documented. The description adds value beyond the schema by providing a full WIQL example for the query parameter and indicating the returned fields, which helps the agent form correct queries.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: 'Run a WIQL query against Azure DevOps and return matching work items.' It provides a concrete example and distinguishes itself from the sibling ado_workitems_get by explicitly directing users there for full details on a specific item.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance for when this tool is not appropriate: 'Use ado_workitems_get for full details on a specific item.' This establishes a clear boundary, though it does not mention other alternatives like ado_workitems_list_recent or when one would prefer this over those tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal mutation (readOnlyHint=false) and open-world side effects (openWorldHint=true). The description adds concrete behavior: it errors if the link is missing, requires a specific PAT scope, and mandates matching original parameters. This gives an agent a clear picture of side effects and failure modes without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no redundant phrasing. The core purpose leads, followed by the essential usage requirement and error/auth notes. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple unlink operation, the description covers purpose, exact parameter reuse, failure behavior, and authentication. No output schema exists, and none is needed. An agent has all necessary information to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed descriptions for each parameter, including the linkType enum explanation. The description adds semantic value by instructing reuse of the same parameter values used at creation, which helps ensure the correct link is removed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Remove) and resource (an existing link between two work items), making it immediately clear what the tool does. It implicitly differentiates from the sibling ado_workitems_link, which creates links, while this one removes them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit instructions to pass the same fromId/toId/linkType used at creation, which is essential for correct invocation. Also discloses the error condition when the link is absent and the required PAT scope. It does not explicitly name alternatives, but the inverse relationship with ado_workitems_link is obvious from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, so the agent already knows this is a write action with potential side effects. The description adds the specific authorization requirement (vso.code_write PAT scope) and clarifies behavioral constraints (mutual exclusion of threadId and filePath, lineNumber defaults, side values). No contradiction. It stops short of describing the return value, but given no output schema that is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but information-dense, with each clause serving a purpose: purpose, mode distinctions, parameter relationships, and scope requirement. It is structured as a series of clear conditional statements. Slightly long, but every sentence earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters and three distinct modes, the description fully explains how to compose parameters, defaults (endLineNumber defaults to lineNumber), and boundary conditions (threadId vs filePath mutual exclusivity). It also notes the required authorization scope. With no output schema, the description covers all necessary operational guidance; nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema coverage is 100%, the description goes beyond individual parameter schemas to explain inter-parameter dependencies and conditional rules: 'provide threadId (do not provide filePath)', 'lineNumber (start) and endLineNumber (end) for a multi-line range', 'side (‘right’ for new file, ‘left’ for old)'. This contextual nuance is essential for correct invocation and is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add a comment to a pull request.' It then clearly differentiates three distinct usage modes (reply to thread, new general thread, inline code comment), making the tool's purpose unambiguous and distinct from siblings like ado_git_get_pr_threads which only reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use instructions for each mode: 'To reply to an existing thread, provide threadId (do not provide filePath). To create a new general thread, provide only content. To create an inline code comment, provide filePath...' It also states the required PAT scope. This is direct, actionable guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the required vso.test_write PAT scope and the static-suite-only restriction, which are operational behaviors that the agent must know before calling. While the annotations already signal a write operation (readOnlyHint=false) and open-world behavior, they don't disclose the permission or the static-vs-dynamic suite limitation, so the description adds meaningful value. It stops short of explaining partial failure behavior, which is why it's a 4 rather than a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Five short sentences, each carrying a distinct piece of information: what it adds, what the input must look like, how to create good input, which suite type it works on, and what scope it needs. No low-value filler or repetition of the schema it already would see. The action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with a write annotation, the description is complete enough: it states the action, expected input type, related creation workflow, valid suite type, and permission requirement. With no output schema, some descriptions would risk leaving the agent blind on return values, but here the operation is conceptually contained (adding memberships) and the prerequisites that an agent might not guess are all spelled out.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all four parameters at 100% coverage, so the baseline is 3. The description adds genuinely useful semantic constraints: testCaseIds must be work item IDs of type 'Test Case' and the array caps at 100 per call, reinforcing the behavior. The suite must be static (suiteId alone doesn't convey that), which is additional semantic nuance that helps the agent pick a valid suite. This elevates it to a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description leads with the specific verb+resource ('Add existing Test Case work items to a suite') and clarifies that this is for existing test cases only. It also distinguishes itself from sibling tools by telling the agent to use ado_workitems_create for new test case creation, making it unambiguous against the surrounding tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit prerequisite condition: use ad_workitems_create with type='Test Case' first if the items don't exist yet. It also defines a hard constraint – only works for staticTestSuite, whereas dynamicTestSuite membership is query-driven – so the agent knows exactly when to use or not use this tool without opening any schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only readOnlyHint=false and openWorldHint=true in annotations, the description carries the behavioral burden and does so fully. It discloses mutation semantics, conditional vs unconditional overwrite, conflict behavior, return values (updated content and new etag), and authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then covers etag guidance, return values, and auth requirements in a tight sequence. Every sentence adds needed context and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and a mutating operation, the description covers everything needed to call the tool correctly: return values, concurrency behavior, auth scope, and when to omit etag. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3, but the description adds operational meaning: where the etag comes from and what happens with and without it, plus how create and update are tied to the path. It stops short of 5 because the etag description mostly paraphrases the schema and no parameter value constraints or examples are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly names the specific action ('Create or update an Azure DevOps wiki page') and the resource (wiki page at a path). It also explains the create/update conditional behavior, which distinguishes it from read-oriented siblings like ado_wiki_get_page and ado_wiki_list_pages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: pass the etag from ado_wiki_get_page to prevent overwriting concurrent edits, omit it for an unconditional overwrite, and requires vso.wiki_write PAT scope. It also names the failure mode (conflict error), so an agent knows exactly when to use this tool and how to prepare the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

azure-devops-local-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![azure-devops-local-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Laonnda/azure-devops-local-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Laonnda/azure-devops-local-mcp)

Score Badge

Copy to your README.md:

[![azure-devops-local-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Laonnda/azure-devops-local-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Laonnda/azure-devops-local-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Laonnda/azure-devops-local-mcp'

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