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

With no annotations, the description carries the full behavioral burden. It usefully discloses the return formats (PNG/JPG, and SVG delivered as svg+xml), but says nothing about behavior when a fragment is ambiguous or no match exists, nor about size or auth constraints.

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 with no filler; the core return behavior is front-loaded and the format caveat follows immediately. Every clause adds information an agent would otherwise have to guess.

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 single-parameter read tool with no output schema, this covers purpose, return format, and input shape adequately. The one real gap is what happens when the fragment is not unique or matches nothing.

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 compensate for the single undocumented `name` parameter, and it does: it explains that the value may be an exact name or a unique fragment and gives concrete examples like 'ELEC_p040' and 'sheet3_external'.

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 ("Return one image") plus the supported formats, which separates it from list_images and get_source_page. It does not explicitly name a sibling it replaces, so it stops short of full differentiation.

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

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

Usage is only implied: an agent can infer this fetches the binary image itself while list_images enumerates them, but the description never says when to call this versus listing or searching. No exclusions or prerequisites are given.

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

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

With no annotations, the description must carry the behavioral load, and it does disclose a non-obvious trait: a top-level id such as '6' pulls in its subsections while '6.1' does not. It says nothing about error behavior for unknown ids, permission requirements, or whether the lang parameter falls back when a translation is missing.

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

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

Two tight sentences, front-loaded with the action and followed by the argument semantics that need explaining. Every clause carries information an agent would otherwise have to guess.

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

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

An output schema exists, so return-value shape need not be described, and both parameters get narrative coverage. The remaining gap is failure/edge behavior (invalid section_id, unavailable translation) for a simple two-parameter read tool, which keeps it short of a 5.

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, and it largely does: section_id format is illustrated with concrete dot-notation examples and lang is given its allowed values ('en' or 'pt'). It stops short of stating the default for lang (the schema shows 'en') or whether the two languages can diverge in structure.

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 concrete verb and resource ("Return the full Markdown of a section"), which is unambiguous about what comes back. It implicitly separates itself from list_sections by returning content for one section, but never names the sibling 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?

The id-hierarchy explanation tells an agent which kind of section_id to supply for the desired scope, which is useful decision information. However, there is no explicit statement of when to use get_section versus list_sections, search_kb, or the get_source_page family, so sibling selection remains inferred.

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

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

With no annotations, the description carries the burden and does reasonably well: it reveals the operation is a render of an existing page (non-mutating), gives the valid dpi band (50–300) and a quality/perf tradeoff hint (~200 for dense schematics). It stops short of describing the returned artifact format or any cost/latency implications.

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

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

Three short sentences, purpose and payoff front-loaded, then parameter guidance in a compact clause-per-parameter rhythm. No filler and nothing repeated from the name.

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

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

For a 3-parameter render tool with no output schema and no annotations, the description supplies the essentials: valid source tags, page convention, dpi range. The one remaining gap is the shape of the return value (image type/format) and any failure mode for out-of-range pages.

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%, yet the description documents all three parameters: the allowed source tags (INST, ELEC, USER, EXP1, EXP2, COOL, FAN), the page numbering convention tied to KB citation syntax, and the dpi range with guidance. This more than compensates for the bare schema, which has no enums or property 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?

States a specific verb+resource: 'Render one page of an original PDF'. The qualifier 'so you can check a citation or read a schematic yourself' pins down the intent, and the contrast with the text-oriented siblings (get_source_page_text, list_source_documents) is implicit but discernible from 'Render'.

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?

Clearly indicates when to reach for it: verifying a citation or inspecting a schematic visually. The '[ELEC p.40] -> source=ELEC, page=40' example turns a usage rule into something directly actionable. It does not explicitly say when to prefer get_source_page_text instead, which keeps it below a 5.

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

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

With no annotations, the description carries the burden and does disclose a real behavioral trait: only the embedded text layer is returned, so schematic pages yield little or nothing. It does not state what happens on a page with no text layer (empty result vs. error) or that no OCR is performed, leaving a small gap.

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

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

Two tight sentences with the core action front-loaded and the fallback routing appended. No filler, no restatement of the name.

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

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

An output schema exists, so return values need not be explained, and the read-only nature of text extraction is self-evident. What remains thin is the format of `source` and the behavior on pages lacking a text layer.

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% for both required parameters, so the description must compensate. It clarifies that page refers to a single page of the original PDF and that the arguments mirror get_source_page, but never defines what form `source` takes (ID, path, or name), so the compensation is only 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?

States a specific verb and resource ("Extract the text layer of one page of an original PDF") with an explicit scope of one page. It also distinguishes itself from the sibling get_source_page by naming the page type where that tool is preferred, so an agent can route without opening either 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?

Gives an explicit exclusion plus the alternative: schematic pages contain little text, so render them with get_source_page instead. This is a concrete when-not/use-instead rule rather than implied usage.

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 disclose meaningful domain context: these are rendered schematics/drawings and filenames encode source document and PDF page. It says nothing about ordering, whether the set is complete, whether it can be empty, or that it is a read-only 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?

Two sentences, no padding, and the filename-encoding example is genuinely informative. It is not front-loaded with the action, however — the reader learns what the images are before learning that this returns a list of them.

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

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

An output schema exists, so return values need not be explained, and the naming convention is covered. But for a no-annotation, no-parameter enumeration tool in a set containing get_image and get_source_page, the missing link between listing names and fetching an image leaves a real gap.

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

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

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter semantics to explain and the description does not waste space on them.

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 is a noun phrase ('Names of the rendered schematic / drawing images') rather than a statement of what the tool does, so the verb (list/enumerate) must be inferred from the tool name. The resource is clear and specific, but there is no differentiation from get_image or the other list_* siblings.

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

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

Provides no when-to-use guidance, no prerequisites, and no mention of the obvious alternative get_image. An agent could infer that this is a discovery step preceding get_image, but that inference is never 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?

No annotations are provided, so the description carries the behavioral burden. Saying 'List all' usefully implies a complete, non-paginated enumeration with no filtering, but it says nothing about whether this requires any setup, how large the result may be, or how lang affects the returned titles.

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 single sentence naming the resource and return fields, followed by a compact parameter note. The trailing fragment 'lang: 'en' or 'pt'.' is clipped but efficient; nothing is wasted.

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

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

An output schema exists, so return shape need not be explained, and the tool is a simple zero-required-parameter read. The main completeness gap is routing: with nine siblings including get_section and search_kb, the description should say when this enumeration is the right call.

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

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

Schema coverage is 0% for the single 'lang' parameter – the schema only supplies a default of 'en' and no description or enum. The description compensates by enumerating the accepted values ('en' or 'pt'), which is the key missing information, though it never states what lang actually changes or that it defaults to 'en'.

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 all numbered sections of the knowledge base') and even names the returned fields (id, title, level), so the agent knows exactly what it gets. It does not distinguish itself from siblings like get_section or search_kb, leaving the choice to inference.

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

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

No when-to-use or when-not-to-use guidance and no reference to the obvious alternatives (get_section for a single section, search_kb for targeted lookup). The agent must infer that this is the enumerate-everything option from the word 'all'.

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 exist, so the description carries the burden. It makes clear this is a catalog of source files rather than content, implying a safe read, but it doesn't state whether all documents are returned, ordering, or whether tags are stable identifiers — context that would matter when feeding tags to other tools.

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 well-formed sentence with the resource front-loaded and the field list trailing. The field enumeration partially duplicates the output schema, which is mild redundancy, but nothing is wasted or buried.

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

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

An output schema exists, so the return fields need not be explained, and for a zero-parameter listing this is close to sufficient. The only real gap is the missing link to sibling tools such as get_source_page, which use the tags this tool emits.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameters whose meaning could be lost, and the description correctly implies the call needs no inputs.

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

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

The description names the resource precisely — the original PDF manuals behind the knowledge base — and enumerates the fields returned (tag, file name, page count, title). The verb is only implied by the tool name 'list', but the resource is sharply distinguished from sibling resources like sections and images.

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 mention of the citation tag format '[ELEC p.40]' hints that this tool supplies the tags needed to query pages, but it never says when to call this versus list_sections, search_kb, or get_source_page. No exclusions or prerequisites are 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, the description carries the full behavioral burden. It usefully discloses the returned fields (meaning, unit, range, matching pump menu parameter, hardware confirmation) and input representations, but it does not explicitly state that this is a read-only operation, nor does it mention error behavior for invalid registers.

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. It front-loads the tool's scope and immediately follows with accepted formats and return contents, so 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?

An output schema exists, so the description need not fully specify return structure, but it still gives a useful return overview. For a simple lookup tool this is nearly complete, with the main gap being the undocumented 'lang' parameter and no sibling-routing guidance.

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 adds strong meaning for the required 'register' parameter by explaining that 'r32', '0x32', and '32' are accepted hex forms, but it entirely omits the optional 'lang' parameter.

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: looking up one EXT-bus register in the ThermIQ map. It gives the accepted input formats and domain context, making the purpose clear, though it does not explicitly distinguish itself from siblings such as lookup_terminal or search_kb.

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 narrow 'one register' scope and the accepted format examples. However, there is no explicit when-to-use guidance, no when-not guidance, and no named alternative for related tasks like searching the knowledge base or looking up terminals.

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

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

With no annotations, the description carries the burden, and it does disclose the returned record fields (function, wiring, wire number, source page), which tells the agent what a hit looks like. It omits any statement about lookup scope, whether the match is exact or fuzzy, or what happens with the lang parameter.

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 with no filler. The six example identifiers are slightly more than needed and lead the sentence rather than the action, but they efficiently convey the format variety.

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

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

An output schema exists, so return-shape detail is not required, and the description covers the record fields anyway. However, for a tool with zero annotation and zero schema-description coverage, leaving the `lang` parameter and the matching behavior unexplained is a real gap.

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

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

Schema description coverage is 0%, so the description must compensate. The examples do illustrate the accepted terminal format, but the `lang` parameter (default 'en') is never mentioned, and the description does not clarify whether `terminal` is an exact identifier or a partial match.

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 concrete resource (terminals of the heat pump, expansion card, cooling module) and states what it returns (function, wiring, wire number, source page), with realistic example identifiers. It never explicitly says 'look up a terminal' or distinguishes itself from the sibling lookup_register, so the boundary between the two lookups is left implicit.

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

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

There is no explicit when-to-use statement, no prerequisites, and no named alternatives (lookup_register, search_kb). The examples '211', '303', '1L1', 'PE5' implicitly signal the kind of input that makes this tool applicable, which provides only implied 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 supplied, so the description carries the full burden and does a fair job: it discloses accent-insensitive matching, the unit of the returned blocks, that only the best matches come back, and that section ids are included. It leaves out the max_results cap/default behaviour and anything about result volume, which matters for a search tool returning an unbounded-looking list.

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, no filler, with the search scope and the get_section hand-off front-loaded before the lang detail. Every clause carries information an 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?

An output schema exists, so return-value shape need not be explained, and the description covers purpose, matching semantics, lang values and the next step. The only real gap is the unmentioned max_results, which matters for controlling result size.

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 has to compensate. It defines lang ('en' or 'pt'), which the schema does not (no enum), and clarifies that query is a keyword rather than natural language, but max_results is never mentioned and its default of 10 is only discoverable 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?

States a specific verb and resource plus the exact index granularity: 'Keyword search over paragraphs, list items and table rows (accent-insensitive)'. It also names the follow-up sibling (get_section) for context, so an agent can distinguish it from list_sections and the lookup_* tools 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?

Explicitly routes the agent onward ('read the section with get_section for context'), which is real when-to-use guidance for the next step. It does not state when to prefer search_kb over list_sections or the lookup_terminal/lookup_register siblings, so the coverage is clear but not exhaustive.

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