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

No annotations exist, so the description carries the full burden. 'Diff' and 'explain' imply a read-only comparison and hint at output (per-parameter explanations), which is useful, but it does not state permissions, whether any state changes occur, or how results are structured.

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: the operation is front-loaded, followed by concrete use cases. 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?

For a two-parameter comparison tool with no output schema, the description conveys both operation and likely return content ('explain each differing parameter'). A note on output structure or read-only nature would make it fully 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 100%, so axis_a and axis_b are already documented in the schema, including the allowed axis naming (X, Y1, Y2, Z, A, B). The description adds no syntax or format detail beyond the schema, so the baseline 3 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?

States a specific verb (diff parameter sets, explain each differing parameter) against a specific resource (two axis drives). It is clearly distinguishable from siblings like get_drive_parameters (single drive) and explain_drive_parameter (single parameter).

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 concrete when-to-use scenarios: cloning a drive, replacing a SERVOSTAR, diagnosing behavioral differences between axes. It does not name the sibling tools it beats out (get_drive_parameters, explain_drive_parameter), so the routing context is implied rather than 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, the description must carry the behavioral burden, and it does disclose the key trait: the return is plain text, not structured JSON, and covers an entire subject at once. It says nothing about payload size, read-only nature, or cost of pulling a large file into context, which matters for a bulk dump.

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 return contract and followed by the use case. The enum list is somewhat redundant with the schema, a minor cost, but nothing is 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?

No output schema exists, so the description correctly fills that gap by stating the return format is text and scoped to one curated file. For a single-enum-parameter read tool, that is close to sufficient; only size/cost expectations are 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 description coverage is 0%, but the sole parameter is a self-documenting enum whose eight values the description repeats verbatim. The description adds no per-value meaning (e.g., what 'sheets' or 'nozzle_flow' contain), so it duplicates the schema rather than compensating for the coverage gap.

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 curated data file as text') and enumerates exactly which files exist, so an agent knows precisely what it gets. It does not explicitly contrast itself with granular siblings like machine_overview or get_plc_io, which is the only thing separating it from 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?

'Handy to load a whole subject into context at once' implies the bulk-loading use case, which is real guidance. However, it never names an alternative or states when a granular sibling (get_axis, get_plc_io, get_procedure) would be preferable, so the choice is left 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that entries carry confidence levels and should be verified for medium/low confidence before changing a drive, but it does not explicitly confirm the tool is read-only, describe side effects, or explain the return structure.

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 tightly written sentences front-load the tool's purpose and examples, then add the important confidence/verification caveat. There is no wasted text.

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 explanation tool with no output schema, the description gives a good conceptual picture of what is returned: an explanation, axis-drive values, and confidence information. It stops short of fully describing output shape or whether values are live versus documented, but 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?

Schema coverage is 100% and the only parameter is already documented as 'Parameter name'. The description adds real domain meaning beyond the schema by specifying SERVOSTAR 600 ASCII parameters and giving examples such as GP, GVTN, FBTYPE, IN3MODE, and PGEARI.

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 ('Explain') and resource ('SERVOSTAR 600 ASCII parameter'), gives concrete parameter examples, and clarifies that it also shows the parameter's value across every axis drive. This is sufficiently distinct from sibling tools like get_drive_parameters and compare_drive_parameters.

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 the tool is useful by saying it explains a parameter and shows values across axis drives, and it warns to verify medium/low-confidence entries before changing a drive. However, it does not explicitly name alternatives or state when to use this versus get_drive_parameters.

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 behavioral burden. It usefully discloses that results include function, type, manufacturer part number, location, and drawing sheet, and that cables are also searched. It does not state whether the operation is read-only, how matching works, or how the limit parameter affects results, leaving material behavioral details uncovered.

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: the main lookup operation comes first, then the accepted query forms, the returned fields, and the cable caveat. Every sentence adds useful information without 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 no annotations and no output schema, the description supplies the key return fields and the important cable-search detail. It is nearly complete for a simple lookup tool, but omits any explanation of the limit parameter or matching behavior.

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%, so the description adds important meaning for the required query parameter by explaining that it accepts designators, type numbers, manufacturer names, or function words and giving concrete examples. The limit parameter remains undocumented in both schema and description, which prevents a higher score.

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: look up an electrical component of the cutting table. The examples of designators, type numbers, manufacturer, and function words make the scope concrete, and the mention of cables clarifies coverage. It does not explicitly distinguish itself from siblings such as search_parts or search, 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?

The description makes clear how to query the tool through designators, type numbers, manufacturer, or function words, which implies the intended usage. However, it gives no explicit when-to-use guidance, no exclusions, and no direction to alternatives such as search_parts when this tool is not appropriate.

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 return payload (page numbers to pass to get_page_image). It omits whether matching is fuzzy or exact, how results are ranked, and whether it searches both documents by default — gaps that matter for a no-annotation 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 tight sentences: purpose and examples first, then the return-value handoff to get_page_image. 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?

For a simple two-parameter lookup with no annotations or output schema, the description covers purpose, query style, and result usage. The only real omission is explicit doc_id behavior and match semantics.

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%: query is documented as 'words from the sheet title' and doc_id has an enum but no description. The description compensates partly for query by showing example phrasings, and its mention of 'electrical documentation or the pump manual' implicitly explains the doc_id scope, but it never names doc_id or its 'any' default explicitly.

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 (find) and resource (sheets/pages of the electrical documentation or pump manual) plus concrete subject examples like "drive Z1" and "terminal XT7". It also hints at the downstream chain via get_page_image, but does not explicitly differentiate itself from nearby siblings such as search, find_component, or get_sheet_index.

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 examples of subjects and the note that results feed get_page_image, so an agent can infer this is the entry point for locating pages by topic. However, there is no explicit statement of when to prefer this over search, list_drawings, or find_component, and no 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 supplied, so the description carries the burden: it discloses the result shape (field listing) and the important default that omitting the argument returns all axes plus general notes rather than erroring. Read-only intent is strongly implied by 'returns' and the lookup framing, but not stated outright nor are any limits mentioned.

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 core purpose, then a compact list of covered components, then the default behavior in a single sentence. No padding, though the middle list is a dense run-on that could be trimmed slightly.

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 convey what comes back — it does so by enumerating the component categories and noting general notes are included when no axis is given. For a single-optional-parameter read tool this is essentially 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 coverage is 100%, so baseline is 3. The description adds real value by listing the accepted axis identifiers and clarifying the optional semantics (omitted → all axes), and it spells 'abrasive feeder' more fully than the schema's enum-like hint.

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 concrete verb+resource ('Everything about one axis of the cutting table') and enumerates the exact contents (drive model, CAN address, motor, feedback, switches, valves, connectors, terminal strips, schematic sheets). This is distinctive next to siblings like get_drive_parameters or find_component, so an agent can route correctly.

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 names the valid axes and the no-argument behavior ('returns all axes plus general notes'), which gives clear usage context. It never mentions exclusions or a sibling alternative (e.g. get_drive_parameters for pure parameter lookups), so it falls just short of 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 full behavioral burden and mostly doesn't: it never states that this is a read-only operation returning the underlying payload, nor the image format, size, or whether results are truncated by max_images (default 8, max 20). The only behavior disclosed is that pictures come back, which is arguably tautological with the name.

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 no filler. It is tight, though the efficient phrasing is partly achieved by omitting 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?

No annotations and no output schema, so the description is the only source for return-value behavior — and it doesn't say how images are returned (base64? URLs? MIME types?) or how the 8/20 limit behaves. For a binary-payload retrieval tool this leaves a critical 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 coverage is 50%: doc_id has an example, but max_images is undocumented in the schema and entirely unmentioned in the description. The description adds domain framing ('Word procedure document') to justify doc_id but does nothing to explain the limit parameter or what happens when more images exist than the cap.

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 (Return) plus resource (pictures embedded in a Word procedure document), with illustrative examples of what the pictures are. It stops short of naming the sibling it differs from, e.g. get_page_image or get_drawing, so an agent must infer that this one is scoped to procedure documents rather than pages/drawings.

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 explicit when-to-use or when-not-to-use statement, and no routing to alternatives among the many image/drawing siblings (get_page_image, get_drawing, get_procedure). Usage is only implied by the phrase 'embedded in a Word procedure document'.

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, and it does disclose the return shape: a rendered PNG, accompanying metadata, extracted text, and DXF/SVG paths reported for CAD use. It does not cover failure modes (e.g. a non-CAD or invalid drawing id) or whether DXF/SVG paths are always present, which keeps it short of a 5.

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 what is returned, then a single routing clause to the sibling tool. Every clause (render format, metadata, extracted text, CAD file paths, PDF alternative) carries distinct information.

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 no annotations, the description must explain returns, and it does so thoroughly for a one-parameter tool. It stops short of describing error behavior or size/format limits, a minor gap for a read-only fetch.

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 100% and the single 'id' parameter is documented with examples pointing back to list_drawings. The description adds no further meaning about the id format or constraints, so the schema does the heavy lifting and baseline 3 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?

States a specific verb and resource (return a CAD drawing) and enumerates exactly what comes back: PNG render of the DWG, metadata, extracted text, plus DXF/SVG file paths. It explicitly distinguishes itself from get_page_image for PDF drawings, so an agent can route between the two without inspecting schemas.

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?

Names the alternative tool (get_page_image) and the condition that selects it (PDF drawings, using the document id). The required 'id' semantics are also anchored to list_drawings, giving the agent a clear entry path.

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. It adds useful context: the data comes from files kept by AMC and values are enriched with dictionary meanings. However, it does not explicitly state read-only safety, permission requirements, or error behavior for invalid axes.

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 efficient sentences that front-load the core action and follow with filtering and enrichment details. The parenthetical file names add provenance without derailing the flow.

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 read tool with no output schema and no annotations, the description provides enough context about what is returned (a parameter set with per-value dictionary meanings) and how filtering works. It could say more about output shape or edge cases, but nothing essential 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 100%, so the schema already documents all four parameters. The description reinforces the optional filtering behavior but adds no syntax, format, or interaction details beyond what the schema provides, making the baseline 3 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?

The description uses a specific verb ("Return") and resource ("Kollmorgen SERVOSTAR parameter set") and scopes it to "one axis drive," which implicitly distinguishes it from compare_drive_parameters. It does not explicitly name sibling alternatives, keeping it just 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?

The description explains optional filtering by parameter names or substring, which is parameter usage rather than tool-selection guidance. It does not state when to use this tool versus explain_drive_parameter or compare_drive_parameters, leaving the choice implied by the resource scope.

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, so the description carries the burden: it discloses it's a read operation, what content is returned (text list, optional rendered image), and the page-numbering convention. It omits error behavior (e.g. out-of-range page) and any limits, keeping it below 5.

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, front-loaded with what is returned, then per-sheet-type content guidance, then the page-numbering caveat. 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?

No output schema exists, and the description explains the return payload well enough (text content shape and optional image). For a 3-param read tool that's sufficient.

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%, so baseline is 3, but the description adds real meaning: page numbers are PDF page numbers equal to sheet numbers, and it explains when to set include_image. The doc_id 'part of title/file name' nuance stays with 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+resource ('Return the extracted text of one page of a document') plus the optional image variant, and distinguishes itself from the image-only sibling by describing what text you get per sheet type.

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 concrete usage context: for schematic sheets the text is labels/designators/wire numbers, and you should request the image to read the actual circuit. It stops short of naming get_page_image or an alternative explicitly, so it's clear guidance without explicit sibling 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?

With no annotations, the description carries the full behavioral burden; it usefully discloses the return format and resolution. However, it says nothing about error behavior for invalid pages, whether the image is cached, permissions, or size/pagination implications for large documents.

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 what is returned, followed by the prerequisite step. 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 two-parameter read tool with no output schema, the description covers purpose, output format, and the prerequisite lookup. Minor gaps remain around failure modes and how this differs from sibling image/page tools, but 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 coverage is 100%, so doc_id and page are already documented; the description only adds the notion that page must be located via search first. That is useful workflow context but adds little semantic depth 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?

States a specific verb and resource ('Return the rendered image ... of a document page') and adds concrete output traits (PNG, 1600 px long side) plus example use cases (wiring sheet, hydraulic scheme, drawing). It doesn't explicitly contrast with siblings like get_page or get_document_images, so the boundary is inferred rather than stated.

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 prerequisite workflow: 'Use search or find_sheet to find the page number first,' which tells the agent how to satisfy the required page parameter. It does not say when to prefer this over get_page or get_document_images, so the alternative-selection guidance is incomplete.

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 full burden of behavioral disclosure, and it does not say this is a read-only static lookup, whether the data is live or a fixed schematic, whether results can change, or what the response looks like. It does disclose content scope (module assignments, relay interface, spare capacity), which is modest value, but the behavioral profile of the call remains undocumented.

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

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

A single sentence that front-loads the primary resource (I/O assignment of the line2 modules) before listing secondary content. No filler or boilerplate; the only weakness is that the trailing 'notes on spare capacity' clause adds length without operational detail.

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, non-required static lookup with no output schema, the description covers what data is available, which is the essential part. It is still thin on the two things an agent would want: what the 'all' default returns and whether the response is structured per-module — neither is stated anywhere in the structured fields.

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 partially does: the module names A2, A3, A5 map directly to enum values, and 'relay interface to the high-pressure pump (COM_IN/COM_OUT)' plausibly maps to pump_interface while 'spare capacity' maps to spare. However 'all' (the default) and the selection semantics are never explained, and the mapping is left implicit rather than stated.

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 resource — the I/O assignment of the Elsaco PROMOS line2 modules on CAN bus 2, plus the pump relay interface and spare-capacity notes. That is far more than a restatement of the name and clearly separates it from siblings like machine_overview or get_pump_info. It lacks an explicit verb ('Returns'/'Lists'), but the resource scope is 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?

There is no statement of when to use this tool, when not to, or which sibling to prefer — e.g. the boundary with get_pump_info (which also touches the high-pressure pump) or machine_overview is left entirely to inference. The enumeration of contents implies it is the wiring/IO lookup, but no conditions or alternatives are named.

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 return content (torques, part numbers, source pages), which is genuinely useful. However it says nothing about failure behavior when an id/name is not found, or whether ambiguous name matches return one result or many.

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 zero waste, and the return-value summary is front-loaded before the sibling pointer. Every clause earns its place.

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

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

For a simple one-parameter lookup with no output schema, the description tells the agent what it will get back and how to source valid ids, which is the essential information. Only the miss/ambiguity behavior is left unstated.

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?

Single parameter with 100% schema coverage; the schema already documents 'Procedure id or words from its title'. The description restates that free-text names are acceptable but adds no syntax, matching rules, or format guidance beyond the schema, so baseline 3 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?

States a specific verb ('Return') and resource ('step-by-step maintenance procedure') and enumerates the payload contents (torques, part numbers, source pages). It is clearly distinguishable from list_procedures, which supplies the ids.

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 to list_procedures to obtain ids, and notes that a free-text name also works as input. There is no statement of when not to use it or what happens when a name matches multiple procedures, so it stops short of full when/when-not 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 burden. 'Structured data' implies a read-only retrieval and the domain list clarifies scope, but it does not explicitly state side-effect-free behavior, auth needs, 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?

One front-loaded sentence lists the domains compactly. It is dense but every clause maps to a section, 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?

For a low-complexity getter with an enum section and no output schema, the description enumerates the available data domains well. It still leaves the default 'all' behavior and exact section mapping to the schema, but is broadly 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 single section parameter is an enum with 0% schema description coverage. The description echoes many enum categories but omits 'all', the 60K/40K split, and exact enum names, so it only partially compensates.

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?

Names the exact pump model and says it returns structured data across listed domains, so the resource and verb are clear. It does not distinguish itself from siblings like machine_overview or get_drive_parameters, so not 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?

No sentence states when to use this versus machine_overview/search or when not to use it. The content list implies it is for pump reference data, but no explicit routing guidance is 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?

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the covered documents, counts (126 sheets and 82 pages), and that entries have one-line titles, but it does not mention ordering, pagination, return shape, or that the operation is read-only/safe.

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

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

The description is a single, front-loaded sentence with no filler. It communicates scope, document coverage, counts, and entry format 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 index tool with one optional enum parameter and no output schema, the description gives the essential contents but leaves gaps around parameter behavior (especially the default 'all') and how the index relates to page-level tools like get_page. It is adequate but not fully 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%, and the single doc_id parameter has no schema-level explanation. The description partially compensates by naming the electrical documentation and pump manual, which map to two enum values, but it does not explain the 'all' option or that doc_id selects which index is returned.

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 resource and scope: a complete page/sheet index covering the electrical documentation and pump manual, including one-line titles. It is distinguishable from single-item siblings like get_page and find_sheet because it explicitly describes a complete index rather than one page or lookup.

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 does not say when to use this tool versus alternatives such as list_drawings, find_sheet, get_page, or get_document_images. The word 'index' implies browsing, but there is no explicit usage guidance or exclusion criteria.

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; 'List' reasonably implies a read-only operation and it discloses the returned fields (ids, titles, vendor, language, page counts), which is useful. But it says nothing about result size for 'all documents' — no pagination, truncation, or volume warning — and no permission or auth requirements.

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

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

A single sentence that front-loads the verb and resource, then packs the document types and returned fields into a parenthetical. No wasted words and nothing important 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?

No output schema exists, and the description compensates by naming the returned fields, which is the main thing an agent needs. What is missing is the scale/response-size behavior for an unfiltered 'all documents' listing and any hint of how this relates to the sibling list/search tools.

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 there is nothing for the description to disambiguate; baseline 4 applies. The description correctly signals the call needs no arguments and that filtering is unavailable at this level.

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 ('documents in the knowledge base') and even enumerates the document subtypes covered (manuals, schematics, drawings, procedures, notes), which tells an agent the scope is broad. It does not, however, distinguish itself from overlapping siblings like list_procedures and list_drawings, so the boundary 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 when-to-use guidance and no alternatives are named, despite three obvious siblings (list_procedures, list_drawings, search) that could plausibly be chosen instead. An agent must infer that this is the inventory/browse entry point rather than a targeted lookup.

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, yet it only implies read-only behavior via the word 'List'. It says nothing about whether all drawings are always returned, ordering, pagination, or what 'with key dimensions' means in the response.

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?

It is a single front-loaded sentence, which is good, but the two long parenthetical enumerations of every drawing name inflate the text and largely restate what the return value will contain. A shorter scope statement ('CAD drawings converted from DWG plus PDF drawings, with key dimensions') would convey the same routing information.

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 list tool with no annotations and no output schema, the description conveys the domain scope well but omits the basics an agent would want: that it is a safe read, that it returns the full set unfiltered, and roughly what each entry looks like beyond 'key dimensions'.

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, which is the baseline-4 case; there is no parameter semantics to document. The description's mention of 'key dimensions' in the payload is a small extra signal about output 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 uses a specific verb and resource ('List the CAD drawings ... and the PDF drawings') and enumerates the concrete artifacts covered, so an agent knows exactly what this returns. It does not, however, differentiate itself from siblings such as list_documents or get_drawing.

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 statement of when to use this versus get_drawing (single drawing) or list_documents (broader document listing), nor any prerequisite or exclusion. Usage must be inferred purely from the tool name.

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 does disclose the content domain (specific procedure types an agent can keyword-match), which is real value. It does not state that this is a non-mutating catalog read, whether results are paginated, or what identifiers come back to feed get_procedure.

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 the purpose first and the inventory second. The long parenthetical is justified because the category names are the matching keywords an agent would use, though it could be trimmed slightly.

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 catalog tool with no output schema, a complete-enough definition: the agent knows what will be listed. The only gap is not telling the agent that the returned entries are the inputs to get_procedure, which is inferable from the sibling names.

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 is nothing about argument semantics the description needs to compensate for. No parameter detail is required or missing.

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 maintenance and service procedures available") and the parenthetical inventory makes the scope concrete, distinguishing it from the sibling get_procedure which retrieves a single one. It stops short of naming that sibling explicitly, so the differentiation is inferable rather than stated.

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, when-not-to-use, or named alternative, but the enumeration of procedure categories implies a browse/discovery role that precedes get_procedure. An agent can reasonably infer the usage, though it is left 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?

No annotations exist, so the description carries the full burden. It discloses the content and the fact that it doubles as a document index, which implies a static read-only reference, but it never states that explicitly, nor does it describe the response shape or whether content is machine-static versus filtered.

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 the action instruction last, so nothing is buried. The parenthetical hardware inventory is dense but earns its place by letting an agent recognize the facts it will receive.

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, no-output-schema orientation tool, the description covers both what comes back and how it relates to the document corpus. Only the return format and read-only nature are left implicit, which is a minor 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 no parameters, so the schema baseline of 4 applies. The description correctly adds no parameter chatter and instead explains what the parameterless call yields.

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 precisely what content the tool returns: machine identity (model, control, drives, PLC I/O, pump), installed options, and a map of where each subject lives in the documents. That is far more specific than the title and clearly distinct from the get_/list_ siblings, though it never names an alternative.

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

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

"Call this first" gives an explicit entry-point instruction, which is the right guidance for a zero-argument orientation tool. It stops short of saying when not to call it or which sibling to use next, but the sequencing signal is unambiguous.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that results come from a manual table, that only pure water is modeled, and that it returns a pump pressure-level table, which is helpful. But it does not state what happens for out-of-range pressures or orifice sizes, whether results are interpolated or exact table lookups, or whether it can fail.

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 sentences and front-loads the core purpose: flow calculation and pump capacity check. The multi-orifice hint and the note about returning the pressure-level table are useful and not wasteful, though the sentence about the pump table could be slightly better connected to the main 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?

For a simple three-parameter calculation tool with no annotations and no output schema, the description is largely complete: it states the inputs, the main output (flow and supply check), and an extra output (pressure-level table). It leaves some gaps around output units, edge-case behavior, and the exact form of the supply check, but the core is covered.

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%, so the schema already documents all three parameters in detail, including ranges and units. The description adds some meaning by encouraging multiple orifice entries for multi-head scenarios, but it does not explain whether pressure_psi and pressure_bar are mutually exclusive, how they interact, or what default pressure is used when neither is supplied.

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 a specific calculation: water flow through a pure-water orifice and whether the JETS 3.8/60 pump can supply it, plus a pump pressure-level table. It is distinct from generic pump-info tools, but it does not explicitly contrast itself with the sibling get_pump_info, leaving slight ambiguity about which tool to use for pump 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?

It gives some usage context by suggesting 'Give several orifices to check a multi-head or orifice + leak scenario', which implies when multiple values are useful. However, it provides no explicit when-to-use vs alternatives, no exclusions, and does not say when not to use it versus get_pump_info.

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 well: it discloses the return shape (ranked hits with document id, page number, snippet) and the fact that results span both full-text pages and structured machine data. It omits anything about ranking behavior, latency, or result limits, so it is strong but not exhaustive.

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

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

Three sentences, front-loaded with what is searched and what comes back, then query guidance, then the follow-up action. No filler and nothing repeated from the schema beyond a brief echo of ranking that an agent needs up front.

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?

No output schema exists, but the description explicitly describes the return (ranked hits, doc id, page, snippet), which covers the gap. For a read-only search tool with fully documented params and no annotations, an agent has everything needed to call it and act on results.

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%, so baseline would be 3; the description earns above that by supplying example token types (designators, part numbers, signal names, plain words) that tell the agent what to actually put in 'query'. The doc_id scoping and limit parameters are left entirely to the schema, which already documents them adequately.

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 — 'search every page of every document plus the curated machine data' — and enumerates the data domains covered (axes, PLC I/O, components, pump, procedures, parts, drive parameters). That scope distinguishes it from narrower siblings like search_parts, find_component, or find_sheet without the agent needing to open any 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 concrete query patterns (device designators 'KM1', part numbers '302001-1', signal names 'PSTOP') and explicitly says to 'follow up with get_page / get_page_image to read the full sheet', which is real workflow guidance. It stops short of naming when to prefer search_parts or find_component instead, so no explicit exclusions or alternatives 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that two sources are searched (the AMC price list and the pump manual's spare-parts pages), but says nothing about result ordering, whether matches are exact or fuzzy, or how the `limit` cap behaves in practice.

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 verb and the named catalog, which is good. The long parenthetical enumeration of part categories (intensifier, check valves, seals, on/off valve, ...) is informative but bulky and pushes the second data source to the tail.

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 search tool with no output schema and no annotations, the description covers the key unknowns: what corpus is searched and how to express a query. Only the result-set behavior (ordering, truncation at `limit`) remains unspecified, which is a modest 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 coverage is 50%: `query` is documented with examples, while `limit` (default 20, max 60) is undocumented. The description reinforces the query semantics ('by name or order number') consistent with the schema example but adds no new parameter detail and is silent on `limit`.

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 (search) and a concrete resource (the H2O Jet / PTV spare parts price list plus the pump manual's spare-parts pages), and enumerates part categories so an agent knows the catalog's scope. It stops short of explicitly distinguishing itself from the generic `search` or `find_component` 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?

The phrase 'by name or order number' implies the appropriate query style, but there is no explicit when-to-use / when-not, and no sibling alternative (e.g. `search`, `find_component`) is named. Usage must be inferred from the corpus description.

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