Azure DevOps MCP Server for Cline

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources and actions in Azure DevOps, with no ambiguous overlaps. For example, create_wiki vs get_wikis vs update_wiki_page are clearly differentiated operations on the same resource type.
Naming Consistency5/5
All tools follow a consistent verb_noun naming pattern with snake_case throughout. The verbs (create, get, list, trigger, update) are used predictably across different resource types (wiki, work_item, boards, pipelines, projects, pull_requests).
Tool Count5/5
13 tools is well-scoped for an Azure DevOps server covering multiple domains (wikis, work items, boards, pipelines, projects, pull requests). Each tool earns its place with clear utility, avoiding both thin coverage and bloat.
Completeness4/5
The toolset provides excellent CRUD/lifecycle coverage for wikis and work items, with good project and pipeline operations. Minor gaps include missing pull request creation/management tools and limited board operations beyond listing, but core workflows are well supported.
Average 2.9/5 across 13 of 13 tools scored.
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
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It fails to mention side effects (e.g., changing status to 'completed' might trigger a merge), authorization requirements, or whether notifications are sent. This is a critical gap 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that merely repeats the tool name. It is under-specified and does not earn its place; it could be expanded with key details like the modifiable fields or constraints.
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 5 parameters (2 with enums) and no output schema, the description should provide context on how to use the tool effectively. It omits important details like the implications of status changes or the optionality of parameters beyond what the schema says.
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 clear description ('New title (optional)', etc.). The tool description adds no extra meaning beyond the schema. According to guidelines, with high schema coverage, a baseline 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 'Update an existing pull request' clearly states the action (update) and the resource (pull request). It distinguishes from sibling tools like 'create_pull_request' (create vs update) and 'list_pull_requests' (list vs update). However, it could be more specific about which fields can be updated.
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 vs alternatives (e.g., when to use 'list_pull_requests' instead) or any prerequisites (e.g., the pull request must exist). No when-not-to-use information is given.
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 'Create a new wiki' which implies a write/mutation operation, but doesn't cover permissions needed, whether creation is idempotent, what happens on conflicts, or what the response looks like. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loading the core action without any fluff. Every word earns its place, though this brevity contributes to gaps in other dimensions.
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 this is a mutation tool with no annotations, no output schema, and sibling tools that suggest a wiki management context, the description is incomplete. It doesn't explain what a 'wiki' is in this system, what gets created, or how it relates to other wiki tools, leaving significant gaps for an agent.
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 coverage is 100%, so the schema already documents all three parameters (name, projectId, mappedPath) with their types and optionality. The description adds no parameter-specific information beyond what's in the schema, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new wiki' states the basic action (create) and resource (wiki), but it's vague about what a 'wiki' entails in this context and doesn't distinguish it from sibling tools like 'create_work_item' or 'update_wiki_page'. It provides minimal but functional purpose information.
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 offers no guidance on when to use this tool versus alternatives like 'update_wiki_page' or 'get_wikis', nor does it mention prerequisites such as needing a project context. It's a bare statement with no contextual usage information.
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 states the tool lists pull requests but doesn't describe key behaviors such as pagination, rate limits, authentication requirements, or what 'list' entails (e.g., format, sorting, or default limits). The description is minimal and lacks essential operational details for a tool with potential complexity.
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 extremely concise with a single sentence: 'List all pull requests in the project'. It is front-loaded and wastes no words, making it easy to parse. Every part of the sentence contributes directly to the tool's purpose, earning its place without redundancy or fluff.
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 complexity of listing pull requests (which often involves pagination, filtering, and authentication), no annotations, and no output schema, the description is incomplete. It lacks details on behavioral traits, return values, and operational constraints. The schema covers parameters well, but the overall context for effective tool use is insufficient, especially for a tool that likely interacts with a version control system.
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, clearly documenting all three parameters (status, creatorId, repositoryId) with enums and optionality. The description adds no parameter semantics beyond what the schema provides, as it doesn't mention any parameters. With high schema coverage, the baseline score of 3 is appropriate, as the schema adequately handles parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose as 'List all pull requests in the project', which is clear but vague. It specifies the verb ('List') and resource ('pull requests'), but lacks specificity about scope or differentiation from sibling tools like list_projects or list_work_items. It doesn't clarify what 'all' entails (e.g., across repositories or within a specific 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a project context), exclusions, or comparisons to sibling tools like list_work_items (which might overlap in functionality). Usage is implied by the name and description alone, with no explicit context or alternatives 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 full burden but only states the action without behavioral details. It doesn't disclose if this is a write operation (likely, but not confirmed), what happens on trigger (e.g., runs immediately, requires permissions), or any side effects like rate limits or costs. This leaves significant gaps 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?
The description is a single, efficient sentence with zero wasted words. It's front-loaded and directly states the tool's purpose without unnecessary elaboration, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete for a mutation-like tool. It doesn't cover behavioral traits (e.g., what 'trigger' does operationally), expected outcomes, or error handling. For a tool with 3 parameters and likely write actions, this minimal description leaves too much undefined.
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 parameters are well-documented in the schema. The description adds no additional meaning beyond implying 'pipelineId' is required (matching schema), but it doesn't explain parameter interactions or usage nuances. Baseline 3 is appropriate as the schema handles the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Trigger a pipeline run' clearly states the action (trigger) and resource (pipeline run), but it's vague about what 'trigger' entails—does it start, schedule, or initiate? It doesn't differentiate from sibling tools like 'list_pipelines', which is a read operation, but the distinction is implied rather than explicit.
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. For example, it doesn't mention prerequisites (e.g., needing a valid pipeline ID) or contrast with siblings like 'list_pipelines' for viewing pipelines. The description lacks context for decision-making.
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 it's a creation tool, implying a write operation, but doesn't cover permissions, side effects, error handling, or response format. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and method, making it easy to parse quickly.
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 complexity of a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what a 'work item' is, provide usage context, describe behavioral traits, or hint at the return value, leaving significant gaps for an AI agent to operate effectively.
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 coverage is 100%, with clear documentation for both parameters ('type' and 'document'). The description adds minimal value beyond the schema by mentioning 'JSON patch operations', which aligns with the 'document' parameter's structure, but doesn't provide additional context like examples or constraints beyond what's in the schema.
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 a new work item') and the method ('using JSON patch operations'), which distinguishes it from sibling tools like 'list_work_items' or 'update_work_item'. However, it doesn't specify what a 'work item' is in this context, leaving some ambiguity about the resource being created.
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 prerequisites, when to choose this over 'update_work_item', or any context-specific conditions for creating work items, leaving the agent to infer usage from the tool name alone.
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 it's a list operation, implying read-only behavior, but does not cover aspects like pagination, rate limits, authentication needs, or what 'available' means (e.g., filtered by permissions). This leaves significant gaps 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, clear sentence with no wasted words, front-loading the core purpose efficiently. It is appropriately sized for a simple list tool, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., how results are returned), does not clarify the scope of 'available', and omits usage context relative to siblings. For a tool in this environment, more information is needed to guide effective use.
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 one optional parameter 'team' documented. The description does not add any meaning beyond the schema, as it does not explain parameter usage or constraints. Baseline score of 3 is appropriate since the schema handles parameter documentation adequately.
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 ('List') and resource ('available boards in the project'), making the tool's purpose understandable. However, it does not differentiate from sibling tools like 'list_projects' or 'list_work_items' beyond the resource name, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 how it differs from 'list_work_items' or 'get_wikis'. There is no mention of prerequisites, exclusions, or context for usage, leaving the agent without direction.
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. 'Get a wiki page by path' implies a read-only operation, but it doesn't disclose any behavioral traits such as authentication requirements, rate limits, error handling, or what happens if the page doesn't exist. The description is minimal and lacks critical context for safe and effective 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?
The description 'Get a wiki page by path' is a single, efficient sentence that front-loads the core purpose without unnecessary words. It's appropriately sized for a simple retrieval tool, with zero waste or redundancy, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete for a tool with 4 parameters and read operations. It doesn't explain return values, error cases, or behavioral constraints, leaving significant gaps. For a get operation, more context on what 'Get' entails (e.g., content format, permissions) is needed to be fully helpful.
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 parameters documented in the schema (wikiIdentifier, path, version, includeContent). The description adds no meaning beyond the schema—it doesn't explain parameter relationships, format examples, or usage nuances. Baseline is 3 since the schema does the heavy lifting, but the description doesn't compensate with additional insights.
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 'Get a wiki page by path' clearly states the verb 'Get' and resource 'wiki page', with the method 'by path' providing specific retrieval mechanism. It distinguishes from siblings like 'get_wikis' (list wikis) and 'update_wiki_page' (modify), though not explicitly named. However, it doesn't fully differentiate from 'get_work_item' or other get_* tools in purpose beyond the resource type.
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 when to choose this over 'get_wikis' (for listing wikis) or 'update_wiki_page' (for modifications), nor does it specify prerequisites like needing a wiki identifier. Usage is implied only by the tool name and description, with no explicit context or exclusions 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 provided, the description carries full burden for behavioral disclosure. 'Get work items by IDs' implies a read-only operation, but it doesn't specify authentication requirements, rate limits, pagination behavior, error responses, or what happens with invalid IDs. The description lacks details on return format, performance characteristics, or side effects, leaving significant gaps for a tool with 5 parameters.
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, efficient phrase ('Get work items by IDs') that front-loads the core purpose without unnecessary words. Every word earns its place: 'Get' specifies the action, 'work items' the resource, and 'by IDs' the key input mechanism. There's no redundancy or fluff.
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's complexity (5 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error handling, or behavioral nuances like how 'errorPolicy' affects responses or what 'asOf' means in practice. For a read operation with multiple configuration options, more context is needed to guide effective use.
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 parameters well-documented in the schema itself (e.g., 'ids' as work item IDs, 'fields' with examples, 'asOf' with format, enums for '$expand' and 'errorPolicy'). The description adds no additional parameter semantics beyond what's in the schema, so it meets the baseline of 3 where the schema does the heavy lifting.
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 'Get work items by IDs' clearly states the verb ('Get') and resource ('work items'), and specifies the primary input mechanism ('by IDs'). It distinguishes from siblings like 'list_work_items' (which presumably lists without specific IDs) and 'get_boards' (different resource). However, it doesn't explicitly differentiate from 'get_wiki_page' or 'get_wikis' in terms of resource type specificity.
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 sibling tools like 'list_work_items' (for listing without specific IDs) or 'update_work_item' (for modifications), nor does it specify prerequisites, error handling context, or typical use cases. Usage is implied only by the tool name and parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't address permissions, pagination, rate limits, or response format. For a tool with zero annotation coverage, this is insufficient 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, clear sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list tool, making it highly efficient.
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, the description is incomplete. It doesn't explain what a 'pipeline' entails in this context, how results are returned, or any behavioral constraints. For a tool with no structured metadata, more context is needed.
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 description mentions no parameters, but the input schema has 100% coverage with clear descriptions for both optional filters ('folder' and 'name'). Since the schema does the heavy lifting, the baseline score of 3 is appropriate—the description adds no parameter semantics beyond what the schema provides.
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 verb ('List') and resource ('all pipelines in the project'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling tools like 'list_projects' or 'list_work_items' beyond the resource type, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites, context for filtering, or how it relates to sibling tools like 'trigger_pipeline' or other list operations. This leaves 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('list') but doesn't describe what 'list' entails—e.g., whether it returns all items, supports pagination, requires authentication, or has rate limits. For a tool with no annotation coverage, this leaves critical behavioral traits unspecified, though it doesn't contradict any 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 a single, efficient sentence with zero wasted words—'List work items from a board' directly conveys the tool's function. It's appropriately front-loaded with the core action and resource, making it easy to parse. No extraneous details or redundancy are present, earning full marks for 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's complexity (a list operation with filtering), lack of annotations, and no output schema, the description is incomplete. It doesn't address return format (e.g., list structure, fields included), pagination, error conditions, or authentication needs. For a tool that likely interacts with a board system, this leaves significant gaps in understanding how to use it effectively.
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 the single parameter 'query' documented as 'WIQL query to filter work items'. The description adds no additional parameter semantics beyond this, as it doesn't explain WIQL syntax, provide examples, or clarify filtering scope. Given the high schema coverage, a baseline score of 3 is appropriate, as the schema does the heavy lifting.
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 verb 'list' and resource 'work items from a board', making the purpose immediately understandable. It distinguishes this from sibling tools like 'get_work_item' (singular retrieval) and 'create_work_item' (creation), though it doesn't explicitly mention these distinctions. The description is specific enough to understand the core function without being tautological.
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 when to use 'list_work_items' versus 'get_work_item' (for single items) or 'get_boards' (for board metadata), nor does it specify prerequisites like needing board access. The agent must infer usage from context alone, which is insufficient for clear decision-making.
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 full burden for behavioral disclosure. 'Create or update' implies mutation but doesn't specify permissions needed, whether changes are reversible, rate limits, or what happens when updating versus creating. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.
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, efficient sentence with zero wasted words. It's appropriately sized for the tool's complexity and gets straight to the point without unnecessary elaboration.
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 mutation tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on creation versus update, what the response looks like, or any error conditions. Given the complexity of a wiki page operation with 4 parameters, more context is needed.
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 parameters are fully documented in the schema. The description adds no additional parameter information beyond what's already in the structured fields. This meets the baseline expectation when schema does the heavy lifting.
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 'Create or update a wiki page' clearly states the verb (create/update) and resource (wiki page), making the purpose immediately understandable. However, it doesn't differentiate from sibling 'create_wiki' which might create an entire wiki versus a page, leaving some ambiguity about sibling tool boundaries.
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 like 'create_wiki' or 'update_work_item'. It doesn't specify prerequisites, conditions for creation versus update, or any context about when this is the appropriate choice among available tools.
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 provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects, return values, error conditions, or authentication requirements.
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?
A single sentence that is concise and directly states the purpose. While it lacks structure (e.g., listing key parameters), it is not verbose and is easy 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 6 parameters and no output schema, the description should explain the return value or expected outcome. It only says 'Create a new pull request', leaving out important context like whether it returns the created pull request object.
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 schema already documents all parameters. The description adds no additional meaning or examples beyond the schema, meeting the baseline but not exceeding 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 'Create a new pull request' clearly states the action and resource. It is specific and distinguishes from siblings like 'update_pull_request' and 'list_pull_requests'.
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 on when to use this tool versus alternatives, nor any prerequisites or context like branch protection rules or required permissions.
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 a read operation ('List'), implying it's non-destructive, but doesn't mention any behavioral traits like pagination, rate limits, authentication needs, or what happens if no wikis exist. This leaves significant gaps for a tool that likely interacts with a project system.
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, clear sentence with zero wasted words. It's front-loaded with the core action and resource, making it highly efficient and easy to parse. Every word earns its place by conveying essential information without redundancy.
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 complexity of interacting with a project's wikis, the description is incomplete. It lacks details on output format, error handling, or behavioral context, and with no annotations or output schema, the agent has minimal guidance. For a tool in a server with multiple wiki-related siblings, more context is needed to ensure correct usage.
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 tool has 0 parameters, and the schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it appropriately doesn't mention any. A baseline of 4 is applied since no parameters exist, and the description doesn't introduce confusion.
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 ('List') and resource ('wikis in the project'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_wiki_page' or 'list_work_items', which might also retrieve wiki-related information, so it doesn't reach the highest score.
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 like 'get_wiki_page' or 'list_work_items'. It lacks context about prerequisites, such as needing an active project, or exclusions, leaving the agent to infer usage from the tool name alone.
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 full burden for behavioral disclosure. While 'Update' implies a mutation operation, it doesn't specify whether this requires special permissions, what happens on partial failures, whether operations are atomic, or what the typical response format looks like. The mention of 'JSON patch operations' adds some technical context but doesn't explain behavioral implications like whether all operations in the array are applied transactionally.
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, efficient sentence that communicates the essential information without any wasted words. It's front-loaded with the core action and immediately specifies the technical approach (JSON patch). Every element of the description serves a clear purpose in conveying the tool's function.
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 mutation tool with no annotations and no output schema, the description is minimally adequate. It covers the basic purpose and technical approach but lacks important context about permissions, error handling, response format, and when to use this versus alternatives. The 100% schema coverage helps, but behavioral aspects remain underspecified for a tool that modifies data.
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 has 100% description coverage, providing detailed documentation for both parameters. The description adds the context that updates use 'JSON patch operations' which helps interpret the 'document' parameter's structure, but doesn't provide additional semantic meaning beyond what's already in the schema descriptions. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Update') and resource ('an existing work item'), making the purpose immediately understandable. It distinguishes from sibling tools like 'create_work_item' by specifying it updates existing items rather than creating new ones. However, it doesn't explicitly differentiate from 'update_wiki_page' which follows a similar pattern but 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'create_work_item' for modifications, or whether it should be used instead of other update operations. There's no context about prerequisites, dependencies, or typical use cases for JSON patch operations versus simpler updates.
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 states the action ('List all projects') but lacks details on permissions, rate limits, pagination, or response format. For a read operation with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste. It's front-loaded and efficiently conveys the core purpose without redundancy or fluff, making it highly 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?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate as a basic read operation. However, it lacks context on behavioral aspects like permissions or output format, which could be helpful for an agent, keeping it at a minimum viable level.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate, earning a baseline score of 4 for not introducing unnecessary information.
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 verb ('List') and resource ('projects in the Azure DevOps organization'), making the purpose unambiguous. However, it doesn't distinguish this tool from siblings like 'list_pipelines' or 'list_work_items' beyond the resource name, which is why it doesn't reach a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 prerequisites, context, or exclusions, such as whether this lists all projects unconditionally or if there are filtering options elsewhere. This leaves the agent without usage direction.
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:

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

Score Badge

Copy to your README.md:

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

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/stefanskiasan/azure-devops-mcp-server'

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