arcade-azure-devops-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools target distinct Azure DevOps resources and actions. The only potential confusion is between QueueBuild and RunPipeline, which both trigger pipeline executions but on different pipeline types.
Naming Consistency4/5
Tools follow an AzureDevops_VerbNoun pattern consistently. One deviation is MyWorkItems, which lacks a verb, but all other names are predictable.
Tool Count3/5
With 21 tools, the server leans toward the heavy side, covering many Azure DevOps areas from projects to wikis. Each tool serves a distinct purpose, but the count is above the typical 3-15 well-scoped range.
Completeness3/5
The tool surface covers core read and create operations for work items, PRs, and builds, but lacks important lifecycle actions such as updating or merging pull requests, creating projects/repositories, and managing teams. These gaps will require agents to work around missing operations.
Average 3.2/5 across 21 of 21 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Queue a new build' reveals nothing about synchronous/asynchronous behavior, return values, auth requirements, or side effects. This is a significant omission for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is minimal and free of fluff, but it is under-specified rather than appropriately concise. A single short sentence may be suitable for a trivial tool, yet here it omits useful context, so it doesn't fully earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, the description is incomplete. It fails to explain what happens after queueing, whether it returns a build ID or URL, or how it relates to similar tools like RunPipeline, leaving the agent under-informed.
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 parameter meanings are already well-documented in the input schema (e.g., project, definition_id, source_branch). The description adds no additional semantic value beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Queue a new build' clearly states the verb ('Queue') and resource ('a new build'), making the primary action unambiguous. However, it fails to distinguish this tool from sibling AzureDevops_RunPipeline, which could also queue builds, so it doesn't fully differentiate.
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 like AzureDevops_RunPipeline or AzureDevops_ListBuildDefinitions. The description gives no context, prerequisites, or exclusions, leaving the agent to guess the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It does not mention side effects, permissions needed, whether it is a mutating operation, or what happens after creation. For a tool that creates a PR, this is a significant omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it merely restates the tool's name and lacks substantive content. It is under-specified rather than appropriately concise; the sentence does not earn its place because it offers no information beyond what the name implies.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description is too sparse. It does not explain return values, required branch formats, or any PR creation nuances, leaving the agent to rely solely on the schema without higher-level context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds nothing about parameters, but the schema already documents each parameter (e.g., source_ref_name, target_ref_name) with clear descriptions, so no additional semantic value is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new pull request'), which distinguishes it from list/search tools among siblings. However, it does not add any specifics about the PR creation process or what makes it different from other create tools.
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, nor any prerequisites or typical scenarios (e.g., 'use when you need to merge a branch'). The sentence only states the action without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Create a new work item,' with no explanation of side effects, required permissions, state changes, or what occurs with the provided fields. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it is under-specified for a tool with 9 parameters and no other documentation. While it is not verbose, it is not appropriately sized for the complexity, bordering on under-specification rather than efficient conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no output schema, and no annotations, the description is highly incomplete. It doesn't explain the work item domain, the significance of required fields, or the expected return value. The schema provides structural info, but the description fails to give necessary context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all 9 parameters. The description adds no parameter information, but the schema already provides adequate semantics. Per the baseline rule, a score of 3 is appropriate when schema covers all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create a new work item' which clearly identifies the verb (create) and resource (work item). It doesn't explicitly differentiate from siblings like UpdateWorkItem or GetWorkItem, but the verb alone distinguishes it. The description is clear but adds no extra context beyond the tool name.
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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any prerequisites, exclusions, or relationship to other work item operations. There is no implied context beyond the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action and does not mention side effects, asynchronous behavior, required permissions, or return values, which is insufficient for an agent to anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with no waste. However, it is under-specified, lacking important context that would make it genuinely useful. It is concise but not structurally complete.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that starts a pipeline run, the description omits any information about what happens after invocation, expected outputs, or usage scenarios. With no annotations and no output schema, the description alone is insufficient to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear descriptions for all three parameters (branch, project, pipeline_id). The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start a new pipeline run' uses a specific verb and resource, clearly indicating the tool triggers a pipeline run. However, it does not differentiate from the sibling tool AzureDevops_QueueBuild, which likely performs a similar function, so it misses the 'distinguishes from siblings' criterion.
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 like AzureDevops_QueueBuild or when not to use it. The description simply states the action without any context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It only says 'Get details', which implies a read operation, but offers no additional behavioral context such as return format, pagination, error conditions, or permission requirements. The verb 'Get' is the only hint, and that's not enough to disclose behavioral traits.
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 a single, succinct sentence with no fluff. It gets straight to the point, which is good. It could be more informative, but for the information it does contain, there is zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with one parameter and no output schema, the description is minimally adequate but lacks richness. It doesn't clarify return value details or how this tool should be sequenced with ListProjects if the caller doesn't know the project identifier. The tool is simple enough that this might be sufficient, but it's not fully 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?
The input schema already covers the single parameter 'project' with description 'Project name or ID' (100% coverage). The tool description adds no extra semantic meaning beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action ('Get details') on a specific resource ('a specific Azure DevOps project'), which distinguishes it from sibling tools like ListProjects (which lists all projects) and GetWorkItem (which targets work items). While 'details' is somewhat generic, the core purpose is unambiguous.
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 doesn't mention that the caller should already know the project name/ID or consider using ListProjects first to find an ID. There are no exclusions or contextual hints beyond the literal action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Get a specific wiki page' and does not mention the include_content parameter, return format, error behavior, or any operational side effects. This is insufficient for a tool with no annotation support.
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 single sentence, front-loaded with the action and resource, containing zero fluff. It is concise and to the point, which is appropriately sized for a simple GET operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, this description is too sparse. It does not explain what the response contains, the role of the include_content flag, or any constraints on the path. For a tool with 4 parameters and no structured output schema, the description is inadequate for the agent to fully understand the tool's behavior.
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 already provides complete parameter descriptions (100% coverage), so the baseline is 3. The description adds no additional meaning about parameters or their semantics; it simply restates the general purpose without enriching the meaning of path, project, wiki_identifier, or include_content.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('specific wiki page'), making it easy to identify what the tool does. However, it does not explicitly differentiate from sibling tools like AzureDevops_ListWikis, and lacks additional scope details such as the required project/wiki/path parameters.
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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or exclusions. There is no mention of when to use this over other wiki-related tools, leaving the agent without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only states that it runs a query, without describing output format, pagination, error handling, or whether it is read-only. This is insufficient for an agent to fully anticipate effects.
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 single, direct sentence with no redundant words. It is front-loaded and immediately communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, leaving the description as the only behavioral guidance. It is too minimal to be fully actionable; it does not explain the query syntax requirements, the meaning of 'top', or what a successful result contains. An agent would need to rely on the schema alone.
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 descriptions for all three parameters (top, query, project), giving 100% coverage. The description itself adds no extra parameter context, but the schema already handles parameter semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Run a WIQL (Work Item Query Language) query' clearly states the specific action and resource, using a verb+resource structure. It does not explicitly differentiate from sibling tools like AzureDevops_SearchCode or AzureDevops_MyWorkItems, but naming WIQL is sufficiently specific for an Azure DevOps work item context.
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?
There is no guidance on when to use this tool versus alternatives such as AzureDevops_MyWorkItems or AzureDevops_GetWorkItem. The description does not mention prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavioral traits. It only states the action without mentioning permissions, side effects, reversibility, or return behavior, which is insufficient for a write 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?
The description is a single, front-loaded sentence with zero redundant content. It communicates the purpose immediately without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description should provide more context about return values or side effects. It is too minimal for an agent to fully understand the tool's behavior beyond the basic action.
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 three parameters with clear descriptions (text, project, work_item_id), so baseline is 3. The description itself adds no extra parameter 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 uses a specific verb ('Add') and a clear resource ('a comment to a work item'), which directly distinguishes it from siblings like GetWorkItem and UpdateWorkItem. It 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as UpdateWorkItem or CreateWorkItem. There are no context clues, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must convey behavioral traits. It merely states 'Get a work item by ID' without disclosing read-only behavior, error conditions, or response format. The verb 'Get' implies read-only, but this is implicit and not explicit enough.
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 single, short sentence with no unnecessary words. It is front-loaded and immediately communicates the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and does not cover important contextual information such as usage scenarios or behavioral guarantees. With no annotations and no output schema, the agent lacks information about safe invocation, error handling, or return structure, making it incomplete for a standalone tool 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?
The input schema has 100% description coverage, with each parameter (expand, project, work_item_id) having a schema description. The tool description adds no additional parameter semantics beyond the schema, so 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 uses a specific verb 'Get' with a clear resource 'work item' and identifies the unique criterion 'by ID'. This clearly distinguishes it from sibling tools like AzureDevops_UpdateWorkItem or AzureDevops_MyWorkItems.
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?
The description provides no guidance on when to use this tool versus alternatives such as AzureDevops_RunWorkItemQuery or AzureDevops_MyWorkItems. It only states the basic operation, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description carries the full burden of disclosing behavior. It provides no detail on return format, pagination, authentication requirements, read-only nature, or search limitations. This is a critical gap for a code search tool.
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 single, ultra-concise sentence with no filler or redundancy. It is front-loaded and every word earns its place, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description alone must provide sufficient context. It fails to explain what the search results look like, whether it searches all branches or just the default, or any constraints. For a simple search tool, it is incomplete and leaves the agent guessing about expected responses.
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 each parameter having a description in the input schema. The tool description adds no extra semantic value beyond the schema, so the baseline of 3 is appropriate. It does not clarify relationships or defaults, but the schema already covers the basic meaning.
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 ('Search'), the target ('code'), and the scope ('across repositories'), which is specific and distinguishes it from sibling tools like AzureDevops_SearchIdentities. This is a strong verb+resource+scope formulation.
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 code search is needed, but it does not explicitly state when to use this tool over alternatives, nor does it mention any exclusions or prerequisites. There is no guidance on when not to use it, so it only reaches an 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It only says 'update an existing work item' without clarifying whether the operation is a partial update (only provided fields change) or a full replacement, how errors are handled (e.g., nonexistent work item), or permission requirements. This is a significant gap for a mutating tool.
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 single concise sentence with no redundant wording or filler. It is immediately clear and front-loaded, earning a high score for structure despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no annotations, and no output schema, the description is under-specified. It does not explain the return value or success condition, whether the update is partial, or any side effects. The minimal one-liner is insufficient for an agent to fully understand the tool's behavior, especially compared to sibling tools that provide more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are already described in the input schema, satisfying schema_description_coverage at 100%. The description itself adds no additional meaning to parameters, but per the rubric, a baseline of 3 is appropriate when the schema already documents parameters. No extra syntax or behavior details are provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('update') on a specific resource ('existing work item'), clearly indicating it modifies an existing item rather than creating a new one. However, it does not differentiate from sibling 'AddWorkItemComment' which also modifies a work item, but the core purpose is still unambiguous.
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 does not explicitly state when to choose this tool over alternatives like 'CreateWorkItem' or 'GetWorkItem'. The usage context is implied by the word 'update' and the required 'work_item_id' parameter, but there is no explicit guidance on exclusions or alternatives, making it minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention any potential side effects, required permissions, rate limits, or output structure. While 'List' implies a read-only operation, the description offers no additional context about behavior beyond what is inherent in the verb.
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 single, front-loaded sentence with no redundant information. It conveys the core purpose efficiently and is appropriately sized for the tool's simplicity.
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?
The tool has a modest schema with 4 parameters and no output schema. The description does not explain return values, pagination, or filtering behavior, but the schema covers the parameters. Given the simplicity of the tool, a 'List branches' description is acceptable, but it lacks some contextual detail that would make it fully 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?
The input schema provides descriptions for all 4 parameters, achieving 100% coverage. The description adds no extra meaning beyond the schema, but per the calibration baseline, a score of 3 is appropriate when the schema fully documents parameters. The optional 'top' and 'filter_contains' parameters are described in the schema, not the description.
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' with a specific resource ('branches') and scoping ('in a repository'). This distinguishes it from sibling tools like AzureDevops_ListRepositories and AzureDevops_ListBuilds, making the tool's 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or exclusion conditions. The description simply restates the function without providing context about when it is the appropriate choice, such as when a user needs to inspect branch names in a specific repo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It simply states 'List all projects' but does not disclose pagination behavior (top/skip) or the ability to filter by state, nor does it mention that 'all' may be limited by these parameters. No information about read-only nature, return format, or authentication is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is concise and front-loaded, clearly stating the primary action and 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?
The tool is relatively simple with no required parameters and full schema coverage, so the description plus schema may be minimally sufficient. However, the description does not clarify that pagination parameters affect the 'all' claim, and with no output schema, the agent lacks information about the return structure. It is adequate but has clear gaps.
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 all three parameters (top, skip, state_filter) already described in the input schema. The description itself adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('projects') with clear scope ('in the Azure DevOps organization'). It clearly distinguishes from sibling tools like 'AzureDevops_GetProject' (which fetches a single project) and other list tools (e.g., ListTeams, ListRepositories).
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for enumerating projects, whereas GetProject is for a specific project, nor does it discuss any exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action but does not disclose pagination behavior, ordering, permissions, or return format. The presence of 'top' and 'skip' parameters suggests potential deviation from 'all' but is not explained.
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?
A single, front-loaded sentence with no unnecessary words. It is appropriately concise for a simple list tool.
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?
The description is minimally adequate for a straightforward list operation with complete schema, but it lacks behavioral context and return-value details. No output schema exists, so the description could have clarified output expectations.
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 descriptions comprehensively cover all three parameters (project, top, skip), and the description adds no additional parameter semantics. Baseline 3 is appropriate given the 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 verb 'List' and the resource 'teams', scoped by 'project'. This effectively distinguishes it from sibling tools like ListProjects or ListWikis.
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 neither names alternative tools nor mentions explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'list' with no mention of pagination limits (despite the 'top' parameter), default behavior, or response shape. It does not contradict any annotation, but fails to disclose behavioral traits.
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 single, front-loaded sentence with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description is minimal but adequate. However, without an output schema or annotations, it would benefit from mentioning response contents or pagination behavior. The 'top' parameter hints at pagination but the description does not explain defaults or result format.
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 baseline is 3. The description adds no additional parameter semantics, but the schema itself documents all three parameters with meaningful descriptions.
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 uses a specific verb 'List' with a clear resource 'build/pipeline definitions' and scoping 'in a project.' It distinguishes itself from the sibling 'ListBuilds' by explicitly referring to definitions rather than builds.
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 the tool is for listing definitions in a project, but provides no explicit guidance on when to use it over alternatives like ListBuilds, nor any conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only says 'list builds' and does not mention filtering behavior, pagination, default limits, or any other operational aspects. This is minimal transparency for a tool that accepts multiple filters.
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 single, direct sentence with no unnecessary words. It is front-loaded and easy to parse, making it appropriately concise and well-structured.
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?
While the schema covers all parameters, the description lacks any context about return values, defaults, or behavior with filters. Since there is no output schema, the description could have provided more completeness, but the tool is relatively simple and the purpose is clear.
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 already describes all parameters with 100% coverage, so the baseline is 3. The description adds no additional meaning about parameters beyond the schema, but also does not conflict with 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 'List builds in a project' uses a specific verb ('list') and a clear resource ('builds') scoped to a project. It distinguishes from siblings like AzureDevops_ListBuildDefinitions and AzureDevops_QueueBuild, which target different resources.
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 only states what the tool does, with no explicit guidance on when to use it versus alternatives or exclusions. The usage is implied by the name and description, but no alternatives or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool does and fails to mention default behavior, filtering options, pagination, or any side effects. This is a significant gap for a list 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?
The description is a single, front-loaded sentence with no redundant words. It is appropriately sized for a simple list tool and every word earns its place.
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?
The tool is relatively simple and the schema covers parameters, but the description lacks contextual information about default status, result limits, or how to use the status filter. It is minimally sufficient but has clear gaps.
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 per the rubric, a baseline of 3 is appropriate. The description itself adds no parameter meaning beyond the schema, but the schema fully documents all four parameters.
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 'pull requests in a repository', which is specific and distinguishes it from siblings like ListRepositories or CreatePullRequest. It fully captures 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly mention when to use this tool versus alternatives, but the purpose is clear enough that usage is implied. No exclusions or alternative suggestions are provided, which is a gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (list) but does not mention read-only nature, required permissions, pagination, or potential limitations (e.g., whether hidden repositories are included). This lacks transparency for a tool with no annotation safety signals.
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 single, front-loaded sentence that is concise and free of filler. Every word contributes to conveying the tool's purpose.
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?
The tool is simple with one parameter and no output schema, so a brief description is acceptable. However, it provides no information about return format or potential variations in behavior, leaving some gaps in contextual completeness.
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% because the single parameter 'project' is described as 'Project name or ID'. The description adds no additional meaning beyond the schema, so the baseline of 3 applies.
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 'List all Git repositories in a project' uses a specific verb (List), identifies the resource (Git repositories), and specifies the scope (project). This clearly distinguishes it from sibling tools like ListBranches and ListProjects.
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 context by stating 'in a project', suggesting the tool is used when you have a project and need its repositories. However, it provides no explicit guidance on when to prefer this over other listing tools or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the basic operation and omits important behavioral traits such as default filtering (e.g., whether completed items are included unless include_completed is set), pagination behavior via the 'top' parameter, or the shape of the returned data. The description does not contradict annotations (there are none), but it provides minimal transparency.
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 single, front-loaded sentence that succinctly states the tool's purpose. Every word earns its place, with no filler or redundancy.
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?
The tool has a simple interface with fully described parameters, so the description need not explain parameter semantics. However, it lacks critical contextual details such as the default behavior regarding completed work items, the meaning of 'assigned to the current user' in relation to the required project parameter, and any implicit limits or return format. Given the absence of an output schema and annotations, the description is adequate but leaves gaps an agent would need to infer.
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% for all three parameters (project, top, include_completed), so the schema already defines each parameter's meaning. The tool description itself adds no extra semantic value beyond what the schema provides, so the baseline of 3 applies.
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 gets work items assigned to the current user, distinguishing it from sibling tools like GetWorkItem (which fetches a specific item) and RunWorkItemQuery (which runs custom queries). The verb 'Get' and resource 'work items' are specific and unambiguous.
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 the primary use case—retrieving the current user's assigned work items—but provides no explicit guidance on when to choose this tool over alternatives, such as GetWorkItem for a single item or RunWorkItemQuery for complex queries. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states that the tool searches, implying a read-only operation, but provides no details about the return format, result limits, authentication needs, or side effects. Since no annotations are present, the description carries the full burden, and this minimal disclosure is insufficient for full transparency.
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 single, concise sentence without any redundancy. It directly states the tool's purpose and avoids unnecessary words, earning a high score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description provides a minimal but acceptable overview. However, it lacks context about the output structure or any behavioral limitations, leaving the agent with some uncertainty about what to expect from the call.
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 covers both parameters (search_filter and filter_value) with clear descriptions, so the tool description adds no additional semantic value. The schema provides the necessary meaning, giving a 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 identifies the action ('Search') and the resource ('identities (users/groups) in Azure DevOps'). It distinguishes itself from sibling tools that target work items, pull requests, and other resources, making the tool's 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: use when searching for identities in Azure DevOps. However, there is no explicit guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. The implied context from the description is sufficient but not detailed.
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?
No annotations are provided, so the description carries the burden. It discloses the scope (project or organization), but omits behavioral details like what happens when 'project' is omitted (does it default to organization?), the shape of the returned data, or pagination. For a read-only list operation, this is adequate but minimal.
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 single, short sentence with a front-loaded verb and no redundant words. It is appropriately concise for the tool's simplicity.
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?
The tool is simple (one optional parameter, no output schema), and the description gives the essential purpose and scope. However, it could clarify the behavior when 'project' is absent and mention the return type, but these gaps are minor for a list operation.
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 covers 100% with 'Project name or ID (optional)'. The tool description adds the 'organization' dimension, hinting at alternate behavior, but does not explain how the parameter selects between project- and organization-level listing beyond the schema's own text.
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 uses a specific verb 'List' with a clear resource 'wikis' and scope 'project or organization'. It distinguishes from sibling tools like AzureDevops_GetWikiPage, which fetches a single page, and other list tools for different resources.
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 given on when to use this tool versus alternatives. It doesn't mention when to prefer it over GetWikiPage or other list tools, nor any exclusions or prerequisites. The agent is left to infer usage from the action alone.
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

Copy to your README.md:

[![arcade-azure-devops-mcp MCP server](https://glama.ai/mcp/servers/subrahmaniank/arcade-azure-devops-mcp/badges/card.svg)](https://glama.ai/mcp/servers/subrahmaniank/arcade-azure-devops-mcp)

Score Badge

Copy to your README.md:

[![arcade-azure-devops-mcp MCP server](https://glama.ai/mcp/servers/subrahmaniank/arcade-azure-devops-mcp/badges/score.svg)](https://glama.ai/mcp/servers/subrahmaniank/arcade-azure-devops-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/subrahmaniank/arcade-azure-devops-mcp'

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