Skip to main content
Glama

get_test_case

Read-onlyIdempotent

Retrieve a full manual test case with all fields: steps, metadata, and optional edit history. Use for detailed review or sharing in Slack or Jira.

Instructions

Get one manual test case in full: id, caseNumber, displayId, title, description, status, priority, tags, ordered steps, folderId/folderName, projectId/projectName, dependsOn, customFields, createdAt/updatedAt and a shareUrl for pasting into Slack or Jira. Optional flags add linkedAutotests (includeLinkedAutotests, default true), recentAutotestExecutions from CI runs (includeRecentExecutions) and an edit-history audit trail (includeHistory). Read-only; nothing is modified. caseId is the internal numeric id from list_test_cases / create_test_case, not a user-facing TC-N; the project is derived from the case. Choose list_test_cases instead to browse, filter or count many cases, or to turn a TC-N into an id - it returns summaries without steps, so use it to pick the case and this tool to read it. Choose get_case_execution_history instead for how the case has fared in Manual Test Executions over time (pass rate plus an execution timeline); includeRecentExecutions here reports automated CI results only. search_tests covers automated tests, which are separate records from manual cases. IMPORTANT if you plan to write back: description and steps are RICH TEXT and do not round-trip as they arrive. Both come back as arrays of formatting nodes rather than strings, and a step reads as title and expected while create_test_case and update_test_case take action and expected. So sending a step straight back sets the wrong field to the wrong type. Send plain strings or Markdown on write and the server converts them; to edit one step, rebuild the whole steps array from your own text, since steps is replace-all.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
caseIdYesInternal numeric test case id (the "id" from list_test_cases / get_test_case / create_test_case). This is NOT the user-facing "TC-N" number (caseNumber/displayId) - if the user gave you a "TC-N", resolve it first via list_test_cases(search: "TC-N") and use the returned id. Project is derived from the case.
includeHistoryNoInclude the edit audit trail: field, oldValue, newValue, changeType, userName, userEmail and changedAt per entry. It is NOT a complete account of the case, for two separate reasons. COVERAGE: the trail holds only the changes it audits, and updatedAt can be newer than every entry in it - one case here carries updatedAt two months after its latest recorded change - while the case itself has no updatedBy field. VOLUME: the array is capped at the 50 most recent entries, with no truncation flag, no total and no way to page further back, so a trail of exactly 50 IS a truncated one and its oldest entry is not the oldest change. Two traps inside the rows as well: an entry records that a field was SUBMITTED rather than that its value moved, so oldValue and newValue are often identical - 28 of 50 on one case here - and userName is frequently just the email address again. So this answers what changed and by whom AMONG AUDITED, RECENT changes, and cannot always answer who last touched the case.
includeLinkedAutotestsNoInclude autotest links made with link_autotest_to_case. These are the only links reported here, and they are not the only links that exist: a reporter can also bind a test to a case by putting a [TC-N] marker in the test title, which ingest resolves to a case id on the test row itself. get_coverage_gaps counts that second kind as covered in its unlinkedAutotests section ONLY: its summary, automationRate, foldersWithLowCoverage and unlinkedCases all use the same narrow, explicit-link definition this list does. So a test can be absent here and still be linked, and a case can sit in unlinkedCases while a marker-bound test covers it, which makes automationRate a floor rather than the whole picture.
includeRecentExecutionsNoInclude autotest results for this case from CI. There is NO time window: the latest result per distinct test title is returned, up to 20, with no date cutoff at all - so an empty array is DEFINITIVE and means no automated test has ever reported against this case, rather than none lately. This is also the only place a test bound to the case by a [TC-N] title marker appears, which makes it the arbiter when linkedAutotests comes back empty.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv1.5.3
    • changedInput schema / properties / includeHistory / description
      Previous value: -"Include edit history (audit log of changes)"New value: +"Include the edit audit trail: field, oldValue, newValue, changeType, userName, userEmail and changedAt per entry. It is NOT a complete account of the case, for two separate reasons. COVERAGE: the trail holds only the changes it audits, and updatedAt can be newer than every entry in it - one case here carries updatedAt two months after its latest recorded change - while the case itself has no updatedBy field. VOLUME: the array is capped at the 50 most recent entries, with no truncation flag, no total and no way to page further back, so a trail of exactly 50 IS a truncated one and its oldest entry is not the oldest change. Two traps inside the rows as well: an entry records that a field was SUBMITTED rather than that its value moved, so oldValue and newValue are often identical - 28 of 50 on one case here - and userName is frequently just the email address again. So this answers what changed and by whom AMONG AUDITED, RECENT changes, and cannot always answer who last touched the case."
    • changedInput schema / properties / includeLinkedAutotests / description
      Previous value: -"Include explicitly linked autotest paths"New value: +"Include autotest links made with link_autotest_to_case. These are the only links reported here, and they are not the only links that exist: a reporter can also bind a test to a case by putting a [TC-N] marker in the test title, which ingest resolves to a case id on the test row itself. get_coverage_gaps counts that second kind as covered in its unlinkedAutotests section ONLY: its summary, automationRate, foldersWithLowCoverage and unlinkedCases all use the same narrow, explicit-link definition this list does. So a test can be absent here and still be linked, and a case can sit in unlinkedCases while a marker-bound test covers it, which makes automationRate a floor rather than the whole picture."
    • changedInput schema / properties / includeRecentExecutions / description
      Previous value: -"Include recent autotest execution results from CI runs"New value: +"Include autotest results for this case from CI. There is NO time window: the latest result per distinct test title is returned, up to 20, with no date cutoff at all - so an empty array is DEFINITIVE and means no automated test has ever reported against this case, rather than none lately. This is also the only place a test bound to the case by a [TC-N] title marker appears, which makes it the arbiter when linkedAutotests comes back empty."
  2. First observedv1.5.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark readOnlyHint/idempotentHint/destructiveHint, and the description is fully consistent — yet it adds a lot of disclosure beyond the annotations: the exact return field set, that 'nothing is changed', the history caveats (50-entry cap with no truncation flag, oldValue and newValue are often identical), the no-time-window execution semantics ('empty array is DEFINITIVE'), and the rich-text round-trip trap where sending a read step back corrupts the write. No contraction found.

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?

Extremely information-dense; every sentence carries real operational value — the sibling routing, the definitive empty-array semantics, the marker-bound-line caveat, the replace-all steps warning. The most critical usage note ('caseId is the internal numeric id… not a TC-N') is appropriately prominent at the end of the first part. It loses one point for being a single long monolithic paragraph — splitting the sibling routing, the link nuances, and the write-back warning would make it easier to parse.

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?

This is a high-complexity tool — 4 params, 3 optional flags with surprising semantics (no time win dow, 50-entry cap, explicit-versus-marker links), one required non-obvious id, read-only with a write-back footgun, and no output schema. The description covers all of these: the shared return list, the suffix-share-difference between includeHistory and includeRecentExecutions, the exotic-autotest binding discrepancy, the rich text versus markdown asymmetry, and the page ambiguity of the id. Nothing of consequence is left to inference.

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 of 3 applies; the schema already picks up each parameter in detail (caseId as internal id vs TC-N, defaults, semantics of includeHistory/includeRecentExecutions/includeLinkedAutotests). The main description only repeats this framing ('Optional flags add…') and points the id semantics, without adding anything beyond what the schema provides. It does not compensate further nor does it need to.

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?

Opens with a specific verb+resource ('Get one manual test case in full') and an explicit field list (id, caseNumber, title, steps, folderId/folderName, shareUrl, etc.) that precisely bounds the operation. It also differentiates itself from the most confusable siblings — list_test_cases, get_case_execution_history and search_tests — within the same description, so there is no ambiguity about which tool is which.

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?

Gives explicit decision rules with alternatives: 'Choose list_test_cases instead to browse, filter or count many cases, or to turn a TC-N into an id', 'Choose get_case_execution_history instead for how the case has fared in Manual Test Executions over time', and flags that search_tests covers a separate record type. The 'IMPORTANT if you plan to write back' warning further conditions the behavior expected of the agent.

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

Latest Blog Posts

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/m00nreport/mcp-server'

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