Skip to main content
Glama

MCP Server By TestMu AI

Generate Test Cases with AI

tm_generate_test_cases

Generate structured test cases from a requirement or prompt using the Test Manager AI generator (applies the project's Memory Layer — Project & Org Instructions — automatically) and file them into the chosen folder. Requirement documents, specs, spreadsheets or screenshots can be attached via files to ground the generation. Volume = test_scenario_limit × per_scenario_test_cases_limit, capped at 50 per call. By default all generated cases are saved into the folder (one sub-folder per scenario); pass auto_save=false to review before saving. The call returns FAST with a request_id (and a browser progress URL) — generation takes ~30-90s in the background; call this tool again with just request_id to check progress, fetch results, or save. Note: consumes AI generation credits.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNoOptional reference files to ground the generation (requirement docs, specs, data sheets, screenshots). Each item carries the file name and its raw bytes base64-encoded in content_base64. Supported: .pdf, .docx, .txt, .csv, .xlsx, .json, .xml, .jpg, .jpeg, .png, .gif, .bmp, .webp; max 5 files, 10 MB each. Large files are better uploaded in the Test Manager UI, since the base64 content travels in the request. Only used when starting a new generation.
promptNoThe requirement / instructions to generate test cases from. Required when starting a new generation.
jira_idsNoOptional Jira issue keys to use as requirement context
auto_saveNoSave all generated cases into the folder automatically (default true for a NEW generation). Set false to review first — that choice persists across request_id polls (a bare poll never saves it); to save after review, call again with request_id AND auto_save=true.
folder_idNoFolder to file generated cases into. Required when starting a new generation.
project_idNoProject ID (ULID). Required when starting a new generation.
request_idNoResume/act on an earlier generation: check progress, fetch results, or save them.
test_scenario_limitNoMax scenarios to generate (default 3)
per_scenario_test_cases_limitNoMax test cases per scenario (default 3)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / files / description
      Previous value: -"Optional reference files to ground the generation (requirement docs, specs, data sheets, screenshots). Supported: .pdf, .docx, .txt, .csv, .xlsx, .json, .xml, .jpg, .jpeg, .png, .gif, .bmp, .webp — max 5 files, 10 MB each. Read the file yourself and base64-encode its raw bytes (shell: base64 -i <file>). Prefer small files (up to a few hundred KB) — base64 content passes through your context, so upload larger files via the Test Manager UI instead. Only used when starting a new generation."New value: +"Optional reference files to ground the generation (requirement docs, specs, data sheets, screenshots). Each item carries the file name and its raw bytes base64-encoded in content_base64. Supported: .pdf, .docx, .txt, .csv, .xlsx, .json, .xml, .jpg, .jpeg, .png, .gif, .bmp, .webp; max 5 files, 10 MB each. Large files are better uploaded in the Test Manager UI, since the base64 content travels in the request. Only used when starting a new generation."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description adds the async contract (returns FAST with request_id + progress URL, ~30-90s background), the credit consumption, automatic Memory Layer application, and the 50-case cap. These are behavioral traits the agent cannot get from structured fields.

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 purpose and key constraints (files, volume cap, auto_save default, async flow, credits) are front-loaded and nearly every sentence carries actionable detail. It is dense but not padded, though the parenthetical Memory Layer note slightly interrupts flow.

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?

For an async, no-output-schema, 9-parameter generation tool, the description covers the return value (request_id + progress URL), the two-phase workflow, saving behavior, and cost — everything an agent needs to invoke and follow up correctly.

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 100%, so parameters are already documented, but the description adds real semantics: the volume formula (test_scenario_limit × per_scenario_test_cases_limit, cap 50), and the request_id resume/poll behavior including that the auto_save=false choice persists across polls.

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 specific verb+resource ('Generate structured test cases from a requirement') and names the generator and destination folder. It is clearly distinguishable from the manual sibling tm_create_test_case by emphasizing AI generation from a prompt, not hand-authored creation.

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?

Explicitly covers when to use which mode: attach files to ground generation, pass auto_save=false to review before saving, and re-call with just request_id to check progress/fetch/save. It also warns that generation consumes AI credits, which is a genuine when-to-use consideration.

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.

Resources