Skip to main content
Glama

ado_create_test_plan

WHEN: the user wants the manual test cases of a feature (a User Story, Feature or Requirement work item) created in Azure DevOps Test Plans: a test plan, a suite tied to that work item, and one Test Case per scenario with its steps. Triggers: 'create the test plan for WI N', 'créer le plan de test', 'put these tests in Azure Test Plans', 'cas de test dans DevOps'. YOU write the test cases: read the work item (ado_analyze_workitem) and, when useful, the code, then pass them as testCasesJson, a JSON array [{"title":"...","priority":1-4,"tags":["..."],"steps":[{"action":"...","expected":"..."}]}]. Each case needs a title and at least one step; every step needs an action, and an expected result for the steps that verify something. Without testCasesJson the tool falls back to one generic case per acceptance-criteria line, which is much weaker. SAFE BY DEFAULT: with confirm=false (default) nothing is written; it returns exactly what would be created and what already exists. Show that preview to the user, and only call again with confirm=true after they approved it. Test cases whose title already exists on the work item are skipped, so running it twice does not duplicate. Needs a PAT with Work Items (Read & write) and Test Management (Read & write); creating plans and suites also needs the Basic + Test Plans access level.

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": {
      "workItemId": "<workItemId>"
    },
    "name": "ado_create_test_plan"
  }
}

Input Schema

NameRequiredDescriptionDefault
planIdNoUse this existing test plan instead of looking one up by name.
confirmNofalse (default): preview only, nothing is written. true: create. Only after the user approved the preview.
projectNoAzure DevOps project. Falls back to DEVOPS_PROJECT.
planNameNoName of the test plan. Default: 'Tests - WI {id} {title}'. An existing plan with this name is reused.
workItemIdYesWork item the tests verify (User Story, Feature, Requirement...), e.g. 6587.
testCasesJsonNoJSON array of test cases written from the acceptance criteria. Strongly recommended. See the tool description for the shape.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses a two-phase preview/confirm protocol ('with confirm=false nothing is written; it returns exactly what would be created and what already exists'), dedupe behavior by test-case title, and the exact PAT scopes plus Basic + Test Plans access level required. The title-based skip is scoped to test cases only, so it does not really contradict idempotentHint=false for the plan/suite creation.

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?

Front-loaded with a WHEN: label and an uppercase 'SAFE BY DEFAULT:' marker that makes the preview gate impossible to miss. It is long, and the four quoted trigger phrases (two of them French) add bulk, but every remaining sentence carries operational information.

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

Completeness5/5

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

With no output schema, the description still tells the agent what the preview returns ('exactly what would be created and what already exists'), and it covers the mutation, auth, idempotency and sequencing concerns an agent needs before writing to a live DevOps project.

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

Parameters4/5

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

Schema coverage is already 100%, yet the description adds the full testCasesJson contract — a JSON array of objects with title, priority 1-4, tags, and steps of action/expected — plus the validity rule (each case needs a title and at least one step) that the schema only points to. It does not re-explain planId, project or planName, but those are already self-documenting.

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

Purpose5/5

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

States a precise verb and resource chain — 'created in Azure DevOps Test Plans: a test plan, a suite tied to that work item, and one Test Case per scenario with its steps' — which no sibling tool does. An agent can separate it from ado_analyze_workitem (which it names as a prerequisite) and from ado_create_task without opening a schema.

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

Usage Guidelines5/5

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

Opens with an explicit WHEN clause and quotes the user phrasings that trigger it, including French variants. It also routes upstream ('read the work item (ado_analyze_workitem) and, when useful, the code') and names the degraded fallback taken when testCasesJson is absent, so the agent knows both the ideal and the default path.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.