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

With no annotations, the description carries the full burden of disclosing behavior. It lists the specific checks (count against measured curve, borrowings from provenance, sibling fit, duplicates, keywords), which is useful. However, it uses domain jargon like 'measured curve' and 'provenance' without elaboration, and doesn't state side effects (though 'lint' implies read-only).

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

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

The description is a single sentence, front-loaded with the verb 'lint' and the resource, followed by a list of specific checks. It is appropriately sized for the tool's complexity, though the list is somewhat dense. No wasted words.

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

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

Given the tool's complexity (3 params, nested objects) and that an output schema exists, the description gives a high-level overview but leaves domain-specific terms unexplained (e.g., 'measured curve', 'provenance'). It doesn't describe the output structure, but that's covered by the output schema. Overall, it is adequate but not comprehensive.

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 references all three parameters indirectly: 'one question' (question), 'paraphrases' (paraphrases), and 'sibling question' (siblings). This gives functional context, but it doesn't explain the internal structure of the question object or how siblings are used beyond comparison. Overall, it adds partial meaning.

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: to 'lint the paraphrases of one question before they go into a pack'. It specifies the resource (paraphrases of a question) and the specific checks performed, which distinguishes it from sibling tools like compose_question or validate_pack.

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 usage context: 'before they go into a pack' indicates this is a pre-pack quality check. It doesn't explicitly mention alternatives or exclusions, but the context is sufficient for an agent to know when to invoke it.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: how parts are placed ('placing each where the retrieval measurements say it belongs'), which parts are indexed versus not, and the return value ('the question object plus what is still missing from it'). This goes beyond a simple action statement, though it omits details on side effects or permissions, which are less critical for a composition 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 two sentences, front-loaded with the main action, and each sentence earns its place. It includes essential behavioral and return information without redundancy. It is appropriately sized for the tool's complexity.

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

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

Despite having an output schema, the tool is moderately complex with 11 parameters, many of which are unexplained. The description focuses on the four main parts and the compositional logic, but omits guidance on the other parameters, prerequisites, or error conditions. It leaves significant gaps for an agent 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 has 11 parameters and 0% schema description coverage, so the description must compensate by explaining parameter meanings. It only vaguely references 'four parts' without mapping them to specific fields. For instance, it never mentions parameters like 'people', 'observation', or 'priority'. The description provides minimal semantic value 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 action: 'Assemble one pack question from the four parts', clearly identifying the resource (pack question) and the process (assembling based on retrieval measurements). It distinguishes itself from sibling tools like parse_meeting_notes or validate_pack by focusing on composition rather than parsing or validation.

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

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

The description provides clear context for when to use the tool: when you have the four parts and need to assemble a question according to retrieval measurements. It implies the prerequisite of having those parts, but does not explicitly name alternatives or exclusions. This meets the 'clear context, no exclusions' level.

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 disclose behavior. It clearly states it is a read operation ('Read') and notes the content source ('Same text as the asistonto:// resources'), but it does not explain behavior for invalid topics, the 'all' topic, or the output format. The description adds some context but leaves several behavioral aspects unspecified.

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 exceptionally concise: two sentences, no redundant wording. It front-loads the purpose, then gives the resource equivalence, then the topic list. Every sentence serves a purpose, making it easy to scan.

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 read-guide tool with an output schema, the description covers the core aspects: what it does, when to use it, and the available topics. The main gap is not specifying behavior for the 'all' topic or error handling, but given the low complexity and presence of an output schema, it is largely complete.

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

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

The schema provides only a bare 'topic' property with no description or enum, so the description's topic list ('pack-format, four-part-questions, paraphrases, calibration, workflow, labels, example, all') is essential and fully compensates for the 0% schema coverage. It effectively enumerates valid values and clarifies the default from 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 action ('Read the pack-authoring guidance') and clearly identifies the resource. It distinguishes itself from sibling tools like read_pack by focusing on authoring guidance rather than pack content, and the topic list adds clarity.

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

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

It gives a clear usage context: 'for clients that cannot read resources,' which tells when to use this tool. The listed topics imply the scope, but it does not explicitly name alternatives or exclusions. The condition alone provides strong guidance.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It discloses the key behavioral trait that the gate is a z-score over the pack's own scores, and that a small pack has a ceiling below it and stays dark. This adds meaningful context about the internal logic beyond what the tool name alone conveys.

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, front-loading the core concept. The phrase 'stays dark' is slightly informal but does not add unnecessary length. Every sentence contributes to understanding the tool's purpose.

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 there is an output schema and only one optional parameter, the description provides sufficient context about the tool's purpose and underlying logic. It explains why pack size matters and how the gate works. It could be more explicit about z_threshold, but overall it covers the essential aspects for a tool of this complexity.

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 description coverage for the parameter z_threshold, and the tool description does not explicitly explain what this parameter represents or how it affects the floor. It only refers to 'a given gate,' which is a vague hint. The default value of 4.75 is also not mentioned, leaving the parameter semantics largely unexplained.

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

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

The description clearly states the tool determines the minimum pack size needed before any question can fire, given a gate. It distinguishes itself from sibling tools like validate_pack or read_pack by focusing on this specific size floor calculation, though it lacks an explicit verb like 'returns' or 'calculates.'

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 explains the context of the live gate being a z-score and mentions that small packs stay dark, which implies when this tool would be useful. However, it does not explicitly say when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites.

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

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It usefully states that it accepts both format shapes and 'reports which one it read,' which is genuine behavioral detail. It does not mention error cases or explicitly reassure non-mutation, but 'parse' is naturally read-only and the output schema covers results.

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

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

The description is exactly two sentences with no filler. The first sentence states the core purpose, and the second packs format variants and output behavior, making every word count.

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 primary input contract and output behavior, and an output schema exists to define return structure. The main gaps are the unexplained optional parameters and lack of error-handling details, but the tool is not overly complex, making this a largely complete description.

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 no descriptions for markdown, prefix, or source, so the description must compensate. It explains the markdown parameter's accepted corpus formats well, and indirectly hints at the prefix parameter via the '### QC-1' example, but it leaves prefix and source underspecified and does not explain their roles or 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 opens with 'Parse a corpus document into pack questions,' which clearly names the verb, input, and output. It also enumerates the two accepted input shapes, distinguishing it from sibling authoring, validation, and writing 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 clearly implies the appropriate context: use this when you have a corpus document in either supported format that needs conversion to pack questions. However, it does not explicitly discuss when not to use it or compare it with sibling tools like compose_question or write_pack.

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

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

With no annotations, the description carries the full burden. It states the tool reads 'the way the live server does' and validates, implying non-mutating behavior, but it does not detail what validation involves, error behavior, or whether any files are modified.

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 concise sentences, front-loaded with the action and followed by a clear use case. Every word contributes value, with no redundancy or filler.

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

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

The output schema covers return values, but the description omits details about the expected pack structure, what validation includes, and how this relates to the sibling validate_pack tool. It is minimally viable but leaves important gaps for a tool with a single parameter and no annotation safety hints.

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, 'directory', has no schema description (0% coverage) and is not mentioned in the tool description. The description fails to add any meaning about what the directory should contain or how to format the path, leaving the parameter completely undocumented.

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

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

The description clearly identifies the tool as reading a pack from disk and validating it, with a specific verb and resource. It also provides a use case (review/extend existing packs) that distinguishes it from write_pack, though the overlap with validate_pack introduces slight 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?

The phrase 'Use this to review or extend a pack that already exists' gives explicit usage context. It does not explicitly mention alternatives like validate_pack, but it provides clear enough direction for when to invoke this 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 must carry the full burden of behavioral disclosure. It only says 'Render' and describes the output format, but does not disclose side effects (e.g., whether it writes files, modifies data, or is read-only), nor does it describe the return value beyond relying on the output schema. This is a significant gap.

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

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

The description is two sentences, with no filler. The first sentence states the core action, and the second adds useful context about its relationship to the pack. Every word earns its place, and it is appropriately 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?

For a single-parameter tool with an output schema, the description provides adequate purpose and usage context. However, it lacks transparency about side effects and parameter details, making it only minimally complete. There are clear gaps that could be filled with a short note on what the output looks like (e.g., 'Returns markdown text') and what format the questions should take.

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 one parameter 'questions' with 0% description coverage. The description says 'Render questions' but does not explain the structure of the questions array or what fields each object should have. It adds no meaning beyond the parameter name, failing to compensate for the lack of schema documentation.

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

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

The description clearly states the tool renders questions into a four-part markdown document for human reading and correction. It uses a specific verb 'Render' with a clear resource ('questions') and output format, distinguishing it from siblings like write_pack and read_pack.

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 context for when to use this tool: it is meant to be kept next to the machine-readable pack, with the phrase 'the pack is for the machine, this is for the room' clarifying it produces a human-facing document. However, it does not explicitly name alternatives 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?

With no annotations, the description carries the full burden. It discloses important behavioral semantics: errors mean the pack will not load, warnings mean it will load but underperform silently. This adds context beyond the schema, though it does not specify mechanics or required permissions.

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

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

Two sentences, front-loaded with the primary action, no redundancy, and every clause adds value. Perfectly concise 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?

Despite having an output schema, the description omits parameter semantics and usage context relative to siblings. With 6 parameters and no annotations, an agent cannot reliably invoke this tool without external knowledge, making the description incomplete.

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

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

Schema description coverage is 0%, and the description provides zero explanation of parameters such as pack, questions, labels, or z_threshold. This is a significant gap; the description fails to compensate for the undocumented schema, leaving an agent uncertain about what each parameter means.

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 validates a pack against two specific criteria: the schema the live copilot loads and measurement-based silent underperformance. It distinguishes from siblings by focusing on validation rather than reading, writing, or composing packs.

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 explains the meaning of errors and warnings, which helps users interpret the result and implies when to use the tool (to check pack health before use). However, it does not explicitly mention when to use it versus alternatives like check_paraphrases or pack_authoring_guide, nor provide 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 adds a key behavioral detail—it validates before writing and refuses invalid packs. However, it omits other behaviors like overwrite semantics or directory creation, leaving significant transparency 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?

Two concise sentences front-load the primary action and resource, with no redundant words. The file list adds specificity without verbosity.

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

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

With 9 parameters, an output schema, and no annotations, this short description is insufficient for correct invocation. It covers purpose and validation behavior, but lacks parameter semantics and edge-case details needed for a tool with this complexity.

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

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

Schema coverage is 0%, and the description does not explain the 9 input parameters. It indirectly hints at background.txt and labels.json corresponding to optional params, but does not clarify pack, questions, overwrite, or others, providing minimal assistance.

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 ('Write a pack to a directory') and specifies the output files (brief.json, paraphrases.json, optionally background.txt and labels.json), clearly distinguishing it from siblings like read_pack and validate_pack.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives such as validate_pack or read_pack. The validation behavior is mentioned, but no when-to-use or when-not-to-use guidance is given.

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