get_test_case_links

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

With no annotations, the description carries the burden, and it does disclose the enriched result fields and accepted caseId forms. However, it does not mention read-only behavior, empty-link behavior, or any error/edge cases, leaving some uncertainty for an agent without annotation support.

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

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

Two sentences, no filler. Core purpose is front-loaded, and the sibling contrast is placed in the second sentence only where it is actionable.

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

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

The tool has no output schema and no annotations, but the description names the returned metrics fields and the linkId needed for unlink_automated_test. It covers ID formats and when to use this tool; only deeper response-shape details are omitted, which is a minor gap for a list-oriented read tool.

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

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 restates what caseId accepts but adds no new parameter meaning beyond the schema; days and projectId behavior are already documented in the schema.

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

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

The description clearly states a specific action ('List the automated tests linked to one manual test case') and adds the distinguishing enrichment: automation metrics. It also explicitly contrasts with get_manual_test_case, naming what that sibling returns and when this tool should be selected.

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

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

The description provides explicit selection guidance: get_manual_test_case returns the raw linkedTests array, while this tool should be used when metrics or a linkId for unlink_automated_test are needed. This gives the agent a clear decision rule among siblings.

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