adtk

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.3.2
Disambiguation5/5
Each tool focuses on a distinct Azure DevOps domain (e.g., work items, repos, pipelines) with no overlapping responsibilities. Actions within each tool are specific to that resource, ensuring clear separation.
Naming Consistency5/5
All tools follow a consistent 'manage_<domain>' naming pattern, and actions inside use standard verbs like list, get, create, update, delete. No mixing of conventions.
Tool Count5/5
14 tools cover a broad range of Azure DevOps functionality without being excessive. Each tool is justified by a distinct set of operations, making the surface well-scoped.
Completeness4/5
Major Azure DevOps features are covered, but some resources lack full CRUD (e.g., test plans missing update/delete, boards only read). Core workflows are supported, with minor gaps.
Average 3/5 across 14 of 14 tools scored. Lowest: 2.4/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
- Last stable release on March 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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.
This repository includes a glama.json configuration file.
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, yet the description fails to disclose behavioral traits such as side effects, authentication requirements, rate limits, or parameter behavior (e.g., what happens if project_key is missing). The description is too brief to inform the agent about the tool's operation beyond its basic function.
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 two sentences but the second sentence largely restates the first. It is short but not optimally concise, and the structure is adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more context about return values, error handling, and parameter dependencies. It lacks completeness for a tool with three parameters and no additional documentation.
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% (all parameters have descriptions). The description repeats the action value but adds no new semantic information beyond the schema. Baseline score of 3 is appropriate since the schema already documents parameters well.
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?
Description states 'Get issue lifecycle metrics for dashboards and visualizations' with a clear verb and resource, and names the specific action 'get_metrics'. It does not explicitly differentiate from sibling tools, but the resource 'metrics' is distinct from other resources like work items or projects.
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 (e.g., manage_work_items, manage_boards). The description only states the action without context for selection.
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 exist, so the description must fully convey behavioral traits. It lists actions implying mutation (create, update, delete) and reads, but does not mention side effects, permission requirements, rate limits, or idempotency. The agent cannot infer safety or impact without external knowledge.
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 one long sentence listing 18 actions, lacking structure and readability. It is not front-loaded; key purpose ('Manage Azure DevOps work items') is present, but the action list dominates. Every word is not earned—the list could be summarized or grouped.
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 high parameter count (27) and no output schema, the description should provide more context on action selection, required parameters per action, and expected results. It only lists actions and relies on the schema for parameter details. The tool is complex, and the description does not offer sufficient guidance for 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%, so the baseline is 3. The description does not add meaning beyond the schema—it only enumerates actions. However, the schema itself provides detailed parameter descriptions, compensating somewhat. The description adds no extra semantics for parameter usage or interrelationships.
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 tool manages Azure DevOps work items and lists specific actions (get, create, update, etc.), making the purpose evident. It distinguishes from sibling tools like manage_boards or manage_pipelines by explicitly mentioning work item types (tasks, bugs, user stories, epics). However, the action list is exhaustive and could be more focused.
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 (e.g., manage_attachments for attachments, manage_boards for board operations). The description does not specify prerequisites, conditions for read vs. write operations, or context where sibling tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must reveal behavioral traits, but it only lists action names. It doesn't specify which actions are read-only vs. mutating, whether operations are idempotent, permission requirements, side effects, or error conditions. This is a significant gap for an 18-parameter 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?
Very short and front-loaded, but the list of actions takes up most of the space. It is concise but sacrifices important behavioral information. Every sentence earns its place, but the description could be restructured to include context without increasing length significantly.
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 high complexity (18 parameters, 12 actions) and no output schema, the description is incomplete. It lacks action-specific guidance, parameter groupings, and behavioral context. An agent would need to read the entire schema and infer usage, which is suboptimal.
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 baseline is 3. The description adds no extra meaning beyond the action list, which is already in the schema's action parameter description. The schema already explains each parameter well.
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 tool manages Azure DevOps pull requests and lists all actions. This differentiates it from sibling tools (e.g., manage_repos, manage_work_items) by resource. However, it doesn't explain what each action does beyond the action name, so some ambiguity remains.
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 vs. alternatives, or when not to use it. The description only enumerates actions without hints about choosing the right action or typical usage patterns. This leaves the agent without decision support.
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 bears full responsibility for disclosing behavioral traits. It only lists action names, which imply operations but do not explain side effects, permissions required, or consequences (e.g., triggering a pipeline may start a build). Minimal behavioral context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence to list actions after stating the resource. It is front-loaded and efficient, though it could be improved by grouping related actions or adding more structure.
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 (9 parameters, multiple actions, no output schema), the description is incomplete. It lacks information about return values, error conditions, or what each action accomplishes beyond the action name. The schema provides parameter details, but the description does not provide the high-level context needed for effective tool selection.
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 parameters with descriptions (100% coverage), so the baseline is 3. The tool description adds no extra parameter context beyond the schema, merely listing actions. It does not enhance understanding of parameter values or constraints.
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 tool manages Azure DevOps CI/CD pipelines and lists specific actions, distinguishing it from sibling tools that manage other resources. However, the verb 'Manage' is generic and the description is a list without a clear statement of the tool's overall purpose.
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 guidelines are provided about when to use this tool versus alternatives or when to use specific actions. The description simply enumerates actions without context about prerequisites, typical use cases, or when not to use the tool.
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 description must convey behavior. It fails to disclose that actions like create/update/delete are mutating, nor does it mention concurrency control via 'version' parameter, permissions, or reversibility. The term 'Manage' is vague for a tool with destructive operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus a list of actions is very concise. It is front-loaded with the main purpose. However, the list could be better formatted for readability.
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 bundles 6 actions with 6 parameters and no output schema, the description is incomplete. It does not explain return values for each action, relationships between actions, or error scenarios. A more detailed description would be expected for a multi-operation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions, so baseline is 3. The description emphasizes 'markdown-native,' which adds value but is already implied by the content parameter description. It does not clarify the difference between 'list' and 'list_pages' or provide additional semantic context beyond 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 it manages Azure DevOps wiki pages and lists all available actions. However, it does not differentiate between 'list' and 'list_pages', which could be ambiguous (list wikis vs list pages). Still, it is specific enough to understand the resource and operations.
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 vs alternatives (e.g., manage_work_items for other content). No prerequisites or conditions are mentioned. The description merely lists actions 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 burden. It does not disclose behavioral traits such as side effects (upload modifies the work item), permissions needed, or rate limits. Minimal information beyond actions.
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 short (one sentence plus list). It is concise but lacks structure; no explanation of actions or parameter relationships. Not verbose, but could be more organized.
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 6 parameters, multiple actions, and no output schema, the description is incomplete. It does not explain how to use each action, what the API returns, or how to construct a download URL. Agent would lack necessary 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 input schema already describes all parameters. The description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Azure DevOps work item attachments and lists the three actions: list, upload, download. This is specific and distinguishes it from sibling tools like manage_work_items or manage_repos.
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, or when not to use it. The description only lists actions without 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?
No annotations are provided, so the description must disclose behaviors. The actions are all read-only, but the term 'manage' may misleadingly imply mutation. No information about authentication, side effects, or restrictions is given.
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 concise with a single sentence, but the word 'Manage' is vague and could be replaced with a more specific verb for clarity.
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 omits crucial context such as output format, required parameters for specific actions (e.g., board_id for get/get_columns), and permission requirements, making it incomplete for a tool with 4 parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, so the description adds little beyond listing actions. It does not explain parameter relationships or usage patterns, hence 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 states the tool manages Azure DevOps Kanban boards and lists three specific actions ('list', 'get', 'get_columns'), providing a specific verb-resource pair and differentiating from sibling tools that manage other 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 over alternatives, nor does it explain which action to choose for a given scenario. It only lists actions 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?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Manage', which is vague. It does not mention side effects (e.g., creation may require permissions), idempotency, rate limits, or error conditions. The actions are listed but their behaviors (e.g., 'get' vs 'create') are not elaborated beyond the action names.
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 concise (two sentences) and front-loaded with the verb 'Manage'. It efficiently lists the actions, though it could be structured into bullet points for clarity. Every sentence earns its place, but the format is minimal.
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 output schema, the description should explain return values or behavior. It does not describe what each action returns or any side effects. The tool has five parameters and multiple actions, but the description lacks completeness for an agent to use it effectively without additional 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 description coverage is 100%, so baseline is 3. The description adds a list of actions in the main text, but the input schema already describes each parameter (e.g., action, project_key, team_id, name, description). The description does not add meaningful new information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool manages Azure DevOps projects and teams, and lists all five actions ('list', 'get', 'list_teams', 'get_team', 'create'). This clearly distinguishes it from sibling tools like manage_repos, manage_work_items, etc., which handle 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 its many siblings (e.g., manage_repos, manage_pipelines). It lists actions but does not explain which action is appropriate for different scenarios or what prerequisites exist.
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 says 'Manage' and lists actions, without disclosing whether each action is read-only or modifies state, or any potential side effects. No annotations provide additional context, so the agent has no behavioral guarantees.
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 concise sentence that front-loads the purpose and lists actions. However, it compresses all information into one sentence without clear separation of action descriptions, which could be improved for readability.
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 12 parameters and no output schema, the description lacks crucial context such as return values, prerequisites, or detailed behavior for each action. The agent would need to infer most usage from 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 has 100% coverage with descriptions for all parameters. The description adds only a list of action names, which are already in the schema's action parameter description. Therefore, the description provides minimal added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it manages Azure DevOps Git repositories and enumerates ten specific actions, distinguishing it clearly from sibling tools like manage_pipelines or manage_work_items 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 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 on how to choose among the listed actions. The agent must infer usage solely from the action names and parameter requirements.
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 burden. It does not disclose side effects, permissions, rate limits, or return behavior. The tool likely performs read-only operations, but this is not explicitly stated.
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 brief (one sentence plus a list), which is efficient. However, the list repeats schema information, and the structure could prioritize key information like supported search types.
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 output schema or annotations, and 6 parameters including multiple action types, the description lacks detail on result format, error handling, or usage nuances. A more complete description would aid agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no new meaning beyond the schema; it merely lists action values already described. It does not clarify parameter interactions or formatting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches Azure DevOps using WIQL, code, work items, and wiki. It lists specific actions, making the purpose unambiguous. Sibling tools focus on managing specific resources (e.g., manage_work_items), so this tool's search role is distinct.
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, such as when to choose 'code' over 'work_items'. No exclusions or cautionary notes are provided, leaving the agent without decision criteria.
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 must carry the full burden of behavioral disclosure. It only states 'Manage' and lists actions, but does not clarify whether operations are read-only or destructive, what permissions are required, or any side effects. This is insufficient for safe agent usage.
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 two sentences. It front-loads the purpose and lists actions efficiently. Every word serves a purpose with no unnecessary content.
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 6 parameters, no output schema, and no annotations. The description does not explain return values, pagination, or behavior of each action beyond the schema. It fails to provide sufficient context for an agent to use the tool correctly in diverse scenarios.
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 for parameters. The description adds no additional meaning beyond what is already in the schema; it only restates the action parameter. Baseline 3 is appropriate since the schema already documents parameters well.
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 identifies the resource (Azure DevOps Advanced Security alerts) and lists the two available actions: 'list_alerts' and 'get_alert'. It distinguishes from sibling tools, which cover different domains (attachments, boards, etc.), by focusing on security alerts.
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 implicitly suggests using this tool for managing Advanced Security alerts, but provides no explicit guidance on when to use it versus alternatives or when not to use it. Given sibling tools are distinct, it's clear enough but lacks contextual advice.
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 present, so the description must disclose behavioral traits. It only states the actions, with no mention of side effects (e.g., create mutates data), permissions, rate limits, or other constraints. This is insufficient for an agent to fully understand the tool's behavior.
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, consisting of a single sentence that front-loads the tool's purpose and actions. Every word is necessary, and the action list is 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 has 7 parameters and 5 actions with no output schema, the description provides only the bare minimum. It lacks details on return values, error handling, or prerequisites, making it merely adequate for straightforward use cases.
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?
Input schema coverage is 100%, so all parameters have descriptions. The description adds no additional meaning beyond the schema, meeting the baseline of 3. It does not provide extra context like format or usage examples.
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 identifies the tool as managing Azure DevOps iterations (sprints) and lists the specific actions. Although the verb 'manage' is generic, the action list and resource name differentiate it from sibling tools like manage_work_items or manage_projects.
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 lists actions but provides no guidance on when to use each action or when to use this tool versus alternatives. The actions are self-explanatory, but there is no explicit 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?
The description does not disclose behavioral traits such as read-only nature, authentication requirements, or response details. With no annotations, the description fails to inform the agent about side effects or constraints beyond the listed actions.
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 very concise with two sentences, front-loading the purpose and key actions. Every word adds value, and there is no unnecessary text.
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 simplicity of the tool (2 parameters, no output schema), the description provides the core information but lacks details on return values or behavior of each action, leaving some ambiguity for an AI 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?
Schema description coverage is 100%, so baseline is 3. The description repeats the action names already in the schema without adding new semantic meaning or usage tips for the 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 'Search and get Azure DevOps users' with specific actions listed. It distinguishes from sibling tools by specifying the resource (users) as opposed to other entities like attachments or pipelines.
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 'get_current' vs 'search', nor any context about alternatives or prerequisites. The description only lists available actions without explaining their appropriate 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 bears full responsibility for behavioral disclosure. However, it only lists actions without explaining side effects, permissions, rate limits, or idempotency. For a multi-action tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the tool's purpose and then enumerates actions. Every word contributes meaning with no 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?
While the schema covers parameters well, the tool has no output schema and multiple interdependent actions. The description does not explain how actions relate, prerequisites, or return values, leaving gaps for an agent trying to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with descriptions for all 8 parameters. The tool description adds no further parameter information beyond listing actions. Per guidelines, baseline is 3 when schema coverage is high, so this score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool manages Azure DevOps test plans, suites, and cases, listing specific actions. This distinguishes it from sibling tools that manage other domains like boards, repos, or work items.
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 use this tool versus alternatives. While the domain (test plans, suites, cases) implies its scope, there is no guidance on when not to use it or how it relates to siblings like manage_work_items, which might also handle test cases.
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:

[![adtk MCP server](https://glama.ai/mcp/servers/zach-snell/adtk/badges/card.svg)](https://glama.ai/mcp/servers/zach-snell/adtk)

Score Badge

Copy to your README.md:

[![adtk MCP server](https://glama.ai/mcp/servers/zach-snell/adtk/badges/score.svg)](https://glama.ai/mcp/servers/zach-snell/adtk)

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/zach-snell/adtk'

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