arcade-azure-devops-mcp

AzureDevops_QueueBuild

AzureDevops_QueueBuild

Queue a new Azure DevOps build for a specified project and build definition, with an optional source branch.

Instructions

Queue a new build.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project": "<project>",
      "definition_id": "<definition_id>"
    },
    "name": "AzureDevops_QueueBuild"
  }
}

Input Schema

Name	Required	Description
`project`	Yes	Project name or ID
`definition_id`	Yes	Build definition ID to queue
`source_branch`	No	Branch to build (e.g., 'refs/heads/main')

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 9, 2026

TDQS

C2.6/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Queue a new build' reveals nothing about synchronous/asynchronous behavior, return values, auth requirements, or side effects. This is a significant omission for a mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is minimal and free of fluff, but it is under-specified rather than appropriately concise. A single short sentence may be suitable for a trivial tool, yet here it omits useful context, so it doesn't fully earn its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with three parameters, no output schema, and no annotations, the description is incomplete. It fails to explain what happens after queueing, whether it returns a build ID or URL, or how it relates to similar tools like RunPipeline, leaving the agent under-informed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameter meanings are already well-documented in the input schema (e.g., project, definition_id, source_branch). The description adds no additional semantic value beyond what the schema provides, warranting the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Queue a new build' clearly states the verb ('Queue') and resource ('a new build'), making the primary action unambiguous. However, it fails to distinguish this tool from sibling AzureDevops_RunPipeline, which could also queue builds, so it doesn't fully differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives like AzureDevops_RunPipeline or AzureDevops_ListBuildDefinitions. The description gives no context, prerequisites, or exclusions, leaving the agent to guess the appropriate use case.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.