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

No annotations are provided, so the description must disclose behavior. The description is straightforward for a read-only listing operation, but it does not mention whether the list is sorted, only top-level files, or if it includes subdirectories. The lack of annotations and minimal behavioral details makes it adequate but not fully transparent.

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

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

The description is a single, concise sentence that immediately conveys the core function. It is front-loaded with the action and resource, with no wasted words. It could arguably be longer to address usage or behavior, but as a concise summary it is excellent.

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

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

The tool is simple with no parameters and has an output schema which likely defines the return structure. The description is sufficient for an agent to understand the basic operation. However, it could benefit from specifying whether it lists all files or only those extracted by the doc_parse tools, and whether the output includes full paths or just filenames. But given its simplicity, the description covers the essential context.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the description does not need to add parameter details. Since there are no parameters, the description is not required to compensate for missing parameter documentation. A baseline of 4 is appropriate for parameter-free 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 uses a specific verb 'List' with a concrete resource 'the extracted .md files' and a specific location 'output directory'. It is clear from the description that the tool returns a list of markdown files, distinguishing it from other doc_* tools that parse or probe URLs, though it does not explicitly name a sibling 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?

The context implies when to use it: after extraction, to see what files are available. However, there is no explicit guidance on when not to use it or alternatives. Given the sibling tools like doc_parse and doc_probe, one might infer it is for post-extraction listing, but the description does not state this.

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

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

With no annotations provided, the description carries the full behavioral burden and does well: it discloses network fetching, file creation, return contents, and the dry_run behavior that avoids network requests. It does not mention failure handling or permission requirements, but the primary side effects are transparent.

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

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

The description is three tight sentences with no filler. It front-loads the primary action, then states the return value, and ends with the dry_run modifier. Every sentence earns its place.

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

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

For a two-parameter tool with an output schema, the description covers the main flow, success outputs, and the special dry-run mode. Minor edge cases like unreachable URLs or existing-file behavior are omitted, but they are not essential for a correct invocation.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It fully explains dry_run ('With dry_run=true, reports what would be fetched without making any network requests') and implies that key identifies the saved receipt, but it never explicitly defines the required key parameter or its expected format.

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 and resource: 'Parse a saved receipt: fetch all its URLs, extract the content, and write a timestamped .md file into the output directory.' This makes the tool's core operation clear and distinguishes it from siblings like doc_parse_url or receipt_show.

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

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

The description clearly frames the tool as being for saved receipts, which gives an agent a clear context for when it is appropriate. It does not explicitly name alternative tools or exclusions, so it stops short of full 5-level 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the non-persistence side effect and the return value (filename and rendered markdown), which is helpful. However, it does not mention other behavioral aspects such as potential network calls, error conditions, or whether it requires any prerequisites like the receipt existing, leaving some gaps.

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

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

The description is two sentences, front-loaded with the primary purpose, and every phrase adds value. It avoids redundancy and delivers the essential information (template usage, non-persistence, return type) without fluff.

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

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

For a two-parameter tool with an output schema, the description covers the key functional points but leaves critical details unspecified. It does not explain what 'key' refers to, does not mention prerequisites (e.g., the receipt must exist), and does not address potential errors or edge cases. While the output schema may cover return details, the lack of parameter definitions is a notable 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%, so the description must compensate. It only hints that 'key' refers to an existing receipt ('using an existing receipt as a template') but does not explicitly define either parameter. 'key' remains ambiguous without further clarification, and 'url' is only inferred from the tool name. This is insufficient given the lack of schema descriptions.

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

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

The description clearly states the tool parses an arbitrary URL using an existing receipt as a template, and explicitly notes it does not persist the result. This specific verb-resource pair and the non-persistence differentiator set it apart from sibling tools like doc_parse or receipt_add, making its purpose unambiguous.

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

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

It provides clear context for when to use the tool: when an existing receipt should serve as the template for selectors/strip_tags/language. It also implicitly advises against using it when persistence is needed by stating 'Does not persist the result as a receipt.' However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a full 5.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the tool fetches the URL statically, reports matching candidate CSS selectors, H2 sections, and sample internal links. It does not mention errors, auth, or rate limits, but for a read-only probe with an output schema this is a reasonable 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?

Three sentences, no filler. The purpose is front-loaded, the second sentence details the behavior, and the third explains how the result is used. Every sentence earns its place.

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

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

The tool is simple: one required string parameter, no nested objects, and an output schema exists, so return values need not be explained. The description covers purpose, behavior, and downstream use. The only notable omission is explicit guidance about when to choose doc_probe_js, though 'statically' already hints at the boundary.

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 only parameter, url, has no schema description (0% coverage). The description compensates by identifying the URL as a documentation page and stating that it is fetched statically. Format constraints are not given, but the single param's role is obvious from the tool name and description.

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

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

The description opens with a specific verb and resource: 'Probe a documentation page to discover its selector structure.' It clearly conveys the tool's unique role among siblings by emphasizing static fetching and selector-oriented output, and even connects the result to creating a receipt.

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

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

The description gives clear context: use this to probe a documentation page and discover its selector structure for making a receipt. The word 'statically' implies choosing this over a JS-rendering alternative, but it does not explicitly name doc_probe_js or state when not to use 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does disclose a meaningful side effect: a saved receipt that 'pre-fills js_render and markdown_passthrough,' plus the headless-Chromium mechanism. But it remains silent on whether the operation is read-only, failure modes (e.g., if Chromium is missing or the page never renders), and network behavior toward external pages, so the disclosure is partial.

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 compact sentences with no filler: the first front-loads the core purpose, the second contrasts with doc_probe and adds the Markdown detection, the third notes the prerequisite and side effect. Each sentence earns its place, though the second sentence packs several ideas together slightly densely.

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?

An output schema exists, so return values need not be explained. The description covers the mechanism, prerequisite, the distinction from doc_probe, and the receipt side effect. It references js_render and markdown_passthrough, which are not among the listed siblings, creating minor ambiguity about those targets, but overall the definition is substantially complete for a single-parameter tool with an output 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%, so the description must compensate. It never explicitly documents the url parameter, though the tool's purpose makes it obvious that url is the documentation page to probe. Since there is only one trivial parameter, the implied meaning mostly suffices, but there is no explicit parameter guidance to offset the 0% schema coverage.

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

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

The description states a specific action ('Probe a JS-rendered documentation page'), a concrete resource, and the mechanism (headless Chromium). It differentiates itself from doc_probe by noting it operates 'over the rendered DOM' and adds a Markdown-copy detector. It relies on the reader already knowing what doc_probe's 'selector report' is, so it's clear but slightly dependent on sibling 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?

The 'Same selector report as doc_probe, but over the rendered DOM' clause communicates the intended use case: dynamic/JS-rendered pages that static probing would miss. It also states a concrete prerequisite ('Requires Playwright Chromium installed'). However, the when-to-use vs. alternatives guidance is implied through the contrast with doc_probe rather than stated as an explicit rule.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavioral traits. It does state the return format and that the tool returns a value, which implies a read-only operation, but it does not explicitly mention absence of side effects, authentication requirements, or reliability characteristics. This is a gap for a tool with zero annotation coverage.

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 wasted words. It efficiently conveys the operation, scope (local and UTC), and format (ISO 8601) without redundancy.

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

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

For a zero-parameter utility with an output schema present, this description is complete. It specifies the output format, and the output schema will handle the exact return structure. Nothing an agent needs to invoke this tool correctly appears to be missing.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline for this dimension is 4. There is no parameter information to add, and the description appropriately avoids inventing semantics for parameters that do not exist.

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 ('return'), a clear resource ('current local and UTC date/time'), and an exact output format ('ISO 8601'). It is distinct from all sibling tools, none of which are date/time related, so an agent can easily identify what this tool does.

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

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

The description implies usage: use this when you need the current date/time in ISO 8601. However, it does not explicitly state when to use it, nor are there any alternative datetime tools among the siblings to differentiate from. The context is clear enough but entirely implied.

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

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

With no annotations, the description carries the behavioral burden and does meaningful work: it discloses upsert semantics, validation-before-write, validation error returns, and the language/code_language fallback behavior. It does not cover permissions or whether omitted fields are cleared on replacement, but the main side effects are visible.

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

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

The description is compact and front-loaded: a one-sentence purpose, a terse required/optional list, and then focused detail on the ambiguous language parameters. Every sentence adds information and there is no filler or repetition.

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

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

For an 11-parameter tool, the description provides the most decision-critical facts: what the tool does, what must be supplied, and how language/code_language interact. It stops short of defining urls, selectors, strip_tags, js_render, and markdown_passthrough, leaving an agent partly reliant on parameter names, though the core invocation path is still clear.

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 for the input schema's silence. It thoroughly explains the two least obvious parameters, language and code_language, including auto-detection and fallback behavior, but the other nine parameters are only named and not semantically defined.

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

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

The description opens with a specific action and resource: 'Create a new receipt (or replace an existing one).' This makes the core purpose clear and distinguishes it from list/show/delete tools, but it does not explicitly contrast itself with the sibling receipt_edit, leaving some add-vs-edit ambiguity.

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 identifies required versus optional parameters and states that validation runs before writing, which gives useful preconditions for calling the tool. However, it never explicitly says when to prefer receipt_add over receipt_edit or when replacement would be inappropriate, so usage guidance is mostly implied.

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 discloses a key behavioral trait: returns false if the key does not exist, which is useful for an agent to know the outcome of a delete attempt. However, with no annotations provided, the description carries the burden of behavioral disclosure; it does not mention whether deletion is permanent, whether it requires confirmation, or any side effects beyond the return value.

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

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

The description is two short sentences with no wasted words. It front-loads the action and resource, then adds the return behavior. Every sentence earns its place.

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

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

For a simple one-parameter delete tool, the description is mostly complete: it states the action, the target, and the return value for a missing key. However, it lacks context about whether the deletion is permanent, any prerequisites (e.g., the receipt must exist), or how the key is structured. The output schema exists but the description doesn't need to explain return values beyond the false case.

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 for the single parameter 'key'. The description says 'by key' but does not explain what a key is, its format, or how to obtain it. Since there is only one parameter and the description names it, it provides minimal but not complete 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 states a specific verb ('delete') and resource ('receipt by key'), and distinguishes itself from siblings like receipt_edit and receipt_add. It clearly identifies the operation and the target, though it doesn't explicitly contrast with sibling tools.

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

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

The description implies usage: call this when you need to delete a receipt by its key. It does not explicitly state when not to use it or mention alternatives, but the sibling context (receipt_edit, receipt_add) makes the intended use reasonably clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It does disclose a meaningful behavior: 'Returns false if the key does not exist.' It also lists allowed fields, implying invalid fields are not permitted. However, it does not address what happens for invalid field names/value types, whether changes persist immediately, or any permission/reversibility concerns.

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

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

The description is compact and front-loaded with the core purpose, then adds the necessary `updates` contract, allowed fields, and failure behavior. Every sentence earns its place, and the allowed-field list is formatted for easy scanning.

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

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

Given that an output schema exists and siblings like receipt_list/receipt_show can supply keys, the description covers the essential call contract: what it patches, which fields are allowed, and what happens if the receipt key is missing. It could be slightly more explicit about `key` being the receipt identifier and how partial updates interact with existing values, but it is adequate for a 2-parameter 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%, so the description must add meaning to both parameters. It thoroughly explains `updates` as a JSON object of field → value and lists the allowed fields. The `key` parameter is only indirectly explained through 'existing receipt' and 'Returns false if the key does not exist,' which is useful but could be more explicit.

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

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

The description opens with a specific verb and resource: 'Patch specific fields of an existing receipt.' It clearly differentiates from sibling tools like receipt_add, receipt_delete, and receipt_show by indicating this is an update/modification operation, and it enumerates the allowed updatable fields.

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 'Patch specific fields of an existing receipt' gives clear context for when to use this tool: modifying an already-created receipt rather than adding, deleting, or reading it. It does not explicitly name alternatives or state when not to use it, but the intended usage is unambiguous.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'List all registered receipts' communicates a read-only enumeration action, and naming the returned fields gives an agent a clear expectation of the output. It does not describe sorting, pagination, or potential empty results, but those are minor for such a simple list 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?

The description is a single front-loaded sentence with no filler. Every element—verb, scope, and return fields—earns its place and directly supports agent decision-making.

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 parameters and an output schema present, the description is complete enough for an agent to invoke the tool correctly. It clearly states that the tool lists all registered receipts and indicates what information is returned. No additional context is necessary for a simple listing operation.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so the baseline is 4. The description reinforces that the tool lists 'all' receipts, implying no filtering is possible or needed. There are no parameter semantics to clarify further.

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 and resource: 'List all registered receipts.' It clearly identifies the operation's scope ('all') and names the output fields ('key, language, and last-fetch status'), making it distinct from sibling tools like receipt_show or receipt_delete.

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

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

The description states what the tool does but provides no guidance about when to prefer it over alternatives, such as receipt_show for a single receipt or receipt_add for creating one. It does not mention any context, prerequisites, or exclusions.

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

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

With no annotations, the description carries the burden of behavior. It discloses that the tool re-reads from disk, which implies refreshing state, but it does not warn that unsaved in-memory edits from receipt_edit might be overwritten. That is a meaningful behavioral gap for a reload 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?

The description is a single sentence that states the operation, the resource, and the intent without any filler. Every word earns its place.

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

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

For a no-parameter tool with an output schema present, the description is nearly complete. The only missing context is an explicit note about whether reloading discards unsaved in-memory edits, which would help an agent avoid unintended state loss.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema description coverage is 100%, so no parameter documentation is needed. The baseline for zero-param tools is 4, and the description does not need to add parameter-level detail.

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 ('re-read') and resource ('receipts.json from disk') and gives the reason: to pick up external edits. This clearly distinguishes it from siblings like receipt_list or receipt_show, which inspect receipts rather than refresh the state.

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?

'Pick up external edits' communicates when to use the tool: after receipts.json has been modified outside of the MCP tooling. It does not explicitly list when not to use it or name alternatives, but the intended use case is reasonably clear.

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

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

No annotations are provided, so the description carries the full burden, but it only conveys that this is a read ('show') operation. It doesn't disclose behavior on a missing/invalid key, whether the receipt must already exist, or any size/pagination constraints on the returned JSON. Given zero annotation coverage, this is a significant gap.

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

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

A single sentence with no wasted words. The core operation, scope (single receipt), output type (full JSON), and argument (key) are all front-loaded efficiently.

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

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

With an output schema present and only one required parameter, the description covers the basic call contract. However, it omits how the key is obtained (likely from receipt_list) and doesn't address error cases, leaving minor gaps for an otherwise simple retrieval tool.

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

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the bare schema offers only a 'Key' string property. The description adds meaning by stating the key identifies a single receipt and that the result is the full JSON. It doesn't explain key format or provenance, but it does clarify the parameter's role beyond the schema.

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

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

The description uses a specific verb ('Show') and resource ('the full JSON of a single receipt') and clarifies it operates on a single item 'by its key,' which distinguishes it from receipt_list (multiple receipts) and the mutation siblings (add/edit/delete). It doesn't explicitly name a sibling, but the single-vs-list distinction is clear.

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

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

No guidance is given on when to use this versus receipt_list or the other receipt tools. There's no stated prerequisite (e.g., that the key is obtained from receipt_list) or explicit exclusion of alternatives. Any sense of when to call it must be inferred from the name and the word 'single.'

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