SumOffice — real Word and Excel for agents

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

With no annotations provided, the description carries the full burden of disclosing behavior. It does disclose key traits: it operates on the session's cabin, not the original file; it refuses stale proposals and instructs to propose again; and repeating an applied proposal is a no-op. These go beyond a simple statement of intent and give the agent actionable knowledge about side effects and edge cases. It does not mention success/failure return values or other side effects, but for a simple mutation tool this is adequate.

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 concise sentences, front-loaded with the core purpose. Each sentence adds necessary information: the action, the scoping to the session's cabin, and the two edge cases (stale and repeat). 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 a tool with a single parameter, no output schema, and clear sibling context, the description is largely complete. It covers the main purpose, the working context (session cabin), and the two critical behavioral caveats (stale and repeat). It does not describe the return value or error responses beyond the stale case, but given the simplicity and the absence of an output schema, this is acceptable.

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 explain the parameter. It mentions 'proposal from document_propose_replacement', implying that proposal_id is the identifier returned by that tool, but it does not explicitly define proposal_id or its format. The description also mentions that a stale proposal is refused and repeating is a no-op, which indirectly explains the role of proposal_id. However, an explicit statement like 'proposal_id is the ID returned by document_propose_replacement' would strengthen this. The implicit reference is enough for a straightforward 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?

The description clearly states the action: 'Apply a proposal from document_propose_replacement to the document in this session's cabin'. It specifies the verb 'apply', the resource (a proposal), and the target (the session's cabin document). It also distinguishes itself from siblings by explicitly referencing the proposal tool and clarifying it does not modify the original file. This fully differentiates it from other document 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 the workflow: you must first have a proposal from document_propose_replacement, and if the proposal is stale you should propose again. It does not explicitly list alternatives or exclusions, but the reference to the specific source tool and the 'propose again' instruction provide clear contextual guidance on when to use this tool. It could be improved by explicitly stating 'use this after document_propose_replacement', but the intent is 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 must carry the burden of behavior disclosure. It adds useful constraints such as 'up to 50' and lists the fields returned, but it never explicitly states that this is a read-only operation or what happens when the cap is exceeded.

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 compact phrase with no filler. It front-loads the key content and the important limit, which is appropriate for a zero-parameter tool.

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?

Since there is no output schema and no annotations, the description should fully explain what is returned. It covers comment fields and the cap, but it does not specify the structure of tracked changes, the output format, or the read-only nature, leaving some 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?

This tool has zero parameters, so there are no parameter semantics to document; the baseline of 4 applies. The 'up to 50' limit refers to output size, not input, so no further parameter explanation 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 clearly identifies the subject area: comments (with author, text, anchor, resolved) and tracked changes, capped at 50. It is not vague, but it lacks an explicit action verb such as 'returns' or 'lists,' and it does not differentiate from sibling tools, so it falls 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?

There is no guidance about when to use this tool instead of document_read, document_describe, or document_apply. Usage context is only implied by the noun phrase, with no exclusions, prerequisites, or alternative routing.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It usefully lists the output fields the agent will receive, but it does not explicitly state that the operation is read-only or side-effect-free, nor does it mention edge cases or failure behavior. For a 'describe' tool, the field list plus the name implies a safe inspection, but richer disclosure would be better.

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 extremely compact: a field list followed by a short routing instruction. Every token earns its place, and the concrete payload is front-loaded before the 'call first' guidance. There is no filler, repetition, or unnecessary 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?

Given zero parameters and no output schema, the description does the necessary work of listing the key return fields and specifying workflow order ('call first'). It is complete enough for an agent to invoke the tool and understand what it will get back, though it could be slightly more explicit about the shape or format of the response.

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 schema is trivially complete at 100% coverage and the baseline of 4 applies. The description correctly avoids inventing parameter details and instead focuses on the returned metadata, which is the only relevant semantic content.

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

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

The description clearly identifies the resource ('document') and enumerates the metadata returned: name, pages, paragraphs, words, comments, tracked changes, and track-changes state. The title 'What the document is' reinforces the purpose, and this distinguishes it from sibling tools like document_read or document_comments, though no sibling is explicitly named.

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 'For documents; call first' provides clear contextual guidance: this tool is the initial inspection step before document operations. It doesn't name alternatives or state when not to use it, but it does restrict scope to documents and establishes ordering, which is sufficient for basic workflow selection.

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

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

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that the PDF reflects the document as it currently exists in the session (after applied proposals or as opened), and discloses the link's 24-hour validity and the inclusion of page count. It doesn't mention potential side effects, but as a rendering/export operation, side effects are unlikely. The description provides sufficient transparency for a read-like 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 two sentences, with the core action and output stated first, followed by a clear scope exclusion and alternative. Every sentence contributes essential information, and the structure is front-loaded with the primary purpose, making it efficient and easy to parse.

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, parameterless tool, the description is complete: it covers purpose, output details (PDF link, validity, page count), scope (current session's cabin), and the alternative for workbooks. There is no output schema to document, and no other operational details (like authentication or rate limits) are necessary for this type of export. An agent can confidently invoke this tool based on the description 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?

The tool has zero parameters, so the description correctly avoids parameter-specific details. Per the baseline rule for 0-parameter tools, a score of 4 is appropriate because there is no parameter semantics to add, and the description does not clutter with irrelevant information.

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

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

The description clearly states the tool's function: it lays out the document's current state and returns a PDF download link plus page count. It uses specific verbs ('lay out', 'return') and identifies the resource (document), and it distinguishes itself from the sibling tool for workbooks ('for workbooks use document_save_copy'), 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?

The description explicitly states when to use this tool (for documents needing PDF export) and when not to use it (for workbooks), directing to the specific alternative (document_save_copy). This provides clear guidance without ambiguity.

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

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

There are no annotations, so the description carries the behavioral burden. It discloses case-insensitive matching, that only paragraphs containing the text are returned, and that snippets are included. It doesn't mention match limits or no-match behavior, but for a simple find operation this is adequate.

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 sentence, front-loaded with the result shape and key matching behavior. No filler or redundancy.

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

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

For a one-parameter search tool with no output schema, the description captures the search term, case sensitivity, and return shape. It lacks only usage guidance and boundary behavior, which are minor for this simple tool.

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

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

With 0% schema description coverage, the description provides the needed semantic: the query parameter is the text to match, and matching is case-insensitive. This is sufficient for a single string parameter already constrained by min/max length in the schema.

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

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

The description states exactly what the tool produces: paragraphs containing the search text. Its document/paragraph framing also distinguishes it from sibling sheet_find and broader document_read.

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 is implied: call this when you need to locate text within a document and see surrounding snippets. It does not explicitly state when to prefer document_read or sheet_find, nor list 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?

No annotations are provided, so the description carries the full burden. It discloses one behavioral trait: 'Opens a separate editor cabin for this session,' which is useful session-isolation context. However, it does not say whether the operation is read-only, what happens to the current cabin, what the tool returns, or whether opening affects the document.

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

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

The description is compact, front-loads purpose, and is organized into three sentences. The long enumeration overlaps with the schema enum and introduces an invalid entry, so not every word fully earns its place, but it remains readable and structured.

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

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

For a one-parameter demo opener, most needed facts are present: allowed demo names, the sibling for user files, and session behavior. However, with no output schema or annotations, the agent still lacks expected return or side-effect context, and the default/required contradiction plus 'xtools' create avoidable 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 schema has 0% description coverage, so the description must compensate. It adds category grouping (documents vs. workbooks) and a default value, but the enum already names the allowed slugs. It also lists 'xtools,' which is absent from the input schema, and claims a default even though slug is required, making the guidance partly misleading.

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

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

The description names a specific action, 'Open', and resource, 'demo files by name', while enumerating documents versus workbooks. It explicitly contrasts with document_open_file, so an agent can distinguish this tool from its sibling. The purpose is unambiguous despite a stale 'xtools' value.

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

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

It explicitly says 'For your own file use document_open_file,' naming the sibling and the condition that selects it. It also states the default 'footnotes' and the demo-file scope, giving clear when-to-use and when-not-to-use guidance. The core routing is 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?

With no annotations present, the description carries the full behavioral burden. It discloses critical safety and lifecycle facts: 'Nothing in the file is executed', the file is kept for 24 hours then deleted, the cabin is private to the session, and the maximum file size is 50 MB. This is exemplary transparency for an unannotated tool.

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

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

The description is dense but well-organized: it front-loads the primary function, then constraints, then post-open workflow. Every sentence contributes useful information, though the downstream tool-routing guidance could be separated into a 'Use after opening' section for slightly better 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?

Given no annotations, no output schema, and four parameters, the description is nearly complete: file types, size limit, input alternatives, retention, security, and sibling routing are all covered. The only significant gap is the unexplained 'path' parameter, and the return value is not described, though no output schema exists to compensate.

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%, so the description must explain parameters. It clarifies url ('https link the server can fetch') and base64 ('file bytes'), and notes that base64 requires name with the correct extension. However, the 'path' parameter is never mentioned, leaving its meaning entirely unspecified.

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: 'Open YOUR file in a private editor cabin', names the accepted file types (.docx/.doc/.odt, .xlsx/.xlsm/.xlsb/.xls/.ods), and imposes a clear size cap. It differentiates from siblings like document_open by emphasizing 'YOUR file' and 'private editor cabin for this session', making the tool's unique scope unmistakable.

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

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

The description gives explicit input requirements ('Give exactly one of: url... base64...') and maps out the downstream workflow, telling the agent which document_*, sheet_*, macro_*, query_*, and workbook_inspect tools to use after opening. It does not explicitly state when to avoid this tool in favor of a sibling like document_open, but the 'YOUR file' and 'private cabin' framing makes the intended context clear.

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

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

With no annotations, the description carries the full burden and does so well: it states that nothing changes yet, that the change is built on a copy, and that the tool returns before/after plus integrity checks for numbers, dates, and links. It also mentions the proposal_id needed for the next step.

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, each earning its place: the core action, the no-side-effect behavior, and the next-step prerequisite. The most important scoping information is front-loaded in the first sentence.

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 annotations and no output schema, the description covers the essential context: what to do first, what happens during execution, what the result contains, and how to continue. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 0%, so the description must explain the parameters. It clarifies paragraph_index (from document_read) and text (full new text), but the optional reason parameter is not explained at all, and no additional constraints or formatting guidance are provided.

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 ('Propose'), a specific resource ('full new text of one paragraph'), and references the source of the index ('paragraph_index from document_read'). It clearly distinguishes this proposal tool from the sibling document_apply, which is the commit step.

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 workflow guidance: read the paragraph first, propose replacement text, then call document_apply with the proposal_id. It does not explicitly list exclusions or conditions for when not to use it, but the propose-vs-apply distinction is strongly implied and sufficient.

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

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

With no annotations, the description carries the full behavioral burden. It clearly discloses pagination through 'next' with null termination, enforces a max window of 40 paragraphs, and explicitly states that a missing paragraph means refusal rather than fabrication.

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 compact sentences with no wasted words. It front-loads the core window concept, then covers parameters, continuation, and refusal behavior 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?

For a simple two-parameter read tool with no output schema, the description covers windowing, bounds, continuation, and error semantics. The only notable gap is the unspecified default for 'count', and permission/read-only context is not mentioned but is less critical here.

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 does: 'from' is defined as a 0-based paragraph index, 'count' as the number of paragraphs capped at 40, and continuation is explained via 'next'. It does not state the default behavior when 'count' is omitted.

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 title 'Read paragraphs' and the description clearly establish a verb, resource, and scope: reading paragraph text as a window. This is distinct from sibling tools like document_apply or document_comments, and the description adds concrete mechanics via 'from' and 'count'.

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

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

The description implies when to use the tool: to read a range of paragraphs and continue via 'next'. However, it does not explicitly mention alternatives or state when not to use it versus related document 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?

No annotations are provided, so the description carries the full burden. It clearly states the original is never touched (non-destructive), describes behavior for macros (.xlsm with VBA intact) and documents (styles, comments, tracked changes preserved). This goes beyond a simple 'save' and discloses format-specific behaviors, which is valuable. However, it doesn't mention rate limits, auth requirements, or what happens if the file exceeds size limits for inline (though that's in schema). Does not contradict annotations (none exist).

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

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

Two sentences, front-loaded with the primary action and outcome (download link valid for 24 hours). The second sentence provides useful detail on format preservation. No fluff, but could be slightly more compact without losing meaning. It earns a 4 for efficiency and clarity.

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 low complexity (1 parameter with full schema coverage, no output schema), the description is complete enough for an agent to call it correctly. It covers the return type (download link) and the session context. The only minor omissions are handling of errors (e.g., if the session has no edits) or explicit output structure, but these are not critical given the simplicity.

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

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

Schema coverage is 100% (the only parameter inline is fully described in the schema). The description adds a bit of context by explaining the purpose of inline (returning base64 bytes) but doesn't add major new semantics—the schema already explains it. Baseline 3 is appropriate.

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

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

States a specific verb (write/save) and resource (copy of the document), and explicitly says it does not touch the original. Distinguishes itself from siblings by focusing on saving a copy and generating a download link, which is unique among the listed tools. The description clearly differentiates from document_export_pdf (which exports to PDF) and document_open (which opens files).

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?

Clear context: use after applied proposals in this session's cabin. It implies a when-to-use (after edits are applied) without explicitly stating alternatives or when-not-to-use. It doesn't mention when to prefer other tools like export_pdf or open, but the context of creating an editable copy is implied. A slight gap is the lack of explicit exclusion for other file operations.

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 does disclose the key trait that it 'Runs nothing,' which is a significant side-effect disclaimer. However, it does not explain what 'route' and 'blockers' mean, nor does it mention whether any permissions are needed or if the tool is read-only beyond the 'Runs nothing' note. It provides some transparency but not comprehensive 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, concise sentence that front-loads the primary action ('List VBA modules and runnable macros') and then adds the key behavioral note ('Runs nothing'). Every word serves a purpose, with no filler or redundancy. It is well-structured and easy to parse.

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 tool with no parameters and no output schema, the description covers the essential information: what it lists, the scope, and that it has no side effects. It does not detail the output format or elaborate on 'route' and 'blockers,' but given the tool's simplicity and the lack of an output schema, the description is reasonably complete for an agent to call it correctly. It could add a bit more about the returned data, but it is not a major 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 input schema has zero parameters, and schema coverage is 100% (trivially, since there are no params). The description adds no parameter-specific information because there are none. Per the rubric, a baseline of 4 is appropriate when there are no parameters, as there is nothing for the description to clarify beyond what the schema already shows.

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

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

The description clearly states the tool's purpose: 'List VBA modules and runnable macros (entry points) in this workbook with their route and blockers.' It specifies the verb (List), the resource (VBA modules and macros), and the scope (this workbook). It also adds 'Runs nothing,' which is a critical differentiator from siblings like macro_plan or macro_read_source, making the tool's purpose unambiguous.

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

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

The description implies safe usage by noting 'Runs nothing,' which suggests it's for inspection rather than execution. However, it does not explicitly state when to use this tool versus alternatives, nor does it name any sibling tools or provide exclusions. The context is somewhat implied but not explicit, leaving some ambiguity for the agent.

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 explicitly says the tool does not run the macro and lists what the plan will contain, which is useful behavioral context. It could go further by explaining the format of route/blockers or whether any state is inspected, but the core non-execution behavior is clear.

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 a colon-separated list of deliverables. Every phrase earns its place, and the key distinction ('without running it') appears early.

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 no output schema and no annotations, the description gives a solid high-level overview but leaves gaps. It never explains what 'route' or 'blockers' mean concretely, and it does not mention how active_sheet factors into planning. An agent can select the tool confidently, but may be underprepared for interpreting its response.

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

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

Schema description coverage is only 50%, and the description adds no meaning beyond the schema. It does not explain the active_sheet parameter at all, nor does it clarify how entrypoint or active_sheet affect the route, blockers, or instruction budget. The schema documents entrypoint's 'Module.Procedure' format, but the description contributes no additional parameter 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 uses a specific verb-resource pairing ('Plan a macro run') and clearly distinguishes itself from execution-oriented siblings like sheet_apply by emphasizing 'without running it.' It also names concrete deliverables: route, native engine support, blockers, and instruction budget.

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 that this is a planning step before execution, but it does not explicitly name alternatives or state when not to use it. For example, it never contrasts itself with macro_list, macro_read_source, or sheet_apply, so routing an agent to the right sibling is left partly to inference.

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

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

The description explicitly states 'Read-only; runs nothing,' which is valuable behavioral disclosure given that no annotations are provided. It also clarifies that it reads source text rather than executing the procedure, which prevents an agent from expecting side effects. It could add more detail about error behavior or return format, but the core safety-relevant behavior is well 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 short sentences with no filler. The core action and the read-only safety note are front-loaded, and the reference to macro_list is placed where it is most useful. 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 simple two-parameter read tool with no output schema, the description covers the essential context: what it reads, how to identify the target, and that it has no side effects. It does not describe the return format, but that is less critical for a read-only source inspection tool and the description is otherwise 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%, so the description must compensate. It explains that 'module' and 'procedure' together identify a procedure from macro_list, which adds meaning beyond the bare schema. However, it does not describe the expected format of these strings (e.g., exact names from macro_list) or whether they are case-sensitive, so the compensation is partial.

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

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

The description states a specific verb ('Read'), a specific resource ('source text of one procedure'), and the exact identifying inputs ('module + procedure name from macro_list'). It also distinguishes itself from siblings by referencing macro_list as the source of valid names, making it clear this is a read-only inspection tool rather than a planning or execution tool.

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

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

The description implies when to use this tool: when you need the source text of a single procedure, and it references macro_list for valid module/procedure names. It does not explicitly state when not to use it or name alternatives, but the context is clear enough for an agent to select it appropriately among the macro_* 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explicitly states 'Reads only; refreshes nothing,' clearly communicating that this is a safe, non-mutating operation. It doesn't cover auth or rate limits, but for a simple read tool this is adequate and exceeds what a bare annotation would provide.

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 with no fluff. The first sentence states the tool's purpose with specificity, and the second sentence adds the behavioral guarantee. Information is front-loaded and every word earns its place.

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

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

For a one-parameter read tool with no output schema, the description covers the return content (steps, load destination, connection), the read-only behavior, and the parameter meaning. It doesn't detail the output format or how to discover valid query names, but it is reasonably complete for the tool's simplicity.

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

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

The schema provides a single string parameter with no description, so schema coverage is 0%. The description's 'by name' adds meaning by clarifying that the parameter is the query name, but it does not specify format, examples, or how valid names are obtained. It adds minimal but necessary meaning 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 clearly states the action (Explain), the resource (one Power Query query by name), and the content of the explanation (steps, load, connection). It does not explicitly distinguish from sibling tools, but the verb/resource combination is specific enough for an agent to understand the tool's primary function.

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 use when an explanation of a specific query is needed, but it does not state when to use this tool versus siblings like query_list, nor does it mention any exclusions or prerequisites. There is no guidance on alternatives or when not to use the tool.

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 disclosure burden and does so well by explicitly stating 'Reads only; refreshes nothing.' This gives the agent confidence that the tool is non-mutating, although it does not mention any potential limitations 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?

A single, compact sentence states the action, the resource, the output contents, and the read-only behavior. There is no redundancy or wasted wording, and important details are front-loaded.

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

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

Despite having no output schema, the description lists exactly what the tool returns (names, step chain, load target, connections) and confirms it is non-mutating. For a zero-parameter list operation, this is sufficient for an agent to select and invoke the tool correctly.

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

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

The tool has zero parametershare, so the input schema already fully describes the invocation surface. The description is not required to explain any parameter semantics; the baseline of 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 description begins with 'List Power Query queries in this workbook', a specific verb and resource, and enumerates the exact content included (names, step chain, load target, connections). This clearly distinguishes it from sibling tools like query_explain or workbook_inspect.

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 a read-only overview use case and scopes the tool to the current workbook, but it does not explicitly state when to prefer this tool over siblings such as query_explain or workbook_inspect. Usage context is implied rather than directly stated.

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

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

With no annotations provided, the description carries the full burden and does so well: it states that the write is scoped to the session cabin, not the original file, that the engine recalculates, that stale proposals are refused, and that repeats are no-ops. This gives the agent a strong model of side effects and failure behavior.

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 dense sentence that front-loads the core purpose and then packs the essential caveats—recalculation, stale-revision refusal, and idempotency—without unnecessary words 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?

Given one simple parameter, no output schema, and no annotations, the description is remarkably complete: it explains where the proposal comes from, the file scope, recalculation behavior, concurrency failure, and repeat behavior. An agent has enough context 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?

The schema only defines proposal_id as a string with length constraints; the description adds the crucial semantic that this ID comes from sheet_propose_edits and is tied to a specific workbook revision. It does not describe the ID format, but the schema covers the basic constraints.

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 ('apply') with a clear resource ('a proposal from sheet_propose_edits') and target ('the workbook in this session's cabin'). It also distinguishes the sheet-specific operation from the sibling document_apply and clearly ties it to sheet_propose_edits.

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 makes the companion workflow explicit: obtain a proposal from sheet_propose_edits, then apply it; if the revision has moved on, propose again. It does not enumerate exclusions or alternatives, but the prerequisite and failure recovery are clear enough for correct selection.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It communicates that the tool is an overview/read-style operation and enumerates the returned information. It does not explicitly state permissions, errors, or that the tool is strictly read-only, but its wording strongly implies non-mutating behavior.

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 with no filler. The output is front-loaded, and the workflow guidance is placed immediately after, making it easy for an agent to parse and act on.

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 overview tool, the description is complete: it specifies what is returned, how it should be used first, and which sibling tools should follow. No output schema exists, but the description provides enough return-value 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 and 100% schema description coverage, so there is no parameter ambiguity. The description correctly avoids adding unnecessary parameter 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 clearly identifies the tool as a workbook overview, listing exact outputs: every sheet tab, used range, current revision, and the open sheet's header row. This is specific and distinguishes it from other sheet/document 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?

It gives explicit sequencing: 'Call this first, then pass the tab name... to sheet_read and sheet_find.' This is clear contextual guidance, though it does not explicitly state when not to use this tool or compare it to a direct sibling alternative.

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 behavioral burden. It discloses the case-insensitive matching, that both values and formulas are searched, and the important fallback behavior when 'sheet' is omitted. The return shape is not described, but the behavioral cautions are substantive.

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 with no filler. The primary operation is front-loaded, and the critical warning about missing 'sheet' is placed immediately where an agent needs it.

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 two-parameter search tool, the description covers both parameters and the most dangerous edge case explicitly. Since there is no output schema, a note about return values or zero-match behavior would be helpful, but the input contract is complete enough 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 coverage is only 50% because 'query' lacks a schema description. The description compensates by explaining that the search text matches values or formulas case-insensitively and by specifying when 'sheet' is mandatory and what happens if it is omitted.

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 ('Find cells'), a specific scope ('used range of a sheet'), and matching semantics ('value or formula contains the text case-insensitively'). This makes the tool's purpose immediately clear and distinguishes it from the sibling document_find by domain.

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

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

The description provides clear, explicit context for using the 'sheet' parameter: it is required when the workbook has more than one sheet, and omitting it causes the open sheet to be searched. It does not compare against alternative tools, but the parameter-level guidance is strong.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that nothing changes in the workbook, that the engine previews edits on the current revision, reports what would change and whether errors appear, and that a person decides whether to apply. This is transparent about side effects and the decision boundary.

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: scope and input examples come first, followed by the no-side-effects guarantee, usage guardrails, and the follow-up action. Every sentence adds operational value with 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?

The description covers the whole proposal lifecycle: read first, propose edits, preview reports, then apply using proposal_id. It addresses safety, constraints, and next steps. Minor gaps remain around the exact structure of the returned report and optional parameter behavior, but the description is sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the main 'edits' parameter with examples and the 20-cell limit, but it does not clarify the optional 'sheet' and 'reason' parameters, nor the expected format of cell references. The required parameter is well covered, but optional inputs remain ambiguous.

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 ('propose') and resource ('contents for up to 20 cells'), with concrete examples of valid inputs like formulas or numbers/text. It clearly differentiates this from sheet_apply and sheet_read by emphasizing that nothing changes in the workbook and that a proposal_id is later applied.

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

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

The description gives explicit operational guidance: read the cells first, avoid overwriting input numbers unless instructed, and then call sheet_apply with the proposal_id. This is a clear workflow with preconditions and next steps, which is more than merely stating when to use the tool.

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 fully carries the behavioral disclosure burden. It reveals the maximum read size, that empty cells are omitted, that both values and formulas are returned, and critically warns that without the sheet parameter the result may quietly reference the wrong sheet. This is rich, honest behavioral context.

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

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

The description is three compact sentences with no filler. The primary action and range format are front-loaded, followed by the critical sheet caveat and a helpful pointer to sheet_describe. 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 tool with two parameters and no output schema, the description is complete: it explains the tool's purpose, parameter semantics, behavioral nuances, and the prerequisite step when tab names are unknown. Nothing essential for correct invocation or interpretation is missing.

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

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

Schema coverage is 50% and only the sheet parameter has a schema description. The tool description compensates by explaining range notation and limits ('A1:F20', 'max 60 rows × 26 columns') and by clarifying exact-tab-name requirements for sheet, including when it is mandatory. This adds substantial meaning 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 states a specific verb and resource ('Read a rectangular range like A1:F20') and explains exactly what is returned ('values and formulas. Empty cells are omitted.'). It is clearly distinguishable from siblings like sheet_describe, sheet_find, and sheet_apply.

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

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

It explicitly tells the agent when the sheet parameter is required ('when the workbook has more than one sheet'), warns about the consequence of omitting it, and names the alternative tool to call first ('Call sheet_describe first if you do not know the tab names'). This is exemplary guidance.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden, and it delivers with the explicit statement 'Runs nothing.' It also clarifies that it reports which procedures can run and why some are blocked, and notes embedded objects are 'preserved,' strongly indicating a non-mutating inspection tool.

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 dense sentences front-load the core purpose and scope, then provide safety and usage guidance. Every clause adds value; the long list of inspected artifacts is efficient rather than 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?

Despite having no output schema and no annotations, the description covers what the tool inspects, its read-only behavior, and when to call it. Nothing essential is missing for an agent to decide to invoke it correctly.

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

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

The tool has zero parameters and the schema is an empty object, so there is no parameter-semantics burden for the description to carry. The baseline of 4 for zero-parameter tools applies.

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

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

The verb 'Map' plus the explicit resource ('the whole application model of this workbook') makes the tool's purpose unmistakable. The enumerated contents (sheets, VBA modules, procedures, event handlers, dependencies, references, queries, connections, controls) precisely distinguish it from narrower siblings like sheet_describe, macro_list, and query_list.

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

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

The description explicitly says 'Call this first for questions like how is this workbook built or what does it depend on,' giving clear when-to-use guidance. It does not mention when not to use it or contrast it directly with alternatives, 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.