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

Annotations only establish the safety profile (not read-only, closed-world, non-destructive); the description adds genuinely useful behavioral context: the required worker-quiescence precondition, the dispatchStopped attestation, and the explicit non-effect (does not authorize a new generation). It stops short of saying what actually happens to the held reservation (released vs. written off) or whether the call is idempotent.

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 hard precondition is front-loaded and every sentence carries information: precondition, procedure, effect, and scope limit. It is dense but not padded; a small amount of restructuring would improve scannability.

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 mutation tool with no output schema and only minimal annotations, the definition is adequate on preconditions but leaves key gaps: what the settlement does to the reservation, what the response contains, and behavior on a failed attestation. An agent can sequence the call but cannot predict its effect.

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 description must carry all parameter meaning. It explicitly covers dispatchStopped:true and implicitly maps reviewer/approvalText to 'Record the researcher approval', but says nothing about actualUsd (is it the verified billed amount, a delta, or a replacement?), projectId, or operationId. Partial compensation only.

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 name plus description convey a specific verb+resource: reconcile/settle a budget reservation stranded by a hard process exit, only after billing is verified. 'Settle an uncertain operation' is somewhat abstract on its own, but the stranded-reservation framing and the contrast with sibling project_budget make the intent readable without opening the schema.

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 states a hard precondition ('ONLY after the researcher verifies actual provider billing'), a sequencing requirement (stop every server/worker that could still dispatch it, then attest dispatchStopped:true), and a scope limit ('Does not authorize another generation request'). This is explicit when-to-use and when-not guidance with the ordering spelled out.

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 declare destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally, and the description usefully enumerates the view's contents. However, readOnlyHint=false is left unexplained for what reads like a display operation, and no permissions, side effects, or scoping behavior are disclosed. Adds content context but no behavioral context beyond an already-sufficient annotation set.

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?

One front-loaded sentence enumerating the returned contents, with no filler, no hedging, and no repetition of the tool name. Every clause carries information.

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 one-parameter, no-output-schema tool, the content list gives the agent a reasonable picture of what comes back. It still omits what projectId scopes, whether the view is per-project or cross-project, and how it relates to the other project/review siblings, leaving gaps an agent would want filled before calling it.

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 single parameter projectId has 0% schema description coverage and is never mentioned in the description, so nothing explains that it selects which case is shown or what its format/constraints are. With one undocumented parameter and no compensating text, this falls below the baseline given to zero-parameter tools.

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 pairs a specific verb ('Show') with a named resource (the case overview) and enumerates exactly which artifacts are displayed: saved case question, accepted findings, review queue, contradictions, next steps. That is far more informative than a restatement of the name. It stops short of distinguishing this aggregate view from overlapping siblings like project_context, project_dossier, or project_export.

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 when-to-use guidance, no prerequisites, and no mention of alternatives, despite several siblings (project_context, project_dossier, review_record, project_export) that plausibly cover adjacent ground. The agent must infer from the tool name alone when this view is the right one to call.

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 the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds real behavioral context beyond that: contradictory evidence 'remains visible' and distinctions must be preserved, implying non-destructive, additive proposal semantics. It omits what state a proposed claim lands in and whether idempotency applies.

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, front-loaded sentences with the purpose first and no filler. Slightly telegraphic, but every sentence carries 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?

For a seven-parameter mutation tool with no output schema and zero schema documentation, this is thin. Nothing explains evidence stance semantics, idempotencyKey behavior, or what a caller gets back after proposing, leaving key invocation details to inference.

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 schema names seven parameters with no documentation and the description must compensate, but it does not. 'Cited' vaguely implies the evidence array and 'dates' vaguely implies eventDate, but no parameter is mapped, explained, or given format guidance.

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 a specific verb and resource: 'Propose a cited historical claim.' This clearly distinguishes it from siblings like entity_propose and identity_merge_propose by naming the artifact (a cited claim). It stops short of explicitly naming which sibling to prefer.

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 when-to-use or when-not-to-use guidance, and no alternative tool is named. 'Keep ownership, occupancy, permits and inferred dates distinct' is content-categorization advice, not a condition for selecting this tool over 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=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds real semantic value by clarifying no dedup/merge occurs for same-named entities, but it says nothing about idempotency behavior, permissions, or what the response contains.

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 short sentences, front-loaded with the action and resource, followed by a single high-value caveat. No 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 mutation tool with 3 required params, no output schema, and 0% schema description coverage, the description covers purpose and one semantic caveat but leaves idempotencyKey, projectId scoping, and the relationship to identity_merge_propose unexplained.

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 there are 4 parameters. The description only echoes the entity-type values already in the type enum and says nothing about name, projectId, or idempotencyKey—the latter being a semantically important flag for a create operation that the description never explains.

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 a specific verb ('Create') and resource ('a distinct person, place, organization or event candidate'), so the agent knows it produces a new entity candidate. It does not name a sibling (e.g., identity_merge_propose) to differentiate, but the second sentence sharpens the scope meaningfully.

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?

'Same names do not imply the same identity' implies you should propose separate candidates rather than assuming a merge, which is useful implied usage. However, no explicit when-to-use/when-not guidance and no named alternative to identity_merge_propose is given.

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 declare readOnlyHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered structurally. The description adds only a vague epistemic caveat rather than any behavioral trait: nothing about scoring, ranking, index freshness, or result fields, though output schema is absent.

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?

It is short and front-loaded with the verb+resource, so it is not bloated. But the second sentence is cryptic and consumes space without earning it, leaving the definition under-specified rather than concise.

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?

A search tool with no output schema, 0% parameter coverage, and two required inputs requires far more than two sentences. There is no explanation of results, ranking, pagination, or how it relates to the many sibling search tools.

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 adds zero meaning to the three parameters (projectId, query, limit). The agent gets no indication of query syntax (natural language? keywords?), limit default, or projectId semantics.

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 says 'Search the project passage index', which is close to restating the name evidence_search. It never clarifies what a 'passage' is, what corpus is searched, or how it differs from siblings like source_search, map_search, or case_overview.

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?

Only the cryptic phrase 'Retrieval relevance is not researcher acceptance' is offered as guidance. There is no explicit when-to-use, no alternatives named (source_search/map_search exist), and no prerequisites such as whether a project must be in a particular state.

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 declare a non-read-only, non-destructive, closed-world operation, and the description adds real context beyond them: both original entities are retained and a researcher review step is required, telling the agent this is a reversible, human-gated proposal rather than a hard merge. It does not mention permissions or idempotency behavior, but the key mutation semantics are disclosed.

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 tight sentences with no filler, and the core action is front-loaded before the behavioral caveat. 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?

For a mutation tool with annotations and no output schema, the description covers the essential behavioral traits (retains originals, needs review) but leaves all five parameters undocumented at 0% coverage. Adequate on behavior, thin on inputs.

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% across 5 parameters (entityIds, rationale, evidence with supporting/opposing stances, projectId, idempotencyKey). The description explains none of them, so an agent gets no help on argument meaning, minimum entity count, evidence structure, or idempotency usage.

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 a specific verb (propose) and resource (identity merge between distinct entities), so an agent can tell it creates a merge proposal rather than performing a merge. It does not, however, explicitly contrast itself with nearby proposal siblings like entity_propose or claim_propose.

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 explicit when-to-use, when-not-to-use, or alternative routing. The agent must infer that this is the right tool for asserting two entities are the same identity, and gets no guidance on how it relates to review_record or the other *_propose 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral caveat, that chat attachments are not assumed accessible, but says nothing about the folder's location, filtering, or what happens when it is empty.

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 short sentences with no filler, and the core action (listing files in the import folder) is front-loaded ahead of the caveat.

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, zero-parameter listing tool with no output schema, the description covers what is listed and what is excluded, which is close to sufficient. A brief note on where the import folder comes from or what enabling it requires would close the remaining 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter information is needed or missing.

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 a specific verb and resource: listing regular files in the import folder, and scopes it by excluding chat attachments. It is clear what the tool returns, though it does not distinguish itself by name from siblings like source_import or source_search.

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?

Usage is only implied: the exclusion of chat attachments hints at a precondition, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling tools (e.g. source_import, source_search).

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 declare readOnlyHint=false, openWorldHint=false, and destructiveHint=false, but the description uses the read verb 'retrieve' and never explains why a retrieval is not read-only (caching, logging, generation?, nor does it describe side effects or return behavior. The coordinate caveat is domain context, not behavioral disclosure.

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 tight sentences with the primary action front-loaded, and the caveat placed second. No filler, though the caveat could be integrated more economically.

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 0% schema coverage, no output schema, and annotations that conflict with the 'retrieve' framing, the description should clarify parameters and the non-read-only nature. It leaves an agent unable to confidently construct the call.

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% for four parameters, so the description carries the full burden. 'Around a candidate' loosely hints at radiusMeters and the candidate identifiers, but projectId, runId, sourceId, and the radius range (25-1000m) are left entirely unexplained.

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 a specific verb (retrieve) and resource (map excerpt) scoped to a researcher-selected candidate, which is clearer than most siblings. However, it does not distinguish itself from the sibling map_search, which an agent could easily confuse it with.

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 when-to-use guidance, prerequisites, or pointer to alternatives such as map_search are given. The second sentence is a domain caveat about coordinates rather than selection 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=false and destructiveHint=false, so the agent knows this is a non-destructive mutation; the description's 'Import' verb is consistent with that. The one genuinely additive behavioral fact is the scope exclusion that it does not georeference historical parcels, but nothing is said about side effects, overwrite behavior, or what is created.

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 terse sentences with no filler and the action front-loaded. But the brevity is under-specification rather than disciplined conciseness given the five undocumented parameters and absence of any guidance.

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 five-parameter mutating tool with 0% schema coverage, no output schema, and only partial annotations, the description omits nearly everything an agent needs: parameter meaning, pagination/return behavior, and prerequisites. It is not complete enough to invoke 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 0% across five parameters (projectId, runId, bbox, width, height). The description explains none of them — not the bbox coordinate order, not the relationship between projectId and runId — so an agent must guess at invocation inputs.

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 and subject ('Import a cited excerpt from the 1880 DC Sanborn service') and even scopes it negatively. However, the tool name 'map_search' implies a search/read operation while the description describes an import, creating a mismatch, and it gives no differentiation from siblings like source_import or import_inbox that plausibly do overlapping work.

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 statement of when to use this tool versus alternatives such as source_import, import_inbox, or map_candidate. The only guidance is a negative scope note ('does not georeference'), which does not tell the agent when this tool is the right choice.

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=false and destructiveHint=false, so the mutation profile is partly covered. The description adds genuinely non-redundant context: costs are reserved before dispatch and uncertain operations are never retried automatically, which matters for a cost-bearing, non-idempotent operation.

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 that are reasonably front-loaded, but the opening clause 'Extract embedded text first, otherwise...' is syntactically awkward and forces re-reading to parse the intended conditional. Little waste, but the structure slightly impedes comprehension.

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?

No output schema exists, so return values need not be explained, and the cost/retry behavior is a useful addition. However, for a mutating tool with four required, zero-coverage parameters, the description omits the meaning of the identifiers required to invoke it and the side effects applied to a page.

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 0% and the description only indirectly alludes to the 'page' parameter ('process one page'). projectId, runId, and sourceId are entirely undocumented in both schema and description, so the description fails to compensate for the coverage gap.

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 a specific verb and resource: process one page with the configured model provider, with a pre-step of extracting embedded text. It implies a distinction from the plural sibling pages_process by emphasizing 'one page', but never names or explicitly contrasts the sibling.

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 phrase 'Extract embedded text first, otherwise process one page' implies a conditional workflow, but no when-to-use guidance relative to pages_process or page_retry is given. The agent must infer the routing from the plural sibling name rather than from explicit instruction.

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 assert readOnlyHint=false, so it's a write action, but the description supplies the actual preconditions: prior approval text and billing settlement, which are the real gating behaviors. It doesn't disclose idempotency or failure mode, keeping it short of 5.

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 tight sentences, prerequisite first, alternative last, no 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?

Covers the crucial 'when' and gating behavior, but with six undocumented parameters and no output schema, an agent still lacks the parameter semantics needed to invoke it correctly. The description should at least map approvalText and reviewer.

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 0% with six required parameters, so the description carries the burden. It references approval implicitly through 'researcher approval' but never explains reviewer, approvalText, runId, or page semantics. A user could not fill these correctly from the description 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?

States a specific verb (authorize one new attempt) and resource (a failed page), with clear scope of 'one new attempt'. Sibling direction is present ('use page_process instead') but doesn't distinguish from processing_unblock, a plausible alternative.

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?

Gives explicit prerequisites (explicit researcher approval, settled prior billing) and an explicit exclusion with the correct alternative for saved results (page_process). This is unusually thorough 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 signal readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral traits beyond annotations: failure semantics ('Stops on the first failure or limit'), resumability ('Completed pages survive interruption'), and billing caution ('Never retries uncertain billing').

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 short sentences with no filler, and the core action is front-loaded. Each sentence adds a distinct behavioral clause rather than repeating structured fields.

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 batch mutation tool with four required, undocumented parameters, the description covers behavioral side effects well but omits usage guidance and parameter semantics. The absence of an output schema is acceptable since return values aren't needed, but the definition still leaves selection and invocation gaps.

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 description must compensate. It only indirectly references the pages parameter ('one to ten selected pages') and says nothing about projectId, runId, or sourceId, leaving most parameter meaning undocumented.

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 a specific verb 'Process' and resource 'pages' with scope 'one to ten selected pages sequentially'. However, it does not explicitly distinguish itself from the sibling page_process (singular), leaving that differentiation to inference.

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 only states the operation and its failure semantics, providing no explicit when-to-use or when-not-to-use guidance. Alternatives such as page_process or processing_queue are not mentioned, so the agent must infer when to batch.

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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is partly covered. The description adds that the content is researcher-supplied and must attach to an existing preserved source, but says nothing about idempotency behavior, whether re-submission duplicates passages, or any permission requirements. It meets the minimum but adds little 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?

A single front-loaded sentence with no padding. Slight deduction because 'honest citation locator' is flowery and vague where a concrete term would be more useful to an agent.

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 mutation tool with a nested-object parameter, 0% schema description coverage, no output schema, and a neighboring passage_correct sibling, the description is too thin. It omits how the passage differs from a correction, whether the add is idempotent, and what the locator sub-fields mean.

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% across 5 parameters, so the description carries the full burden. It loosely gestures at text ('transcription or observation'), sourceId ('preserved source'), and locator ('honest citation locator'), but never explains the nested locator structure (page, quote, region, precision enum) and entirely omits projectId and idempotencyKey. Substantial gaps remain.

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 ('Record') and resource ('a researcher-supplied transcription or observation against a preserved source'), which is more informative than the name alone. However, it does not distinguish itself from the sibling passage_correct, so the agent cannot tell from the text alone why to use this tool rather than the correction variant.

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 explicit when-to-use, when-not-to-use, or named alternative guidance. The phrase 'researcher-supplied' implies this is for manual entry of new content, but the agent must infer that this is for creating rather than correcting passages. No prerequisites or sequencing information is given.

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=false and destructiveHint=false, so safety is partly covered. The description still adds real value beyond them: it clarifies the operation is additive (original is not deleted) and discloses the side effect that affected conclusions are invalidated and must be reviewed again.

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 short sentences, both front-loaded with the most decision-relevant facts (the additive nature of the write, then the review consequence). No 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 five-required-parameter mutation tool with no output schema and zero parameter documentation, the description is too thin. It does not say what is returned, whether a new passage identifier is produced, or how the corrected passage relates to the original in downstream review workflows.

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% across five required parameters, so the description must carry the burden and does not. It hints that 'text' is the corrected transcription but says nothing about reason, reviewer, passageId, or projectId, leaving most parameters semantically opaque.

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 a specific verb and resource: create a corrected transcription while preserving the original. That is clearer than a bare name restatement, but it never contrasts itself with the sibling passage_add, which plausibly covers similar ground.

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?

Usage is implied rather than stated: an agent can infer this is for fixing an existing passage's transcription, and the note that affected conclusions need re-review signals the downstream context. No explicit when-to-use versus when-not-to-use guidance or named alternative is given.

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 real behavioral context not present in annotations: it does not dispatch model requests, so it is cheap/side-effect-free from a model-cost perspective. However, the annotation readOnlyHint=false sits awkwardly with a 'Show' verb, and no return shape, scope, or pagination behavior is disclosed.

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 tight sentence with the key scope qualifier front-loaded and no filler. Nothing is wasted, though it is arguably under-specified rather than maximally informative.

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 low-complexity query tool this covers the gist, but with no output schema the description should say more about what 'progress' contains (counts, statuses, per-source breakdown) and the parameters are entirely unexplained. It is minimally adequate rather than 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?

Schema description coverage is 0% for two parameters (projectId required, sourceId optional), and the description supplies no meaning for either. It does not explain what projectId vs sourceId select or that sourceId narrows the view, so the description fails to compensate for the coverage gap.

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 a specific verb+resource ('Show saved page-processing progress') and adds a distinguishing clause ('without dispatching model requests') that separates it from the processing siblings like page_process/pages_process. It is clear what the tool reports, though it does not name the alternative tool outright.

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?

Usage is only implied: the 'without dispatching model requests' clause hints that this is a status-check rather than a trigger, but no explicit when-to-use/when-not or named alternative (e.g. page_process, processing_unblock) is given. An agent can infer intent but must guess at the boundary.

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 only give safety hints (readOnlyHint=false, destructiveHint=false, openWorldHint=false); the description adds real behavioral context beyond them – an approval/auth requirement (researcher review) and a rate/cost constraint ('Budget checks still apply'). It does not disclose what state change the acknowledgement produces, keeping it short of a 5.

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

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

Two compact sentences with the critical precondition front-loaded ('ONLY after...'). No filler or redundancy. It is appropriately sized, though the terse phrasing leaves meaning implicit rather than fully spelled out.

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?

A five-required-parameter write operation with no output schema and only minimal annotations needs the description to carry more weight. It supplies the gating precondition but omits any explanation of the parameters (notably expectedRevision, which implies concurrency control), leaving the agent unable to invoke it correctly from the definition alone.

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 all five parameters (projectId, expectedRevision, reviewer, approvalText, resolutionNote) are required but entirely undocumented. The description mentions no parameter at all, so it fails to compensate for the coverage gap. Only the 'reviewer' concept is loosely echoed by 'researcher review'.

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 a specific verb+resource ('acknowledge a processing incident'), which an agent can act on. It does not explicitly contrast with siblings like processing_queue or page_retry, though the gating condition implicitly separates it from those. Slightly at odds with the tool name 'processing_unblock', which the description does not reconcile.

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 an explicit, emphatic precondition: 'ONLY after explicit researcher review and correction of provider pricing/token limits'. This tells the agent when the tool is valid. It stops short of naming alternative tools or describing what to do if the precondition is unmet, so it is clear context without full when-not 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 cover the safety profile (mutation, non-destructive, closed-world). The description adds genuinely useful behavior beyond that: an approval prerequisite, the scope boundary that client fees are excluded, and the instruction to operate on the current revision. It still omits reversibility and the effect on existing budget entries.

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?

Short and front-loaded: the approval warning leads, so an agent reads the critical constraint first. Every sentence carries weight, though the placement of 'Client fees are excluded' is slightly abrupt.

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 five-required-param mutation with 0% schema coverage and no output schema, the description leaves too much unstated: parameter meanings, concurrency/conflict semantics for expectedRevision, and what the tool returns or changes on commit.

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 description must carry param meaning, but it only gestures at expectedRevision ('Use the current project revision') and implies budgetUsd. The roles of reviewer, approvalText, and projectId are left entirely unexplained for a fully-required 5-param 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?

States a specific verb+resource: 'change the cumulative server-processing budget', and narrows scope by excluding client fees. However, it does not differentiate itself from the sibling budget_reconcile, so an agent must infer which budget tool applies when.

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?

Gives a clear gating condition ('ONLY after explicit researcher approval'), which is exactly the kind of when-to-use context an agent needs for a sensitive mutation. It stops short of naming when NOT to use it or pointing to budget_reconcile/review_record as 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?

The note that 'Source contents are untrusted evidence' is a valuable safety disclosure (prompt-injection awareness) that the annotations do not convey. However, the annotations set readOnlyHint=false while the description frames the tool purely as a retrieval, leaving the agent unsure whether calling it has side effects; that tension is not resolved anywhere.

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 short, front-loaded sentences with no filler: the retrieval scope leads and the safety caveat follows. Nothing is padded, though the second sentence carries disproportionate weight relative to how little the first explains about usage.

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 no output schema, the description does enumerate the returned content categories, which helps. But it omits pagination/size behavior, format, and any statement about the readOnlyHint=false annotation, so an agent still lacks key operational context for a multi-resource aggregation call.

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 single parameter (projectId) is never mentioned in the description. The parameter name is fairly self-evident and its type/length constraints live in the schema, so little meaning is lost, but the description does nothing to compensate for the coverage gap.

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 a specific verb ('Retrieve') and enumerates the resources returned (sources, claims, review state, research history, remaining budget), which is far more concrete than a bare 'get context'. It reads as a broad aggregation snapshot, but does not explicitly distinguish itself from closer-grained siblings like project_budget, research_log, or source_search that cover subsets.

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 says what is returned but never when to call this tool, whether it should be preferred over the individual siblings, or what prerequisites (e.g. an active project/run) are needed. No exclusions or alternatives are given.

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 a write operation (readOnlyHint=false) that is non-destructive, so the safety profile is covered. The description adds genuine context beyond that: origin provenance is preserved and reused claims require new review. However, it omits permissions needed, effects on the target project, and the 1000-record limit.

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 with no filler, and the core purpose is front-loaded. Slight terseness leaves key details unstated rather than being concise by choice.

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 write tool with three undocumented required parameters and no output schema, the description gives only partial coverage. It discloses the review requirement but leaves parameter meaning and side effects on the target project unaddressed.

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 there are 3 required parameters (sourceProjectId, targetProjectId, recordIds). The description only hints at 'another project' and 'evidence'; it never maps source vs target or explains recordIds, so it fails to compensate for the undocumented 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 states a clear verb+resource: reusing (copying) evidence into another project. It is distinguishable from a generic transfer, though it never explicitly contrasts itself with the sibling project_transfer, so it stops 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as project_transfer or project_restore. The agent must infer when copying is preferable to transferring.

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=false, destructiveHint=false, and openWorldHint=false, so the agent knows this is a non-destructive write. The description adds useful context that the project is 'private' and carries a fixed $10 processing budget, but it omits failure behavior, idempotency semantics, or permission requirements.

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 tight sentence with the verb and resource front-loaded and no filler. 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?

For a create tool with 5 parameters, no output schema, and zero schema documentation, this one-line description is too thin. An agent cannot know what the parameters mean, what the call returns, or how it relates to the surrounding project lifecycle tools.

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% across 5 parameters, so the description carries the full burden, yet it explains none of them. Non-obvious parameters such as knownInformation, sourceConstraints, and idempotencyKey get no clarification, and even required address/question are only indirectly implied.

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 a specific verb and resource ('Create a private property-history project') and adds a scoping detail (the $10 server-processing budget) that clarifies what kind of project results. It is clear on its own but does not explicitly distinguish itself from siblings like project_copy, project_restore, or project_transfer.

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 statement of when to use this tool versus the many project_* alternatives, nor any prerequisites. An agent must infer that this is the entry point for starting a new project rather than duplicating or restoring one.

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 openWorldHint=false, so the safety profile is covered. The description adds value by disclosing how the output is organized (it separates approved conclusions from proposals and flags contradictions), which is genuine behavioral context beyond the annotations, but it says nothing about permissions, size, or whether it generates fresh content.

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; the verb and resource lead and the section enumeration follows. 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?

For a one-parameter, read-only tool with safety already covered by annotations and no output schema, the description's content breakdown effectively summarizes what is returned. It is nearly complete, missing only scoping/format details.

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 schema does not document projectId. The description does not compensate, but the single required parameter is a self-evident project identifier with obvious semantics, so the gap is minor rather than severe.

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?

Specific verb ('Return') plus a well-defined resource ('readable dossier') and an enumeration of its content sections (approved conclusions, proposals, contradictions, sources, research gaps). It is clear what the tool produces, but it never differentiates itself from overlapping siblings such as case_overview or project_context.

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 statement of when to reach for this tool versus project_context, case_overview, or project_export, and no prerequisites or exclusions. Usage must be entirely inferred from the name and purpose.

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 establish it is a non-read-only, non-destructive, non-open-world write operation. The description adds that output goes to the configured local export directory, reinforcing the local scope, but omits whether existing files are overwritten, how files are named, or what the call returns.

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; the verb and destination lead the statement. It is efficient, if slightly sparse given 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?

For a write tool with no output schema and no annotation detail, an agent still cannot tell what files are produced, whether prior exports are overwritten, or what a backup format implies. Key operational 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 0%, so the description must carry parameter meaning. It lists the format values, but those merely restate the schema enum, and it says nothing about projectId's semantics or constraints (min/max length, required).

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 a specific verb (Write) plus the resource formats and the destination directory, so the operation is unambiguous. It distinguishes itself from siblings like project_transfer, project_copy and project_restore, though it does not explicitly name those 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?

There is no statement of when to choose this over the many closely related siblings (project_transfer, project_copy, project_dossier), nor any prerequisites such as configured export directory requirements. Usage must be inferred entirely 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=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds the scoping detail that results are limited to 'this installation's' projects, which is useful, but says nothing about ordering, completeness, or size of the result set.

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 short sentence with the action front-loaded and the motivating purpose trailing it. No filler, no repetition of the tool name.

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 read tool with annotations covering safety, this is nearly complete; no output schema exists, but a one-line hint about what a project entry contains (or whether pagination applies) would have removed the last ambiguity.

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 takes zero parameters, so per the baseline there is no parameter semantics burden on the description. Nothing is missing on this axis.

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 gives a specific verb and resource ('List this installation's research projects'), which is clearly distinct from write-oriented siblings like project_create, project_copy, and project_restore. It stops short of naming any sibling explicitly, but the read-only listing intent is 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?

'so earlier work can be resumed' implies the usage context — consult this before resuming prior research — but it never states when-not to use it or points to alternatives such as project_context or project_dossier. Usage is inferable 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that: the non-overwriting guarantee and the size-based CLI fallback. It omits auth requirements, failure/idempotency behavior, and what operationId controls.

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 tight sentences with the core action front-loaded and the constraint/fallback following. No filler, though it is quite terse relative to the 0%-documented 3-parameter 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?

A mutating restore tool with no output schema, and the description covers the key non-overwrite guarantee and a CLI fallback. It still leaves operationId's role, failure semantics, and the expected bundle shape unexplained for an agent to act confidently.

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 description must carry the load, but it only indirectly hints at 'bundle' and 'targetProjectId' (fresh project). The third required parameter, operationId, is never explained, and neither is the bundle's expected format beyond 'JSON'.

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 a specific verb and resource ('Restore a complete portable JSON bundle into a fresh project'), so the action is unambiguous. However, it does not differentiate itself from plausible siblings such as project_copy, project_transfer, or source_import, leaving the agent to infer the boundary.

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 a clear precondition ('into a fresh project', 'Never overwrites an existing project') and an explicit alternative for a specific case ('Use the CLI for large backup files'). It stops short of naming sibling tools like project_transfer or project_copy as the alternative for those scenarios.

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=false) cover the safety profile, and the description adds substantial context: originals remain local, destination must be fresh, processing must be halted, and approval is mandatory. It does not disclose failure/atomicity or idempotency behavior around operationId, which would complete the picture.

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 critical precondition is front-loaded ('ONLY after explicit researcher approval'), and every sentence carries operational weight. A couple of clauses are densely packed and run together, but there is no 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 complex, no-output-schema, 0%-coverage mutation tool this covers the prerequisite and safety story well. It still omits semantics for several required parameters (operationId, expectedRevision) and any note on outcome or failure handling, so an agent can trigger it but cannot fully reason about the call contract.

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% across 7 parameters, so the description must carry the burden. It clarifies dispatchersStopped (stop processing in both clients before attesting) and implies reviewer/approvalText via the approval requirement, but leaves projectId, targetProjectId, operationId, and expectedRevision (likely a concurrency token) entirely unexplained.

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 a specific verb and resource (transfer a local case) plus the destination (configured Astra database) and scope (preserving history and budget, originals stay local). It is clear, but it does not explicitly differentiate itself from sibling tools like project_copy, project_restore, or transfer_recover, leaving the agent to infer which transfer variant applies.

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?

Gives strong preconditions: only after explicit researcher approval, stop page processing in both clients before attesting dispatchersStopped, and the destination must be fresh. However, it never names the sister tools that handle the recovery/status follow-ups (transfer_recover, transfer_status), so the agent gets 'when' but not the surrounding 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, covering the safety profile, but the description adds almost no behavioral context: it doesn't say the entry is preserved/immutable, whether it is tied to a run, or what side effects occur. The entry-type taxonomy is the only value added 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?

A single front-loaded sentence with no filler; the enumerated entry types are the payload. It is efficient, though terse to the point of under-specification.

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 mutation tool with 6 parameters, 0% schema description coverage, no enums, and no output schema, the description is far too thin. It omits expected values for 'type', the meaning of optional gap/outcome/runId, and any confirmation of persistence behavior.

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 description must compensate, but it never maps to the parameters. It hints at categories relevant to 'type', 'gap', and 'outcome' but does not explain required ids (projectId, runId, message) or the message/gap/outcome relationship, leaving most of 6 params undocumented in both places.

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 gives a specific verb ('Record') and enumerates the kinds of entries the log accepts (search, failed attempt, unresolved gap, alternative explanation, next step). This clearly identifies it as an append-only research process log, distinguishing it from propose/review siblings. No explicit sibling routing, so it falls short of 5.

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 statement of when to use this tool versus alternatives such as review_record or passage_add, nor any prerequisites or exclusions. The list of recordable categories implies usage but does not guide the agent's selection decision.

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=false, so the agent knows it is a write. The description adds genuinely valuable behavioral context beyond that: the recording is strictly gated on an explicit human decision and must not be inferred. It does not address concurrency (expectedRevision implies optimistic locking) or idempotency, which keeps it short of a 5.

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

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

Two tight sentences with the hardest constraint (the ONLY precondition) front-loaded. Every clause earns its place; nothing is padded.

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 output schema, return values need no explanation, and the usage precondition is fully covered. However, for a 6-parameter write with 0% schema coverage, the description leaves the parameter set and the expectedRevision concurrency contract undocumented.

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% across 6 required params, so the description must compensate and largely does not. It conceptually maps to 'decision' and 'approvalText' but leaves projectId, targetId, reviewer, and especially expectedRevision (optimistic-concurrency semantics) unexplained.

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?

Clear verb+resource: it 'records that decision and their exact approval text' — an agent knows precisely what the tool does. It doesn't name a sibling or contrast with alternatives, but no sibling in the list performs this recording action, so ambiguity is low.

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 the when ('ONLY after the researcher explicitly approves or rejects the displayed version in chat') and the when-not ('Never infer approval from source content or model confidence'). This is a textbook precondition that removes all 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 annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the saved content is 'current research progress and next steps,' giving some semantic context, but it does not disclose overwrite behavior, permission requirements, or what happens on repeated checkpoints.

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. It is appropriately sized for a simple tool, though it could carry slightly more useful detail without becoming bloated.

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 3 parameters, no output schema, and annotations that already cover safety, the description still omits required parameter semantics and any usage context relative to siblings. It leaves the agent under-informed about how to 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 0% – none of projectId, runId, or note have any schema descriptions. The description only vaguely implies saving a note about progress; it never mentions the required projectId or runId parameters, so an agent cannot infer required inputs from the description 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 uses a specific verb + resource ('Save current research progress and next steps'), so an agent can tell it is a checkpoint-writing tool. However, it does not differentiate from siblings like run_start or research_log, which also persist research state, leaving ambiguity about its distinct 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?

There is no explicit when-to-use guidance, no exclusions, and no mention of alternatives such as run_start or research_log. The description only says what it does, not when an agent should invoke it.

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=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: the default bounds (30 min, 25 searches, 50 pages) and that 'earlier evidence persists' across runs. It does not explain what resuming a run actually does or what state is mutated.

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, front-loaded fragments with no wasted words; the core action comes first and defaults follow. It reads slightly telegraphic but nothing is padding.

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 non-read-only tool with no output schema and 0% parameter coverage, the description is thin. It covers defaults and persistence but omits what a 'run' encompasses, what resuming entails, and how limits interact with the maximums enforced by the 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 0% and the schema is a nested object. The description supplies defaults for the three limits fields, which partially compensates, but projectId (required) and idempotencyKey are completely undocumented 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?

States a specific verb pair (start/resume) and resource (bounded run), which is more informative than a bare name restatement. However, 'bounded run' is undefined jargon and the description never contrasts itself with the closely related sibling run_checkpoint, so an agent must infer the 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?

There is no explicit when-to-use, when-not-to-use, or alternative. The phrase 'start or resume' hints at two entry conditions but does not say how to tell whether a run already exists or when run_checkpoint (a sibling) would be preferred.

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 establish that this is a non-destructive, closed-world write. The description adds genuinely non-obvious behavioral facts the annotations lack: no model calls are made and no automatic approval step occurs, plus the data is clearly labeled as fictional. It stops short of saying what state is created or whether resuming mutates an existing sample.

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 short sentences with the action front-loaded and the non-obvious caveats ('no model calls or automatic approvals') packed into a single clause. Every word carries information; no 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 zero-parameter, no-output-schema tool the description covers what it does and the two most surprising behavioral traits. It omits what 'resume' targets and what the created sample contains, but the complexity is low enough that these are minor gaps.

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 takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate. The schema is empty with 100% coverage, so no compensating detail is needed.

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 gives a specific verb pair ('create or resume') and a concrete resource ('clearly labeled fictional sample'), so the agent knows this seeds or reopens sample data. It does not name or contrast against any sibling (e.g., project_create, case_overview), so differentiation is left to inference.

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 statement of when to pick this tool over siblings like project_create or case_overview, nor any prerequisites or conditions. The dual 'create or resume' mode hints at two call contexts but never explains which one applies.

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 non-open-world, and the description adds genuinely non-structured context: it is always callable even with incomplete config, and carries a security constraint ('Never pass credentials through chat'). That safety note is valuable behavioral guidance 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, front-loaded clauses with no filler; the availability guarantee and security constraint each earn their place. The clipped, fragmentary phrasing is slightly harder to parse than a complete sentence would be.

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 status tool with no parameters and no output schema, the description covers availability and a security caveat but never hints at what readiness information is returned or what a caller should do with it. Adequate, but a gap remains since no output schema exists to fill it.

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 takes zero parameters, so schema coverage is vacuously complete and there is nothing for the description to disambiguate. Baseline 4 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 verb 'Check' is present and the object is implied ('readiness'), so an agent can infer this reports setup/configuration status. However, 'readiness' is undefined, and 'learn how to start or resume' muddies whether this returns state, instructions, or both. No sibling (e.g., welcome) is named to differentiate it.

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 states a real availability condition ('Always available, including when research configuration is incomplete'), which is useful context for a setup flow. But it names no alternative and gives no criteria for choosing this over siblings like welcome or project_list.

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 declare readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the mutating, outward-facing nature is already conveyed. The description adds genuinely useful context beyond that: "one" (single item per call) and "Original bytes are preserved" (the content is stored unaltered). It stops short of auth, size, or duplicate/re-import behavior, but the annotations carry much of the load.

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, front-loaded with the core action and input modes before the constraint sentence. Every sentence does some work, with 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?

Ten parameters, 0% schema description coverage, and no output schema mean the description is the only place semantics can live, yet it documents only 3 of 10 inputs. For a mutation tool importing external material into a project/run, this leaves the agent under-informed about rights, attribution, and identity params.

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 0% across 10 parameters, so the description must compensate. It names the three mutually exclusive source inputs (path, url, base64) but leaves rights, attribution, filename, mimeType, projectId, runId, and title entirely undefined, which is a substantial gap for a 10-param tool.

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 a specific verb (import) and resource (source) plus the three accepted input modes: local path, public URL, or base64 file. It is clear what the tool does, but it does not distinguish itself from the similarly-named sibling import_inbox, so the agent must infer which import channel 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?

"Use only material the researcher may process" implies a rights/allowed-material precondition, which is a usage constraint. However, it gives no explicit when-to-use guidance versus siblings like import_inbox or source_read, and no exclusions, leaving selection 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?

Annotations establish readOnlyHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds that no model processing occurs and that output includes coordinate metadata, which is useful context beyond annotations, but omits return format, pagination, or size limits for images/crops.

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 tight sentences, front-loaded with the verb and resource. Every word earns its place, though it could be slightly more informative without bloating.

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 4-parameter read tool with a nested crop object at 0% schema coverage and no output schema, the description is too thin. It should clarify parameter roles, coordinate system, and output shape to be actionable without schema inspection.

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% with 4 parameters (one nested object with 4 sub-fields). The description mentions 'coordinate metadata' and 'crop' only obliquely but does not explain projectId, sourceId, page, or the crop x/y/width/height semantics, leaving a significant gap that the description should fill.

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 a specific verb (Read) and resource (preserved source text or original page/crop image) with coordinate metadata, distinguishing it from processing siblings via 'Performs no model processing'. However, it does not explicitly name which sibling to use for processed/sampled output.

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 when-to-use or when-not-to guidance, no alternatives named. The phrase 'Performs no model processing' implies a distinction from pages_process/page_process but does not tell the agent when to prefer source_read over those 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?

Annotations provide readOnlyHint=false, openWorldHint=true, destructiveHint=false, indicating a non-read-only operation against an open-world source. The description adds the important note that matches are 'candidate evidence, never identity confirmations,' which is valuable behavioral context about result reliability. However, for a tool with annotations already covering safety profile, it doesn't explain why readOnlyHint is false or what mutations occur, leaving a 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?

Two concise sentences that are front-loaded with the core action and followed by an important caveat. 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?

With no output schema, the description should explain return values, but it only notes that matches are candidate evidence. It also doesn't clarify the non-read-only nature despite annotations indicating mutations, leaving the agent without necessary context for a tool with poorly documented parameters.

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% for all three required parameters (projectId, runId, address). The description provides no information about parameter meanings or usage, failing to compensate for the complete lack of schema documentation.

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 a specific verb ('Search') and resource ('DC HistoryQuest public building index'), which is clear. Sibling tools include 'map_search', 'evidence_search', and 'source_import', so 'source_search' is somewhat distinguishable but the description doesn't explicitly differentiate itself from those 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?

No explicit when-to-use guidance or alternatives are provided. The description implies a search context but doesn't specify conditions for selecting this tool over sibling search tools like map_search or evidence_search.

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 non-read-only, non-destructive, closed-world, so the safety profile is covered. The description adds real behavioral context beyond them: the required prior state (process already stopped by the researcher), the warning against inferring shutdown, and the terminal-state restriction on cancellation. It does not say what 'recover' actually performs, so it stops short of 5.

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, front-loaded with the hard precondition and with zero filler. The phrasing 'recover or cancel its lock' is slightly compressed, but nothing is wasted.

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?

No output schema and no parameter documentation, so the description is the only source of semantics. It covers the critical precondition well but omits what a successful recovery does (restart vs. release the lock) and any failure/retry behavior, leaving gaps for a mutating 4-param 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 0% across 4 required params, so the description must compensate. It maps 'recover or cancel' onto the retry/cancel enum and ties the precondition to previousProcessStopped, but projectId and operationId get no mention and the retry-vs-cancel distinction is not spelled out.

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 the specific action ('recover or cancel its lock') on the lock left by the previous transfer process, which is enough to separate it from siblings like transfer_status and project_transfer. The referent of 'its' is inferable but not explicit, keeping it short of a 5.

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?

Gives an explicit precondition ('ONLY after the researcher stops the previous transfer process') plus two exclusions: do not infer shutdown from elapsed time, and a completed transfer cannot be cancelled. This is exactly the when/when-not guidance an agent needs to avoid firing the tool prematurely.

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 openWorldHint=false, so 'Makes no remote requests' largely restates the annotation rather than adding new information. The one genuinely additive detail is that progress is persisted local state, which tells the agent results may be stale relative to remote reality; beyond that there is no disclosure of output shape or failure modes.

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 short sentences with zero filler; the primary purpose is front-loaded and the secondary behavioral note follows. Nothing needs trimming.

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 output schema, the description does the right thing by naming what comes back (progress plus the operation and destination for resuming). The only real hole is the undocumented projectId, which for a one-parameter read tool is a modest 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 0% and the single required projectId parameter carries no description in either the schema or the tool description. The description should have clarified which project's transfer record is read (e.g. the source or destination project), but it says nothing, leaving the caller to guess.

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 a specific verb (read) and resource (persisted transfer progress) plus what the payload contains: the operation and destination needed to resume. That is far more than a restatement of the name, but it never contrasts itself with the adjacent transfer_recover sibling, so an agent must infer the split.

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 phrase 'needed to resume after interruption' implies the situation that calls for this tool, but there is no explicit when-to-use versus transfer_recover/transfer_status-style alternative, no stated prerequisites, and no exclusion of cases where a fresh transfer should be started instead.

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 openWorldHint=false, so the safety profile is covered. The description adds real value beyond them: it states the tool is unconditionally available even in an incomplete configuration, and it imposes a security constraint ('Never pass credentials through chat') that an agent would otherwise not know.

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, no filler, with the availability guarantee and the credential warning front-loaded after the purpose clause. Slightly compressed phrasing in the first sentence ('Check readiness and learn how to start or resume') costs it a point, but nothing is wasted.

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, read-only tool this is close to adequate, but with no output schema the description never indicates what 'readiness' actually returns (a status flag, a checklist, a next-step pointer), which is the main thing an agent needs before calling it. Availability and security are covered; the result shape is not.

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 takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level detail is missing or needed.

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 gives a verb pair ('Check readiness and learn how to start or resume') but the resource is left implicit — readiness of what, and how this differs from sibling tools like setup_status or project_context. 'Welcome' plus 'start or resume' hints at onboarding, but an agent cannot precisely tell what this tool does versus several siblings without probing.

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?

'Always available, including when research configuration is incomplete' gives one genuine usage condition — call it even when setup is broken. However, it names no alternatives and no exclusions, so the agent gets no routing guidance relative to setup_status, project_list, or project_context.

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