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

With no annotations, the description carries the full burden. It discloses key behaviors: optional fields use defaults, custom fields must match the template or a 422 is returned, and batch size is 1-100. It could also mention the response format or idempotency, but it already adds substantial value beyond the tool name.

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 wasted words. It front-loads the action and immediately follows with the most important usage constraints.

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 description covers the core creation action, batch limits, optionality, and the custom-field gotcha. It does not explain return values or permission requirements, but there is no output schema and the input schema handles field-level details well.

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 coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining that folder_id/template_id/state_id are optional with defaults and that template-specific custom fields must match the template or cause a 422. This helps the agent avoid common errors.

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 opens with 'Create one or more test cases (1-100) in a project's repository,' giving a specific verb, resource, and scope. This clearly differentiates it from sibling tools like testmo_update_cases or testmo_list_cases.

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?

It provides clear context for use: creating new test cases, with a batch size limit and note that only 'name' is required while others use defaults. However, it does not explicitly mention when not to use it or name alternatives like testmo_update_cases.

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

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It reveals a key constraint (cases required when include_all is false), but it does not disclose side effects, return value, permissions, or any destructive potential. For a mutation tool, this is a significant gap.

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?

The description is two sentences, front-loaded with the primary action, then the essential requirements. Every word earns its place, with no redundancy or unnecessary detail.

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?

Given the tool's complexity (12 parameters) and lack of an output schema, the description covers the most critical call information (required fields and conditional logic). However, it omits any explanation of return values or post-creation behavior, leaving some contextual gaps for an agent deciding how to use the result.

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?

The input schema already covers 100% of parameters, giving a baseline of 3. The description adds value by clarifying that state_id comes from testmo_list_states (entity 'run') and reiterating the conditional dependence between include_all and cases, which is helpful beyond the schema descriptions.

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 the tool's purpose with a specific verb and resource: 'Create a new manual test run in a project.' This distinguishes it from sibling tools like testmo_list_runs or testmo_update_run by specifying the creation action and the 'manual' test run type.

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 clear usage context by specifying required parameters and the source of state_id ('from testmo_list_states, entity 'run''). It also explains the conditional requirement for cases when include_all is false. However, it does not explicitly contrast this tool with alternatives, so it does not reach a 5.

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

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

With no annotations, the description carries the full burden. It discloses that the tool performs a raw GET, implying a read-only operation, but does not mention authentication requirements, error handling, response format, or rate limits. The behavior is minimally transparent but lacks deeper context.

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?

The description is two sentences, front-loaded with the 'Escape hatch' label, and every word earns its place. It is direct, clear, and free of fluff.

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?

For a generic raw GET tool with one parameter and no output schema, the description is largely complete. It explains its purpose and when to use it. It doesn't describe return values, but since it's a raw passthrough, that's not necessary. However, it could mention how errors are surfaced.

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?

The schema provides 100% coverage for the single 'path' parameter, describing it as the API path after /api/v1 with examples. The description reinforces this by saying 'everything after /api/v1' but adds no new semantic meaning beyond what the schema already conveys.

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 the tool performs a raw GET against any Testmo API path, with the specific scope of 'everything after /api/v1'. It also positions itself as an escape hatch for endpoints not covered by other tools, distinguishing it from the sibling tools that target specific resources.

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 explicitly says to use it for endpoints not covered by the other tools, providing a clear when-to-use directive. However, it does not name specific alternative tools or give explicit when-not-to-use scenarios beyond that, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the returned summary elements, but it does not explicitly state read-only behavior, authentication needs, or the effect of the 'expands' parameter. Still, 'get' implies a read operation, and the listed return fields offer some transparency.

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?

The description is a single, front-loaded sentence with no waste. It immediately communicates the tool's purpose and includes the key output components without redundancy.

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?

For a simple getter without an output schema, the description adequately communicates the return contents and the tool's scope. However, it lacks explicit mention of how the 'expands' parameter influences the response and does not differentiate from sibling tools, which slightly reduces completeness.

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?

The input schema already provides descriptions for both parameters (run_id and expands), so schema coverage is 100%. The description adds no further meaning about the parameters or their usage, which matches the baseline score.

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 the action ('Get') and the resource ('a single run's summary'), and enumerates the contents (name, status counts, totals, milestone). This distinguishes it from list-oriented siblings like testmo_list_runs and from the generic testmo_get.

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 no guidance on when to use this tool versus alternatives such as testmo_list_runs or testmo_get. There is no mention of use cases or exclusions, leaving the agent without directional support.

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

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

With no annotations provided, the description carries the full burden. It clearly indicates a read-only operation ('List') and reveals key behavioral aspects: support for filters and pagination. This is sufficient for a standard list tool, though it does not detail return format or permissions, which are typically expected from context.

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?

The description is a single sentence, front-loaded with the primary purpose, and includes no filler. Every word earns its place, and it efficiently conveys both the action and key capabilities.

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?

Given 7 parameters, full schema coverage, and no output schema, the description adequately summarizes the tool's role and capabilities. It mentions the main filter dimensions and pagination. It could be more complete by explicitly noting that the response is a paginated list of test cases, but this is strongly implied by 'List test cases'.

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 each parameter is already explained. The description adds minimal semantic value by grouping filters ('folder/name/template') and mentioning pagination, but this is already evident from the schema properties. It does not explain parameter interactions, such as recursive only applying when folder_id is set.

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 the action ('List'), the resource ('test cases'), and the scope ('in a project's repository'). It also mentions supported filters and pagination, which distinguishes it from sibling tools like testmo_create_cases and testmo_update_cases.

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 implies when to use the tool (to list test cases) but does not provide explicit exclusions or alternatives compared to sibling listing tools like testmo_list_runs or testmo_list_results. It states supported filters and pagination, giving context for common use, but lacks explicit 'use this instead of X' guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the output fields and does not mention important traits such as whether the operation is read-only (though 'list' implies it), whether pagination is supported, or whether archived projects are included. This is a gap for a tool with no annotation safety hints.

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?

The description is a single sentence that is front-loaded with the action and resource, and includes the key output details in parentheses. Every word contributes value without unnecessary verbosity.

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?

For a simple list tool with no parameters and no output schema, the description is largely complete: it states the purpose and the return fields. However, it lacks any mention of potential limitations like pagination or authorization requirements, which might be relevant for an agent. Overall, it is adequate for the tool's simplicity.

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?

The tool has zero parameters, and the schema coverage is 100% (empty properties). The baseline for 0 params is 4. The description adds context about the response structure (id, name, run/milestone counts), which is useful even though there are no parameters to explain.

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 the action ('List') and the resource ('all Testmo projects'), and adds the fields returned ('id, name, run/milestone counts'). This distinguishes it from sibling tools like testmo_list_runs, which list runs rather than projects.

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 verb 'List all' implies the tool is for retrieving a high-level view of all projects, but there is no explicit guidance about when to use it over alternatives or any exclusions (e.g., pagination, permission context). It relies on the tool name to convey the distinction from siblings.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals a key nuance (only tests with recorded results) and clarifies the test_id linkage, but omits other behavioral details like pagination behavior or that it's a read-only operation (though 'List' implies it). This is partial but not complete transparency.

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. The main action is stated first, and the critical caveat about recorded results is front-loaded in a clear note. Every phrase adds value.

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 7 parameters and no output schema, yet the description is compact. It addresses the most important surprise (recorded result filtering) and the run_test_id relationship, but doesn't cover pagination, expand options, or result structure. It's adequate for basic use but not fully complete for a parameter-rich 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 adds no extra parameter-level semantics beyond the schema; the test_id note relates to the output rather than input parameters, so it doesn't improve parameter understanding.

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 'List recorded test results for a run' with a specific verb and resource. It further differentiates from siblings by noting it returns tests with recorded results, not every case, which distinguishes it from run/case listing tools.

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 implies its use when you need recorded results for a run, and adds a cross-reference to recoding results via test_id. However, it does not explicitly present alternatives or exclusion criteria, so usage guidance is indirect rather than explicit.

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

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

No annotations are provided, so the description carries the burden of behavior disclosure. It states the operation is 'list', implying read-only, and mentions supported filters and pagination. However, it does not describe return format or any edge-case behavior, which would be useful.

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?

The description is two sentences long, front-loaded with the main purpose, and every word adds value. No redundancy or unnecessary details.

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?

For a list tool with comprehensive parameter schema, the description covers purpose and available options. Since there is no output schema, a brief note on the return value would improve completeness, but overall it is sufficient for correct invocation.

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 coverage is 100%, with each parameter already having a description. The description merely summarizes the filters without adding extra semantic detail beyond what the schema already provides.

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 'List manual test runs for a project', using a specific verb and resource. It distinguishes from sibling tools like testmo_list_cases and testmo_list_results by specifying 'manual test runs'.

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 clearly indicates when to use the tool: to list runs with optional filtering and pagination. It does not explicitly mention alternatives like testmo_get_run for single-run lookups, but the context is clear enough for agent selection.

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

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

No annotations are provided, so the description is the sole behavioral disclosure. It correctly signals a read-only list operation and hints that returned states include state_id, but it does not describe response structure, pagination, or permissions.

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, front-loaded with the core action and scope. No wasted words.

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?

For a one-parameter list tool, the description gives the purpose, input scope, and why the output is needed. It does not spell out the return structure, but the state_id mention covers the main downstream use.

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?

Only parameter is project_id, and the schema already describes it as 'Project ID' with 100% coverage. Description adds project context but no additional syntax or constraints, so baseline 3.

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?

States it lists workflow states for a project and names the relevant types (run, repository_case, session). The tie to state_id clarifies the tool's role and differentiates it from sibling list tools.

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?

Explicitly states it is needed for state_id when creating a run or a case, giving clear when-to-use guidance. It does not name alternatives or exclusions, so not a perfect 5.

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

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

No annotations are provided, so the description carries the full burden. It discloses that the tool returns a mapping of id to name and gives examples, but it does not mention other behavioral aspects such as read-only guarantees, ordering, or potential absence of statuses. For a simple list operation, this is adequate but not exhaustive.

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?

The description is two sentences, front-loading the core function and then adding a practical rationale. Every word earns its place with no redundancy or filler.

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?

For a single-parameter, read-only list tool, the description provides the essential context: what it lists, the format (id→name), and why it matters. Since there is no output schema, the description partially covers return values. It does not discuss edge cases or project-specific variations, but those are minor for this simple 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?

The schema already documents project_id as 'Project ID' with 100% coverage. The description adds context by tying project_id to the project whose statuses are listed, but it does not add significant meaning beyond what the schema provides. Baseline 3 is appropriate given high schema coverage.

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 specifies the tool's function: listing result statuses for a project, with a concrete id-to-name mapping and examples. It distinguishes itself from sibling tools like testmo_list_runs or testmo_list_results by focusing on statuses and explicitly connecting to the action of recording a result.

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 gives a clear usage context: it is needed to determine the correct status_id when recording a result, thus implicitly directing when to use this tool (before testmo_record_result). It does not explicitly name alternatives or exclusions, but the context is sufficiently clear.

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

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

With no annotations, the description carries the full burden. The verb 'List' clearly indicates a read-only operation, and it adds useful context about the purpose of the returned templates (template_id and custom_* fields). However, it does not explicitly state lack of side effects or describe response format, but for a simple list tool this is sufficient.

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?

The description is concise, consisting of two short sentences that are front-loaded with the core action. Every sentence adds value without redundancy.

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?

For a simple list tool with one parameter and no output schema, the description is complete enough: it states what is returned (templates), why it is needed (template_id and custom_* fields), and the required context (project). Minor missing details like where to obtain project_id are secondary.

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% (project_id described as 'Project ID'). The description reinforces that templates are for a project, but adds minimal semantic value beyond the schema. Baseline 3 is appropriate since the schema already documents the parameter.

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 the tool lists case templates for a project, using the specific verb 'List' plus resource. It distinguishes itself from siblings by specifying 'case templates' and 'project', and even explains its relation to creating cases via template_id.

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 clear usage context: it is needed for template_id when creating cases and to know which custom_* fields a template accepts. This implies the appropriate time to use it (before creating cases) and gives value, though it does not explicitly mention when not to use it or alternatives.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It only says 'Record a result' without stating whether this is a mutating operation, whether it overwrites existing results, what permissions are needed, or what the return value is. This leaves significant behavioral ambiguity for an operation that writes data.

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?

The description is exactly two sentences with no fluff. The first sentence front-loads the primary action, and the second sentence efficiently clarifies two critical parameter references. Every word earns its place, making it concise and well-structured.

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 annotations and no output schema, so the description must compensate. It covers the operation and key parameter lookup paths, but it omits behavioral side effects, return value, and any mention of the bulk sibling for larger batches. For a mutation tool with this complexity, the gaps are noticeable but not fatal, making it minimally adequate.

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?

The input schema already describes all five parameters (100% coverage), giving a baseline of 3. The description adds value by explaining that run_test_id is the per-run test id shown as test_id in testmo_list_results and that status_id should come from testmo_list_statuses, which goes beyond the schema's terse one-line descriptions and reduces lookup errors.

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 the verb ('Record') and the resource ('a result for one test in a run'). The phrase 'one test' explicitly distinguishes this from the sibling tool testmo_record_results_bulk, and the mention of run_test_id clarifies the exact scope of the operation, making the purpose unambiguous.

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 clear context by specifying that this tool records a single test result and directs users to testmo_list_statuses for valid status IDs, which is practical guidance. However, it does not explicitly mention alternatives like the bulk-record sibling or state when not to use this tool, so it lacks explicit exclusions but still gives useful context.

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

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

With no annotations, the description carries the burden of disclosing behavioral traits. It clearly discloses the critical all-or-nothing validation behavior: an invalid item rejects the whole batch. It also mentions the batch size limit (1-100). This adds significant context beyond the schema, though it does not cover authentication or return format.

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, front-loaded with the primary purpose and followed by essential constraints. Every word earns its place, with no redundant or filler content.

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?

Given the absence of annotations and output schema, the description covers the core operational aspects: batch size, required fields, and atomic validation behavior. It does not explain the response structure or prerequisites (e.g., run must exist), but the provided schema and the key behavioral detail are sufficient for basic usage.

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?

The schema already provides 100% coverage with descriptions for all parameters. The description reinforces that each item requires test_id and status_id and clarifies that test_id is the per-run test id from testmo_list_results, which is already in the schema. Thus it adds minimal new semantic value beyond the structured data.

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 the specific action: recording results for multiple tests in a run in a single request. It distinguishes itself from the sibling tool testmo_record_result by emphasizing 'multiple tests' and 'one request', making the bulk nature explicit.

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 implies the appropriate use case: when you need to record results for multiple tests at once rather than one by one. It also directs users to obtain test_id via testmo_list_results. However, it does not explicitly name alternative tools or state when not to use it, missing a stronger guideline.

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

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

With no annotations, the description carries the burden and discloses key non-obvious behaviors: PATCH semantics, same values written to every listed case, and the requirement that custom fields exist in every targeted case's template. This goes beyond simple 'updates cases' and helps the agent anticipate side effects. It lacks error/authorization details, but the core behavior is well covered.

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?

Three sentences, each carrying essential information. The first sentence states the action, the second explains the core behavior (same values for all), and the third clarifies a subtle custom-field requirement. No filler, no repetition of schema details.

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?

For a 10-parameter update tool with nested objects and no output schema, the description covers the most critical operational aspects: batch semantics, custom-field handling, and singular/multiple id usage. It could mention that only provided fields are updated (PATCH), but that is already implied by the 'PATCH' mention. Given the rich schema, this description is adequately complete.

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?

The schema already documents all parameters (100% coverage), so the baseline is 3. The description adds meaningful semantic value by explaining that field values are applied uniformly to all ids, that 'name' is intended for single-id use, and how the 'custom' object must align with case templates. This reduces ambiguity beyond the schema alone.

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 opens with 'Update 1-100 repository cases (PATCH)' — a specific verb, resource, and method. It clearly distinguishes from siblings like testmo_list_cases (listing) and testmo_create_cases (creating), and the '1-100' scope adds precision.

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?

Provides clear context on how to use the tool: pass 'ids' plus fields to apply to all, with the note that 'name' is normally used with a single id. It also explains custom field placement and template constraints. It does not explicitly name alternatives, but the usage is well implied relative to sibling create/list tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the critical PATCH semantics ('Only provided fields change') and the irreversible closure behavior ('runs cannot be re-opened via the API; false is rejected'). This goes beyond the schema and gives agents essential edge-case knowledge.

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?

The description is three short sentences, each earning its place. It front-loads the purpose, then adds critical behavioral caveats. There is no redundancy or vague filler.

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?

Despite having 10 parameters and no output schema, the description covers the key operational context needed to invoke the tool: PATCH semantics and closure irreversibility. It does not explain return values or error handling, but those are less critical for a simple update operation given the comprehensive schema.

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 schema already explains each parameter. The tool description adds the partial-update semantic and clarifies the is_closed behavior beyond the schema note, but most parameter meaning remains in the schema. Since the schema does the heavy lifting, a baseline of 3 is appropriate.

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 opens with 'Update a run (PATCH)', which gives a specific verb ('Update'), a resource ('run'), and the HTTP method. It clearly distinguishes from siblings like testmo_create_run and testmo_update_cases by making the target resource explicit.

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 operational guidance: 'Only provided fields change' and 'Set is_closed=true to close a run'. However, it does not explicitly state when to choose this tool over alternatives (e.g., testmo_update_cases) or mention exclusions, so usage context is implied rather than explicitly framed.

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