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

Annotations cover readOnly/openWorld, and the description adds rich behavioral detail beyond them: the grouped-by-family return format, the not_loaded / in_documents_folder / not_in_documents_folder reporting, the semantics of coverage: "weak", and the caveat that coverage is judged only on keyword matches.

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?

Front-loaded with the purpose and example, then per-parameter guidance, then return-shape notes. Dense but nearly every clause adds operational value; the return-format paragraph is slightly long but earns its place given no output schema.

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

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

Given no output schema and 0% param coverage, the description covers everything: purpose, argument conventions, return structure, coverage semantics, and how to follow up with sibling tools. An agent could call and interpret this correctly without opening anything else.

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 carry the burden and it does: it defines topic (subject only, no standard names), doc_ids (which standards, omit for all), and the example values for each. Only limit is not explained, but the critical parameters are fully disambiguated.

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

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

Specific verb+resource: 'side-by-side search of one topic in several standards', with a concrete example (ECSS vs NASA on factors of safety). Naming the ECSS/NASA pairing and the compare-across-standards scope distinguishes it clearly from search_requirements.

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

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

Explicitly instructs how to build the topic argument ('the subject only... no standard names'), when to omit doc_ids ('omit for all loaded'), and what to do with weak coverage ('say so rather than force an equivalence'). It even routes post-search work to get_requirement / get_table, giving explicit alternatives.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and closed-world scope are covered. The description adds the useful nuance that references may come from the requirement's notes as well as the requirement itself, but does not mention pagination, ordering, or output shape.

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

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

A single, front-loaded sentence with zero redundant wording. Nothing to trim.

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?

Annotations cover the safety profile and there is no output schema, so return values needn't be explained. However, with two undocumented required parameters and no output/schema detail, the description is only minimally adequate for invoking the tool correctly.

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

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

Schema description coverage is 0% for both required parameters, so the description carries the full burden. It never explains what doc_id and req_id identify or how they relate (e.g., whether req_id is scoped to doc_id).

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 (List) and resource (standards and clauses that a requirement refers to). It distinguishes itself from siblings like get_requirement by focusing on outbound references rather than the requirement itself, though it doesn't name alternatives explicitly.

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

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

Usage is implied: call this to discover what a requirement cites. There's no explicit when/when-not guidance or named alternatives, but the scope is narrow enough that the intent is reasonably clear.

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

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

Annotations already declare this a read-only, closed-world operation. The description adds genuinely new behavioral context by disclosing the record value domain (requirement, recommendation, permission, guidance, deleted) and instructing the agent to report which kind it is — useful since no output schema exists. It says nothing about not-found or ambiguous-ID 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 one-line purpose is front-loaded, followed by compact labeled parameter examples. It is longer than the bare minimum but nearly every clause is a distinct ID-format case that 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-required-parameter read operation with no output schema, the description covers inputs thoroughly and characterizes the returned content, including the record `kind` taxonomy. The only real gap is the absence of guidance on unmatched or ambiguous IDs.

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 carries the full burden, and it delivers: both doc_id and req_id are explained with concrete formats and examples across multiple naming conventions (ECSS, NASA, DRD content, FCR items, n-th "shall" paragraph). This is well above the baseline for an uncovered schema, though the grammar remains loose rather than exhaustive.

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

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

States a specific verb and resource ("Get the exact text of one requirement") with clear singular scope. It does not, however, explicitly distinguish itself from the sibling search_requirements, so an agent must infer that this is the exact-ID lookup rather than the discovery 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?

Usage is only implied: the heavy emphasis on precise ID formats signals that this tool is for when you already hold a doc_id/req_id. It never names search_requirements as the alternative, nor says what to do when exact IDs are unknown, so the agent must infer the routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the outline contains no requirement text, which prevents an agent from mistakenly quoting it. It does not discuss pagination or output size for large standards.

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?

Purpose is front-loaded in the first sentence, followed by compact per-parameter glosses and a single cautionary sentence. Given the 0% schema coverage, the parameter lines earn their place, though the text runs as one dense block rather than clearly delimited sections.

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?

There is no output schema, so the description must describe returns, and it does: clause numbers, titles, record counts by kind, the record IDs placed directly in a clause, and the tables in it. Combined with the clause/depth semantics and the pointer to text-retrieval siblings, an agent has everything needed to call it correctly.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning, and it does: doc_id is given with two concrete example identifiers, clause is explained including the omit-for-whole-document behavior, and depth is defined as heading levels below the start with its default of 2. This fully compensates for the empty schema descriptions.

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

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

The opening line states a concrete verb+resource: a table of contents for one standard, returning clause numbers, titles, and per-kind record counts. The closing sentence separates it from get_requirement and get_table by declaring that no requirement text is included, so an agent can distinguish it from siblings without opening a schema.

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

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

It clearly routes the agent to alternatives ('use get_requirement / get_table for anything you quote or cite') and explains the scope effect of the clause parameter (that section and its subsections). It lacks an explicit when-to-use versus list_documents or search_requirements, so it stops short of a full routing guide.

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

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

Annotations only provide readOnlyHint and openWorldHint; the description adds rich behavioral detail: the row format (labels, value cells, parsed values, footnote markers), spans_rows for merged cells, tier/page/check metadata, citation-check requirements, and the empty-table_id listing mode.

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 information-dense and mostly front-loaded, with each sentence adding a distinct piece of behavior or parameter guidance. It is slightly long due to the necessary return-format and citation-check instructions, but not wasteful.

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

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

With no output schema and 0% schema description coverage, the description does the necessary work: it explains the return structure, special row attributes, citation rules, and the listing fallback. An agent has enough context to call and interpret the tool correctly.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It provides concrete examples for doc_id (e.g. 'ECSS-E-ST-32-10C') and table_id (e.g. 'Table 4-3' or '4-3'), and explains the empty-string default that lists a document's tables.

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 (Get), resource (table), and output form (structured rows, verbatim). It is clearly distinct from sibling tools like get_requirement and get_section_outline, which handle requirements and outlines rather than tabular data.

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

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

Usage is implied by the purpose, and the description explains that omitting table_id lists a document's tables. However, it does not explicitly say when to choose this tool over siblings like list_documents or search_requirements, nor does it state prerequisites for obtaining doc_id.

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

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

Annotations only cover readOnly/openWorld, but the description adds substantial behavioral context: the meaning of each tier value, the warning that unchecked/checked numbers should be verified against the source page, that not-loaded documents have no available text, and that results are capped at `limit` with a `truncated` flag.

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?

Front-loaded with the resource and its attributes, then filters, then return shape. Dense parenthetical asides and semicolon chains make it slightly hard to scan, but nearly every clause carries information the agent needs.

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

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

With no output schema, the description supplies the return contract ('{"count", "documents"}', at most `limit`, plus `truncated`), the reliability caveats on tier, and the not-loaded semantics. An agent has everything needed to call and interpret this tool.

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

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

Schema description coverage is 0%, so the description carries the full burden and does so: it documents family values, doc_type examples, discipline codes ('E-32', 'Q-70', 'NASA-5000') or names, query semantics, include_not_loaded behavior, and limit. Case-insensitivity is disclosed, which the schema does not express.

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

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

States a specific verb and resource ('List the standards currently loaded') and enumerates the concrete attributes returned (issue, title, family, doc_type, discipline, record counts, tier), so the agent knows exactly what this catalog view yields. This is clearly distinguishable from retrieval siblings like get_requirement or search_requirements.

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

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

Gives explicit when-to-use guidance for every filter, tells the agent when to set include_not_loaded, and adds a hard constraint: 'never answer from them, but you may name one as the standard that would cover a question.' That is a genuine usage rule, not an implied one.

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

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

Annotations only declare readOnlyHint/openWorldHint; the description goes far beyond by documenting the response envelope (results, not_loaded, elsewhere, notes), the in_documents_folder vs not_in_documents_folder split with remediation via corpus.yaml, tier/check/page fields, and the neighbours mechanism. This is unusually rich behavioral disclosure, including the mandatory 'check against the source, page N' repetition rule.

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?

Purpose and the critical query constraint are front-loaded, and nearly every sentence carries operative instruction (citation rules, verification duties). It is dense and somewhat run-on, with backtick field names stacked across long sentences, but there is little true padding.

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

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

For a tool with no output schema and no parameter descriptions, the description supplies return shape, edge cases, and downstream citation obligations, so an agent has what it needs to interpret results correctly. The remaining gap is the unexplained limit parameter and any indication of result ordering or truncation.

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 must carry all parameter meaning; it fully defines query (never empty, with example phrasings) and doc_id (scoping behavior, standard-name restriction semantics) far beyond the bare schema. The third parameter, limit, is never mentioned anywhere, leaving paging behavior undocumented.

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

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

States a specific verb+resource ('search across loaded requirements') and even names the retrieval mechanism (BM25, hybrid with embeddings when enabled). It is clearly distinguishable from siblings like get_requirement or compare_topic, which presuppose a citation or topic rather than a free-text query.

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

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

Gives real routing guidance: restrict with doc_id or let standards named in the query scope the search, take numbers from matched_table_row or get_table, and never answer from not_loaded entries. It stops short of an explicit 'use X instead when Y' map against siblings such as get_requirement, so it is strong but not exhaustive.

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