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

With no annotations provided, the description carries the full burden, and it does so well. 'Presentation-only' and 'cannot change governed execution or evidence' accurately disclose both what the tool does and what it will not do, giving the agent clear safety expectations.

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 compact sentences with no filler. The first sentence front-loads the action and preconditions, and the second adds the essential limitation. Every sentence earns its place.

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 zero-parameter tool with no output schema, the description provides everything needed: what happens, when it should happen, and what side effects it cannot have. No important invocation information is missing.

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 is already fully covered. With no parameters to document, the description does not need to add parameter explanations; the baseline for zero-parameter tools applies.

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 names a specific action ('Open') and a distinct resource ('MartinLoop Arcade') and scopes it as presentation-only. It differentiates the tool from the run/eval/status siblings by emphasizing it is strictly a display surface, not a control surface.

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 states the condition under which the tool should be used ('when the host supports MCP Apps'). It also tells the agent not to use it for mutating or governed workflows by clarifying that the Arcade 'cannot change governed execution or evidence'.

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?

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds useful context by clarifying that the tool reads 'persisted evidence' and that omitting loopId dynamically loads the latest run. The closing sentence reinforces the read-only guarantee, though it is somewhat redundant with the annotations.

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 four sentences with no filler. It front-loads the core purpose, then covers parameter behavior, usage boundaries, and read-only safety, with every sentence earning its place.

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 a single optional parameter, an output schema, and annotations covering safety, the description is complete. It provides purpose, usage constraints, alternatives, parameter guidance, and state-change guarantees, so an agent can select and invoke the tool correctly.

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% and the schema already documents loopId as optional with the 'omit to read latest run' behavior. The description restates this logic but adds no new semantic detail beyond the input 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 uses a specific verb ('Read'), names a precise resource ('read-only evidence projection used by the Arcade view'), and explicitly distinguishes itself from sibling tools like martin_status and martin_run_dossier. An agent can immediately understand what this tool does and how it differs from alternatives.

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 states 'Use only for Arcade rendering' and explicitly redirects to martin_status for budget pressure and martin_run_dossier for full evidence. It also explains the loopId behavior clearly: provide it for an exact run or omit it for the latest run.

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?

Annotations already mark the tool as destructive and non-idempotent, and the description adds useful context beyond that: the receipt is durable, the operation records a request rather than killing a process, and reason/requestedBy provide audit context. This helps an agent understand the side-effect profile without contradicting the annotations.

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 compact, front-loaded with the core purpose, and every sentence earns its place. It covers purpose, selector rule, usage condition, alternative, and a key non-behavior without repetition.

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 definition is complete for a cancellation tool of this complexity: it explains the selector constraint, the audit parameters, the durable nature of the receipt, and the distinction from pausing. Since an output schema is present, the description need not detail return values.

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 the baseline is 3, but the description adds meaningful parameter semantics: it states that exactly one selector (file, loopId, or latest) must be provided, explains that runsDir changes the run-store root, and clarifies that reason and requestedBy are audit context. This goes beyond the schema's individual property 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 names a specific action ('Write a durable cancellation receipt') and a specific resource ('one canonical MartinLoop run'), and it differentiates this tool from martin_pause by stating that cancellation is for abandoned work, not temporary holds. The selector options are also clearly summarized.

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 when to use the tool ('when work must be abandoned, not temporarily held') and identifies the alternative ('use martin_pause for a reversible hold'). It also clarifies a non-goal: this records a request and does not kill a process.

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?

Annotations already provide idempotentHint=false and destructiveHint=true, so the description does not need to restate those. It adds useful context about durability and the pause/approval timing, but does not explain side effects such as what state is changed or whether this actually resumes execution. No contradiction with annotations.

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 filler. Every part earns its place, and the key action and timing are clear immediately.

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 an output schema, the tool has six undocumented parameters and no parameter descriptions. One sentence describing purpose is not enough for an agent to invoke it correctly without guessing at parameter semantics.

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 0%, and the description offers no explanation for any of the six parameters: file, latest, loopId, reason, runsDir, and requestedBy. An agent has no guidance about what values are expected or how they relate to a continue request.

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 uses a specific verb ('Record') with a clear resource ('a durable continue or resume request for a Martin run') and a precise context ('after a human pause or approval checkpoint'). This semantically distinguishes it from sibling tools like martin_pause, martin_cancel, and martin_run even without naming them.

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 states when to use the tool: after a human pause or approval checkpoint. It does not explicitly name alternatives or exclusion cases, but the context is specific enough to guide invocation.

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?

The description adds meaningful behavior beyond annotations by revealing that the default action is preview, and that the external gh command is only invoked when execute=true. Annotations already declare destructiveHint=true and idempotentHint=false, so the lack of extra destructiveness detail is acceptable.

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 tightly written sentences deliver the core purpose first and the critical execution gate second. Every word earns its place; there is no filler or repetition.

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 a clear high-level purpose and an output schema, the tool has eight optional parameters with zero documentation and a 0% schema description coverage. An agent lacks necessary context about file/runsDir semantics, latest/loopId coupling, format effects, and what happens without execute.

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 0%, so the prose must compensate, but it only explains execute. The remaining parameters (base, file, title, format, latest, loopId, runsDir) are left entirely undefined in both the schema and the description, making it hard for an agent to populate them correctly.

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 names a concrete operation ('Create or preview a GitHub PR') with a specific body source ('MartinLoop dossier'). It is immediately distinguishable from siblings like martin_review_pr and martin_pr_summary because it clearly targets PR creation rather than review or summarization.

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?

There is no guidance on when to choose this tool over alternatives among the many PR- and dossier-related siblings. The only directive is 'Use execute=true to actually call gh,' which is parameter-level execution guidance rather than a tool-selection criterion.

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?

Annotations already declare readOnlyHint and idempotentHint, and the description's 'Read-only' phrasing reinforces this without adding conflict. It adds behavioral value by scoping the diagnostic domains and by warning that the output is not proof of completion, which is a meaningful non-obvious trait. With annotations covering safety, this is strong but not maximal.

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 concise sentences deliver purpose, usage timing, exclusions, and next steps with no filler. The most important information is front-loaded, and every sentence earns its place. Reusing 'Read-only' from annotations is minor redundancy but not harmful to an agent scanning prose.

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 tool with zero required parameters, a complete output schema, and read-only/idempotent annotations, the description covers all essential decision-making context. It includes scope, when to invoke, what not to infer, and which sibling to call next. An agent can safely invoke this tool correctly without further clarification.

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%, with all three optional parameters already thoroughly described in the input schema. The description itself adds no parameter-specific guidance, but the schema carries the full burden. This meets the baseline for a fully covered 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 identifies the tool as read-only diagnostics for environment, engine, workspace, and run-store data, which is specific about resources and scope. It lacks an explicit active verb like 'get' or 'run', instead using the noun phrase 'diagnostics', though the intent is unmistakable. It distinguishes from siblings by positioning itself as a first-step diagnostic rather than a completion check.

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 states when to use the tool: 'Use first for software work, fresh installs, suspicious state, or before retries.' It also provides a clear exclusion: 'Do not use as proof that a task is complete.' It routes the agent to the appropriate next tool based on whether the work is new or failed, making the decision tree 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds behavioral context: it requires exactly one selector, explains that runsDir changes the run-store root, and notes that json is the default format. It doesn't describe the return shape, but the output schema exists and the description's added constraints are 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 compact and front-loaded: it states the core action in the first sentence, then selector/format rules, then usage context, then an exclusion. Every sentence earns its place, and the structure moves from what to how to when.

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 read-only, idempotent tool with a full output schema and 100% parameter coverage, the description is complete. It covers selector semantics, format options, default behavior, runsDir override, when to use it, and when not to use it. The only minor gap is not describing the exact content of the formatted summary, but the output schema and the phrase 'evidence summary' cover that sufficiently.

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 documents all five parameters. The description adds value by clarifying the mutual exclusivity of selectors ('Provide exactly one selector') and by explaining that runsDir is a root override for resolving loopId or latest. It also names the format enum values and the default, which reinforces the schema without repeating it verbatim.

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 reads a formatted evidence summary for a MartinLoop run, with specific selector options (file, loopId, latest) and format options. It distinguishes itself from martin_run_dossier by explicitly saying it is not a substitute for the full structured record, and it names the sibling tool for that purpose.

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 explicit when-to-use guidance: 'Use after martin_run, before merge or release claims, or when sharing what happened.' It also provides a clear exclusion: 'Do not use as a substitute for missing verifier evidence; use martin_run_dossier for the full structured record.' This is strong routing 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this with 'Read-only' and 'not as permission to execute.' It adds context about producing a pre-work burn estimate and warns about budget/risk consent, going beyond the bare annotation flags. No contradictions with annotations.

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 deliver purpose, usage conditions, exclusions, and next-step guidance with zero filler. The most important information—read-only estimation—is front-loaded, and every clause earns its place.

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 that annotations cover read-only and idempotent behavior, the schema covers all parameters, and an output schema exists, the description fills the remaining gaps: when to use it, what it is for, and what to do next. Nothing needed for correct invocation is missing.

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 the schema itself documents all parameters. The description adds general context about 'software objective' and 'budget/risk' but does not provide new meaning for individual parameters beyond the schema. Baseline 3 is appropriate; the description does not carry the parameter documentation burden.

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 a specific verb and resource: 'Read-only cost, route, and pre-work burn estimate for a software objective.' This clearly distinguishes the tool from planning, execution, and run-management siblings like martin_plan and martin_run. It also communicates the operative scope—estimating, not executing.

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 when to use it ('before planning/preflight when a change may spend agent time or exceed budget') and when not to ('Do not use for casual questions or as permission to execute'). It also provides a concrete next step: call martin_plan if acceptable, or ask for consent for high budget/risk. This is exemplary routing 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating it 'reads saved run evidence and inspects local git signals' and 'does not modify state or contact GitHub.' It adds valuable context beyond the annotations by revealing that the tool operates on local signals only and does not reach out to GitHub, which is not inferable from structured fields alone.

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 dense but well-structured, front-loading the core purpose before usage guidance and exclusions. Every sentence earns its place: purpose, when to use, workflow placement, what not to use it for, and behavioral guarantees. It avoids fluff and provides substantial decision-relevant information in a compact form.

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 that the tool has an output schema and strong annotations, the description covers the remaining context an agent needs: the domain of operation (MartinLoop run grading), the six dimensions, merge-readiness interpretation, workflow ordering, alternatives, and side-effect guarantees. The optional parameter selection is already documented in the schema, and the output schema covers return-value expectations, so no critical context is missing.

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 parameters already have clear descriptions in the schema, including mutual exclusivity between file, latest, and loopId. The description itself does not add much parameter-level detail beyond saying it grades a run, but with complete schema coverage this is acceptable and does not require compensation.

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 a specific verb and resource: 'Grade a MartinLoop run across six dimensions' and clearly states the output is 'a scored merge-readiness verdict.' It distinguishes the tool from siblings by explicitly listing what it is not for, such as retrieving raw verification output and reviewing PR bodies, so an agent can tell it apart without opening schemas.

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 explicit timing guidance ('Use after a governed run completes'), workflow placement ('Use before martin_pr_summary or martin_create_pr'), and two explicit negative use cases with named alternatives (martin_get_verification_results and martin_review_pr). This leaves little ambiguity about when to invoke this tool versus its 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety and idempotency are covered. The description adds that the tool returns a 'summary with artifact directory references', which is useful but does not elaborate on what those references are or how they are structured. Given the read-only and idempotent hints, the bar is lower, and the description provides some additional context, so a 3 is appropriate.

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, concise sentence that front-loads the main purpose and includes key details (attempt summary, artifact directory references, canonical run). It is efficient and readable, with no unnecessary 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?

The tool has four parameters, an output schema exists, and annotations cover safety. The description provides a high-level purpose but does not clarify which parameters are required or how they interact (e.g., the relationship between file and loopId). Given the complexity and available schema, the description is sufficient for basic understanding but not fully complete for edge 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%, meaning each parameter has a description in the schema. The tool's description adds limited value beyond the schema, mainly implying that the tool focuses on a single attempt and that attemptIndex defaults to the latest. It does not explain how the parameters interplay (e.g., file versus loopId). Baseline 3 is correct because the schema already documents parameters adequately.

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 states a specific action ('Load'), a specific resource ('one Martin attempt summary'), and the key scope ('for a canonical run'). It is clear what the tool does at a high level, but it does not explicitly differentiate from sibling tools like martin_get_run or martin_get_verification_results, which also appear to retrieve run-related data.

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 does not specify when to use this tool versus its siblings. For instance, it does not indicate that this tool is for inspecting a specific attempt within a run, while martin_get_run might be for whole-run details. There is no explicit guidance on which scenarios warrant this tool over alternatives, leaving the agent to infer from the name.

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?

Annotations already declare readOnlyHint and idempotentHint, covering safety and repetition behavior. The description adds that the tool returns a specific summary of fields, but it does not disclose any additional behavioral traits such as error behavior, how missing runs are handled, or constraints on parameter combinations. With annotations in place, this is an acceptable baseline.

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, well-structured sentence that leads with the action and then lists the output components. Every word earns its place, and there is no redundant or vague phrasing.

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 that an output schema and readOnly/idempotent annotations exist, the description adequately summarizes what the tool does and returns. However, it does not clarify that exactly one of file, latest, or loopId should be used, or whether these are mutually exclusive. This is a minor gap for a read-only retrieval 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 input schema provides descriptions for all 4 parameters, so schema coverage is 100%. The tool description itself adds no parameter-level meaning, and the baseline of 3 is appropriate because the schema carries the burden.

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 uses a specific verb ('Load') and names the resource ('one Martin run'), then enumerates the returned fields (budget, cost, verification, artifact, canonical path summary). This makes the core purpose clear, but it does not explicitly differentiate from siblings like martin_get_attempt or martin_get_verification_results, aside from the field listing.

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 no guidance on when to choose this tool over alternatives, nor does it mention parameter selection rules (e.g., file vs latest vs loopId). Agents are left to infer usage from the schema alone, and no exclusions or sibling comparisons are provided.

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?

Even though annotations already mark readOnly and non-destructive, the description adds behavior beyond annotations: it reads persisted run files, does not execute commands, modify state, or contact GitHub. This is valuable operational context and does not contradict annotations.

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 earning its place: core purpose, when to use, exclusions, and behavioral boundary. The alternatives and constraints are front-loaded and the prose is tight.

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?

With a rich output schema, fully described parameters, and annotations, the description is nearly complete. It does not explicitly state that at least one of file or loopId should be supplied despite the schema listing none as required, which is a small but real invocation gap.

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 the input schema already documents file, loopId, and runsDir with their meaning and mutual exclusivity. The description adds no further parameter-level detail, which is acceptable because the schema carries the burden.

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 names a specific verb (Load), resource (structured verification evidence for a MartinLoop run), and content (verifier commands, pass/fail outcomes, contradiction signals). It explicitly distinguishes itself from martin_eval and martin_get_status, so an agent can tell it apart without opening schemas.

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 gives explicit when-to-use ('after a run completes' to confirm verifiers passed before merging/promoting) and explicit when-not-to-use with named alternatives (martin_eval for merge-readiness, martin_get_status for live status). These exclusions leave no ambiguity about routing.

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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description does not contradict those annotations, but it adds little beyond the verb 'Summarise'—no detail about what gets read, potential output size, or any other behavioral traits. This meets the baseline with annotations present.

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?

A single, front-loaded sentence with no filler: verb, object, and source are all in the first clause. It is scannable and every word earns its place.

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?

This is a low-complexity read-only tool with full annotations, an output schema, and two fully described optional parameters. The description adequately captures the operation and input source. The main gap is the lack of selection guidance among siblings, but that is less critical given how simple and safe the operation is.

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 fully documents both parameters. The description mentions 'saved loop file or run-store directory', which mirrors the file parameter's schema description and adds no new format, syntax, or precedence information. Baseline 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 clearly states a specific verb ('Summarise') and resource ('Martin Loop run records') plus the input source. It implies an aggregate, read-oriented operation distinct from siblings like martin_list_runs or martin_get_run, but does not explicitly differentiate itself by name, so it stops short of a perfect score.

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?

No guidance is given on when to use this tool versus the many sibling inspection tools (e.g., martin_get_run, martin_list_runs, martin_triage_runs, martin_run_dossier). The only implicit usage context is the accepted input types in the description, but there are no exclusions, conditions, or alternative routing hints.

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?

Annotations already cover readOnlyHint and idempotentHint, so the safety profile is established. The description adds scope context ('run store', 'recent', 'lightweight filters') but discloses little beyond what the annotations and parameter schemas already imply; there is no contradiction.

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?

A single, front-loaded sentence names the operation and then summarizes the filter dimensions without any filler. Every word contributes to the agent's understanding.

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?

With no required parameters, fully described schema entries, safe annotations, and an existing output schema, the description is largely sufficient for correct invocation. It lacks only explicit alternative routing to siblings, which is more of a usage-guidance gap than a completeness gap.

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 a useful conceptual grouping—status, lifecycle, engine metadata, and recency—that helps an agent map the seven optional filter parameters into meaningful categories beyond the flat schema entries.

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 states a specific verb ('List') and resource ('Martin runs from the run store'), making it clear this is a listing operation distinct from run/get/inspect/status siblings. It does not explicitly contrast itself with martin_triage_runs, so it falls just short of full sibling differentiation.

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 usage: call this when you need a recent list of runs with lightweight filters, but it gives no explicit guidance about when to prefer a sibling like martin_get_run or martin_triage_runs. The context is clear enough to infer, but no exclusions or alternatives are stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds operational context beyond those flags: it only reads persisted run files, does not execute commands, does not modify state, and does not contact GitHub. This network-isolation and no-execution detail is valuable behavioral context not present in annotations. No contradiction.

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?

Four sentences with zero waste: core purpose, use cases, two exclusions, and a behavioral guarantee. The verb+resource is front-loaded, and every sentence earns its place.

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?

Complete for a read-only observational tool. The description covers purpose, usage context, exclusions, and behavior; the output schema explains return values; and annotations cover the safety profile. Nothing an agent needs to invoke it correctly is missing.

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 all five parameters (file, limit, latest, loopId, runsDir) are fully documented in the schema. The description hints at the single-run scope that maps to the mutual-exclusion constraints, but it does not add parameter-level detail beyond the schema. Baseline 3 is appropriate when the schema carries the full burden.

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 states a specific verb ('Read'), a precise resource ('MartinLoop events, ledger entries, and operator control receipts'), and a scope ('for a single run'). It distinguishes itself from siblings by naming what it is not (martin_get_status, martin_get_verification_results), so an agent can select it confidently without opening schemas.

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 when to use ('observe live or completed run activity, diagnose stuck or failed runs, or audit operator actions') and when not to use, naming two alternatives with the conditions that route elsewhere. Nothing is left to inference.

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?

The description adds useful behavioral context beyond the annotations: it clarifies that the tool 'records a request' and 'does not kill a process,' which tempers the destructiveHint and prevents the agent from expecting process termination. It also conveys durability and audit-context behavior. It does not fully explain what side effects the destructiveHint refers to, but it does not contradict the annotations.

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 compact and front-loaded: purpose first, then the central selection constraint, then the usage context, then behavioral clarification and sibling routing. Every sentence contributes information; there is no filler or redundant repetition of the schema.

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?

With six parameters, a one-of selection requirement, an output schema, and many sibling tools, the description is sufficient for an agent to call the tool correctly. It covers the selection constraint, the effect of each parameter group, the appropriate use case, and how this tool differs from cancel/continue. The output schema removes the need to describe return values.

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 the schema already documents each parameter. The description adds value by grouping parameters into functional roles: selectors (file/loopId/latest), run-store override (runsDir), and audit context (reason/requestedBy). It also communicates the critical 'exactly one selector' rule, which the schema only fragments through mutual-exclusion notes.

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 a specific verb and resource: 'Write a durable pause receipt for one canonical MartinLoop run.' It immediately distinguishes this tool from cancel/continue by defining the artifact it produces, and the 'exactly one selector' constraint sharpens the operational intent. No ambiguity about what the tool is for.

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 explicitly states when to use the tool: 'for a temporary hold before risky follow-up work.' It also gives direct routing guidance by naming martin_cancel and martin_continue as alternatives for abandoning or resuming work, so an agent can choose between siblings without guessing.

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?

Annotations already provide readOnlyHint and idempotentHint. The description reinforces the read-only nature, adds what the tool produces, and clarifies that it does not mutate files or replace the verifier. This adds useful behavioral context beyond the annotations, though idempotence is not explicitly discussed.

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, with the core purpose front-loaded and no filler. Every sentence adds useful information about scope, usage boundaries, or next steps.

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 an output schema and safety annotations, the tool is complex with 13 input parameters. The description gives a good workflow overview but does not explain how to choose or set the many constraint parameters, which are mostly undocumented at 23% schema coverage. An agent would struggle to construct a well-formed planning request.

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 only 23%, so the description must compensate for the many undocumented parameters. It mentions 'objective', 'scope', 'budget', and 'verifier', but does not map these to specific fields such as maxUsd, verificationPlan, policyPack, allowedPaths, or deniedPaths. Most parameters remain unexplained in both schema and description.

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 identifies this as a read-only planning step that converts an objective into concrete artifacts: bounded scope, verifier proposal, policy pack, and risk recommendation. It also differentiates itself from preflight and run by explicitly positioning itself before those phases.

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 when to use it ('before preflight/run' for 'authorized software changes'), when not to use it ('Do not use to mutate files or replace the verifier'), and what to do next ('call martin_preflight with the chosen scope, budget, and verifier'). This is exemplary 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful context beyond that by specifying exactly what the validation covers (engine, verifier, path scope, budget) and clarifying it is not a proof of execution or completion. This enriches the behavioral contract without contradicting the annotations.

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 deliver the purpose, usage timing, checks performed, exclusion, and next step. Every clause earns its place, and the most critical info (purpose) is front-loaded. There is no fluff or 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 preflight validation tool with 17 parameters, an output schema, and read-only/idempotent annotations, the description fully covers the needed context: what it validates, when to call it, what it is not, and what to do next. The output schema handles return specifics, so no additional return-value explanation is needed. An agent can invoke this tool correctly with no missing information.

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 82%, and most parameters have clear descriptions (e.g., engine enum, maxUsd, maxTokens, deniedPaths). The description does not add parameter-specific details beyond what the schema already provides. With high coverage, the description is not required to elaborate on each parameter, so a baseline score 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 states a specific action ('Read-only validation of the exact run contract') on a specific resource (the run contract) and explicitly distinguishes it from execution by noting 'before execution or spend' and naming the sibling martin_run. It also makes clear it is not a proof of completion, removing any ambiguity about its role.

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 explicit timing ('Use after planning and before martin_run'), states the checks it performs (engine, verifier, path scope, budget), and directs the next action ('call martin_run if allowed, otherwise resolve the reported blocker'). It also says 'Do not use as execution or completion proof,' which is a clear when-not-to-use condition. No exclusions or alternatives are left unstated.

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?

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint, and the description adds useful concrete context: it only reads saved run evidence, does not modify the repository, and does not contact GitHub. This goes beyond the annotations by explicitly ruling out network side effects and repo mutations.

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 main purpose is front-loaded, the alternative routing is compressed into clear usage guidance, and the no-side-effect statement earns its place. Every sentence contributes to selection, invocation, or safety clarification.

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?

With an output schema present and strong annotations, the description covers when to use it, what it consumes, what it produces, and what it does not do. An agent has enough information to invoke it correctly without guessing.

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 documents all five parameters, their mutual exclusivity, and format defaults. The description does not add parameter-level detail, but it does not need to since the schema covers it.

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?

Opens with a specific verb ('Generate') and names the concrete artifacts: a GitHub-ready PR title and Markdown body from a completed MartinLoop run dossier. It also distinguishes itself from martin_create_pr, martin_review_pr, and martin_eval, so an agent can tell which sibling to pick.

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 when to use the tool: after a governed run completes when PR copy is needed without creating the PR. It also names the alternatives for actually opening the PR, reviewing an existing PR, and obtaining a merge-readiness grade first.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is well-covered. The description adds valuable context beyond annotations: it clarifies the tool 'only reads saved run evidence and does not modify the repository or contact GitHub,' which is a specific behavioral guarantee not present in the annotations. It also explains the behavior of omitting prBody (evaluates the auto-generated body). This adds meaningful behavioral transparency without contradicting any annotations.

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 front-loaded with the core purpose, then provides usage guidance, exclusions, and a safety note in a logical flow. Every sentence serves a distinct function—purpose, when-to-use, exclusions, and behavioral transparency—with no filler or redundancy. It is appropriately sized for the tool's complexity.

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 has an output schema and rich annotations, the description covers all essential aspects: it explains what the tool does, when to use it, when not to use it (with alternatives), the key parameter behavior (prBody omission), and its non-destructive nature. No critical information is missing for an agent to select and invoke this tool correctly.

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 has 100% description coverage, so each parameter's purpose is already well-documented. The description adds minimal additional parameter semantics: it reiterates the prBody behavior (supply to review a specific body; omit to evaluate the auto-generated one) which duplicates the schema's description. No other parameters receive additional explanation in the description, so it does not exceed the baseline expected for 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 states a specific verb ('Review'), a specific resource ('PR body or draft against the MartinLoop run dossier and evaluation evidence'), and a specific output ('a verdict with specific findings'). It also differentiates itself from siblings by naming martin_pr_summary and martin_create_pr as alternatives for different tasks, making the tool's distinct role 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 explicitly states when to use this tool ('Use when you have an existing PR body and want to check whether it accurately represents the governed run evidence') and when not to use it, naming the exact alternative tools ('Do not use to generate a PR body from scratch — use martin_pr_summary instead. Do not use to open or create a PR — use martin_create_pr instead.'). This provides clear routing with no ambiguity.

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?

Annotations already declare destructiveHint=true, openWorldHint=false, idempotentHint=false. The description adds context about governance and prerequisites ('governed', 'after MCP workflow admission is satisfied') but does not disclose additional behavioral traits such as file modification scope, side effects, or failure modes beyond what annotations imply. It neither contradicts nor enriches beyond the annotations significantly, so a 3 is appropriate.

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 sentences, front-loaded with the purpose, then usage conditions, then next steps. Every sentence earns its place; there is no redundancy or filler. It is 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?

Given the 14-parameter schema (fully documented) and presence of an output schema, the description covers the essential operational context: when to invoke, prerequisites, and next steps. It lacks explicit detail on the execution behavior (e.g., that it modifies files and runs verification), but this is implied by 'coding run' and the verificationPlan parameter. Minor gap, so 4.

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 all 14 parameters are fully documented in the input schema. The description does not add any parameter-specific meaning or clarify usage of individual parameters. Since the schema carries the full load, the description adds no value here, justifying the baseline score of 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?

The description clearly states the action ('Execute a governed MartinLoop coding run') and the resource (MartinLoop coding run). It specifies the verb and resource, and the context of 'after MCP workflow admission is satisfied' adds specificity. It differentiates from question-only diagnosis, though it doesn't name specific sibling tools. This is clear and near-excellent, but lacking explicit sibling distinction.

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 when to use: 'when the user has authorized implementation, bug fixing, tests, or refactoring and doctor/estimate/plan/preflight receipts match this task.' And when not to use: 'Do not use for question-only diagnosis or when policy, budget, credentials, or scope still need consent.' Also provides next steps. This is exemplary usage 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?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description carries a lower burden. It adds some context about the tool reading a comprehensive dossier, but no additional behavioral traits such as return format or side effects. This is adequate but not rich.

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 sentences with no filler: the main purpose, the selector constraint, and the usage routing. It is front-loaded with the core action and every sentence earns its place.

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 read-only tool with annotations covering safety and an output schema covering return values, the description is complete. It explains the selectors, the run-store root override, and routes to the correct sibling when the use case differs. An agent has everything needed to invoke it correctly.

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 documents each parameter and their mutual exclusivity. The description reiterates the selector concept and runsDir override but adds no information beyond what the schema provides. Baseline 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 a specific verb and resource: 'Read the full structured execution dossier for one MartinLoop run' and enumerates the contents (attempts, events, artifacts, verification, integrity, cost, discovery surfaces). It also names siblings it is not ('use martin_get_run' and 'use martin_dossier'), clearly differentiating this tool from alternatives.

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?

Explicit when-to-use and when-not-to-use guidance is provided: 'Use for comprehensive evidence review' and 'Do not use for a compact state check; use martin_get_run, or use martin_dossier when formatted sharing output is required.' This gives the agent a decision rule, not just 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?

The annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds a useful boundary beyond that: it returns only a compact budget snapshot for one run and not full events/artifacts, and clarifies that runsDir only changes the run-store root. No behavioral contradiction with the annotations.

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 with no filler: purpose first, selector rule second, usage boundary third. Every sentence earns its place and the most important operational constraint ('exactly one selector') is stated prominently.

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 output schema, annotations, and fully covered parameters, the description covers the remaining operational rules: exactly one selector, what each selector points to, runsDir's scoped effect, and when to route to siblings. There is no critical missing information an agent would need to invoke it correctly.

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 the baseline is 3, but the description adds semantic meaning by mapping each selector to its intended source: 'inline record' for loopJson, 'saved record' for file, 'run-store ID' for loopId, and 'newest run' for latest. It also explains the non-selector role of runsDir, which helps an agent avoid treating it as a fifth mutually exclusive option.

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 names a specific verb ('Read') and resource ('current budget, cost, remaining limits, and stop pressure for one MartinLoop run'), and proactively distinguishes from siblings by saying it is not for full events/artifacts (martin_get_run or martin_run_dossier). It is immediately clear what this tool does and what it is not.

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 gives a compact use case ('Use for a compact budget check') and explicit exclusions with named alternatives ('Do not use for full events or artifacts; use martin_get_run or martin_run_dossier instead'). The selector rule ('Provide exactly one selector...') also tells the agent how to choose an input path.

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?

The description labels the operation 'read-only', which aligns with readOnlyHint and idempotentHint, and adds non-obvious selection behavior by saying only runs 'that need attention' are prioritized. It also provides the workflow cue to inspect the selected run or dossier before retrying, which is useful context beyond the annotations.

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 short sentences cover purpose, usage triggers, and next step with no filler. The key selection signal, that this is for attention-worthy runs and not brand-new objectives, is front-loaded.

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?

With readOnly and idempotent annotations, a fully described 8-parameter schema, and an output schema present, the description supplies what structured fields cannot: selection rationale and follow-up workflow. It is complete enough for an agent to decide when to invoke and what to do next.

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% and each parameter has a meaningful description, including default behavior for limit and the includeHealthy filter. The tool description itself adds no parameter-level detail, which is acceptable given the high-coverage baseline.

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 states a specific resource ('saved Martin runs'), the action ('prioritization'), and the filtering criterion ('that need attention'). This clearly positions it against siblings like martin_list_runs or martin_status, which imply plain listing or status checks rather than attention-based triage.

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 gives concrete positive triggers ('prior attempt failed', 'asks what to fix next', 'resumes an interrupted session') and an explicit exclusion ('Do not use for a brand-new objective with no relevant run history'). It also names the next action, so an agent knows both when to call and what to do afterward.

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