Skip to main content
Glama
Sign In
TestDino MCP

TestDino MCP

by testdino-hq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Test Case Links

get_test_case_links
Read-only

List automated tests linked to a manual test case with automation metrics like success rate and last execution. Also returns link IDs for unlinking tests.

Instructions

List the automated tests linked to one manual test case, each enriched with recent automation metrics (successRate, lastExecution, platforms). caseId accepts the internal _id or the "TC-123" key. get_manual_test_case also returns the raw linkedTests array; use this tool when you need the metrics or a linkId to pass to unlink_automated_test.

Input Schema

NameRequiredDescriptionDefault
daysNoMetrics window in days (server default applies when omitted)
caseIdYesInternal _id or "TC-123" style ID
projectIdYesProject ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv2.2.0
    • addedInput schema / $schema
      Added value: +"http://json-schema.org/draft-07/schema#"
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / caseId / description
      Previous value: -"Test case ID (Required). Can be internal _id or human-readable ID like 'TC-123'."New value: +"Internal _id or \"TC-123\" style ID"
    • changedInput schema / properties / days / description
      Previous value: -"Metrics window in days (server default applies when omitted)."New value: +"Metrics window in days (server default applies when omitted)"
    • addedInput schema / properties / days / maximum
      Added value: +365
    • addedInput schema / properties / days / minimum
      Added value: +1
    • changedInput schema / properties / days / type
      Previous value: -"number"New value: +"integer"
    • changedInput schema / properties / projectId / description
      Previous value: -"Project ID (Required). The TestDino project identifier."New value: +"Project ID"
  2. Addedv2.0.3

TDQS

A4.4/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=true, so the safety profile is already covered; the description goes further by disclosing what the return entries actually contain (successRate, lastExecution, platforms) and that a linkId is available for downstream unlinking. It does not mention pagination, caps on linked tests, or metric staleness, which keeps it short of a 5.

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?

Two sentences: the purpose with its enrichment is front-loaded, and the second sentence carries only routing and identifier-format information. No filler, no restatement of the tool name.

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

Completeness4/5

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

There is no output schema, so the description must carry return-value context; it names the key metric fields and the linkId, which is enough to act on. It stops short of describing the full entry shape (e.g. test name/identifier per link), so it is nearly but not fully complete.

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's caseId note ('internal _id or the "TC-123" key') restates what the schema already documents, and the days window parameter is not addressed at all in the description, so no meaning is added beyond structured data.

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 and resource ('List the automated tests linked to one manual test case') plus the distinguishing enrichment ('recent automation metrics (successRate, lastExecution, platforms)'). It is immediately separable from list_automated_tests and get_manual_test_case 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?

Explicitly names the overlapping sibling ('get_manual_test_case also returns the raw linkedTests array') and the exact condition that selects this tool over it: needing metrics or a linkId for unlink_automated_test. That is a full when/when-not/alternative statement.

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

Deploy Server

Other Tools