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

No annotations are provided, so the description carries the full burden of explaining behavior. It lists observable fields but does not state that the tool reads current state, whether it is safe/read-only, what the response shape is, or whether any side effects occur. This is a meaningful gap for a tool with no output schema.

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

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

The description is extremely terse, with no filler or redundant phrasing, and the resource name is front-loaded. However, it is a fragment rather than a complete sentence, so it sacrifices a little clarity for brevity.

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 zero-parameter tool, the listed fields provide reasonable situational context, but the lack of an explicit verb, output schema, or relationship to printer_status leaves some ambiguity about what invoking the tool actually returns. It is minimally viable 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?

The tool has zero parameters and the schema is empty, so there are no parameter semantics to explain. The description adds enough context by indicating that the tool concerns AMS/external spool trays and their attributes, matching the baseline for a no-parameter tool.

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

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

The description identifies a specific resource — AMS / external spool trays — and names concrete data fields: type, color, empty, active tray. It is not a tautology, but it lacks an explicit verb such as 'get' or 'return', and does not directly contrast with printer_status.

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 statement about when to use this tool instead of siblings like printer_status or printer_doctor. The intended use is only implied by the resource name and listed fields, with no exclusions or alternative routing guidance.

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

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

With no annotations, the description carries the full burden. It valuably states that the tool does not print or change printer state, which is the most important safety trait. However, it does not explain what the checks actually do (network calls, CLI invocations) or what the returned diagnostic result looks like.

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 that names the verb first, enumerates the checked subsystems, and ends with an important non-destructive caveat. Every word earns its place and there is 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 zero-parameter tool with no output schema, this description is nearly complete: it names the full scope of checks and explicitly excludes print/state modifications. It could be slightly richer by clarifying expected output or why to prefer it over printer_status, but the essential calling context is present.

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

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

The input schema has zero properties, so there are no parameter semantics to document. The baseline for a no-parameter tool is 4, and the description creates no parameter-related gaps.

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 specifies the verb 'Check' and lists the exact resources the tool inspects (env, LAN ports, MQTT, FTPS, slicer CLI). It also distinguishes itself from state-changing operations by explicitly stating it does not print or change printer state, though it does not name a specific sibling like printer_status.

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

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

The description gives clear context: use this when you need to verify environment/network/protocol/slicer connectivity, not for printing or modifying printer state. It does not name explicit alternative tools, but the non-mutation statement effectively tells an agent when not to choose this tool.

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

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

With no annotations, the description carries the full behavioral burden. 'List files' clearly implies a read-only operation, and 'via FTPS' adds transport context. However, it does not explicitly state side effects, path handling behavior, or FTPS authentication/connection expectations.

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 concise sentence with no filler. The primary action, resource, and protocol are front-loaded, and every word contributes meaningful 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 simple list operation, the description plus the path schema are mostly adequate. However, it lacks usage guidance and parameter semantics, and the absence of an output schema means the agent is not told what kind of file listing to expect. These are gaps but not critical for basic 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?

The description contains no mention of the 'path' parameter, and schema description coverage is 0%. The schema only provides the title 'Path' and a default of '/', so the description offers no additional meaning or usage context for the 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 action ('List'), a clear resource ('files on the printer SD card'), and the transport method ('via FTPS'). This differentiates it from siblings like printer_upload or printer_status without needing to open their 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?

There is no guidance about when to use this tool versus related tools such as printer_upload, printer_status, or printer_doctor. No conditions, exclusions, or alternative selection criteria are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It adds the requirement that confirm must be true, but it does not explain what happens when confirm is false, whether the operation is reversible, or how the tool behaves if no print is currently active. This leaves significant behavioral ambiguity for an agent.

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 short sentences with no filler. The core action is front-loaded, and the necessary condition follows immediately. Every word earns its place.

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

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

For a simple one-parameter pause operation, the description conveys the essential action and requirement. However, without annotations or an output schema, an agent is left without guidance on error scenarios, idempotency, or how pause interacts with the print state machine (e.g., whether a paused print can be resumed). It is adequate but has clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify the critical fact that confirm must be true, which is not obvious from the schema's default of false and non-required status. However, it does not explain the semantic purpose of confirm beyond being a required flag, leaving the boolean's behavior partially unexplained.

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

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

The description states a specific verb and resource: "Pause the current print." This is clear and matches the tool name. It does not explicitly differentiate from the sibling printer_stop, though the semantics of pause vs. stop are inherently distinct.

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

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

The description gives a precondition ("Requires confirm=true") but provides no guidance on when to use this tool versus printer_resume, printer_stop, or other siblings. There is no mention of circumstances that would make pausing inappropriate or alternatives that should be chosen.

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 discloses the most important constraints: confirmation is mandatory and the action must not proceed while a job is RUNNING. It does not detail broader side effects, but the critical safety behavior is clearly surfaced.

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, each earning its place: the action, the confirmation requirement, and the status-check guardrail. The description is front-loaded and contains 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 9-parameter mutating tool with no annotations and no output schema, this is too thin. It covers the core gate conditions well but omits the semantics of several boolean options and the plate parameter, so an agent cannot fully reason about every call option.

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 meaning only to path (local sliced file vs filename already on printer) and confirm (requires true), while the other 7 parameters such as plate, use_ams, timelapse, bed_levelling, and vibration_cali are left entirely unexplained.

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

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

The description states a specific verb and resource ('Start a print') and clarifies the two valid sources: a local sliced file (after upload) or an existing filename on the printer. This clearly distinguishes printer_print from sibling tools like printer_upload, printer_status, and the control commands.

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 provides explicit preconditions: 'confirm=true' and 'Check printer_status first'. It states a hard when-not with 'do not start if a job is RUNNING' and names the sibling tool to consult beforehand. This is actionable guidance for an agent deciding whether to invoke the tool.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It does disclose a key behavioral trait: the operation requires confirm=true, which signals a confirmation gate. However, it does not describe error behavior, reversibility, or consequences of calling with confirm=false, leaving some behavioral gaps.

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

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

The description is two short sentences with no filler. The main purpose is front-loaded, and the parameter requirement is stated directly. Every word earns its place.

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

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

For a simple tool with one optional-looking parameter and no output schema, the description provides the two essential facts: what the tool does and what the caller must supply. It does not cover edge cases such as calling it on a non-paused printer, but the tool's simplicity makes the description mostly 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 input schema only defines confirm as a boolean with default false and no description. The description adds crucial semantics by stating 'Requires confirm=true,' telling the agent the exact value needed for the call. This compensates for the 0% schema description coverage, though it does not explain the meaning of the confirmation beyond the requirement.

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: 'Resume a paused print.' This clearly identifies the tool's function and distinguishes it from sibling tools like printer_pause and printer_stop. The addition of 'Requires confirm=true' further clarifies the intended action.

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

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

The description implies when to use the tool: when a print is paused and needs to be resumed. However, it does not explicitly state when not to use it or mention alternatives such as printer_status or printer_doctor. The confirm requirement is a usage constraint, but the broader context of choosing this tool over siblings 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 that confirmation is required, implying a guarded mutation, and lists the allowed profiles. It does not state side effects, whether the change applies immediately, or what happens if confirm=false. This is modest disclosure, not full transparency.

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 compact sentences with the core action and allowed values first, followed by the critical requirement. Zero verbose or redundant content.

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

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

For a two-parameter tool with no output schema the description covers purpose, allowed values, and the key confirmation requirement. It is sufficient for an agent to make a correct call. Missing use-case routing and deeper behavioral details are minor given the tool's simplicitiy.

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. It adds meaning by enumerating valid values for profile (silent, standard, sport, ludicrous) and specifying that confirm must be true, correcting the schema's false default. Could explicitly name the profile parameter, but the intent is clear.

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: 'Set speed profile', and enumerates the four valid profiles. This clearly distinguishes it from sibling tools like printer_pause, printer_resume, and printer_stop, which are all dfferent actions.

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 guidance or exclusions against alternatives. However, 'Requires confirm=true' gives a clear invocation condition. The use case is implied by the name and verb, but no direct comparison to sibling tools is provided.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It goes beyond a simple status read by revealing that fresh=true triggers a full P1S pushall and warns against tight-loop calls, which signals cost/rate-limit implications. It does not explain the default caching behavior or potential errors, but for a status tool the disclosed behavior is meaningful and helpful.

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

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

The description is two sentences with no filler. The first sentence front-loads what the tool returns, and the second delivers the crucial parameter caution. 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 one-optional-parameter status tool with no output schema, the description covers the key response fields and the one behavioral caveat that matters. It does not describe response formatting or error cases, but the listed fields are enough to understand return value expectations. The tight-loop warning adds practical operational context.

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

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

Schema coverage is 0%, so the description is the only explanation of the fresh parameter. It explains both the effect (requesting a full P1S pushall) and a usage constraint (avoid tight loops). It does not explicitly state what happens when fresh is false, but the schema default of false plus the conditional phrasing provide enough context for an agent to act correctly.

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

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

The description clearly states the tool reports the current P1S state with concrete fields: idle/printing status, job name, progress, temps, and remaining time. It does not use an explicit verb like 'get', but 'Current P1S state' unambiguously identifies the resource and operation. It is implicitly distinguished from sibling action tools like printer_pause or printer_resume, though it does not explicitly name a sibling 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?

The description implies the tool is for reading live printer status and gives specific guidance about when to set fresh=true and to avoid calling it in a tight loop. However, it does not explicitly state when to prefer this tool over alternatives such as printer_doctor or printer_ams, nor when not to use it. The usage guidance focuses on the parameter rather than tool selection.

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

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

With no annotations, the description must reveal behavioral traits itself. It discloses that the operation requires explicit confirmation, which is useful. However, it does not mention whether stopping cancels the job irreversibly, what happens to the print state, or whether the action can be undone.

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

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

Two short sentences with no filler. The core action comes first, followed immediately by the critical safety requirement. Every word earns its place.

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

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

For a one-parameter tool, the description covers the essential action and confirmation. But it leaves ambiguity about the difference between stop and pause, and it does not describe the result of stopping or any side effects. Given the sibling list includes printer_pause and printer_resume, this ambiguity is a meaningful 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 for the confirm parameter. It does so by explicitly stating that confirm=true is required, overriding the schema default of false and clarifying the parameter's behavioral meaning.

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

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

The description clearly states the action ('Stop the current print') and the target resource. However, it does not distinguish 'stop' from the sibling 'printer_pause', so an agent might not know whether stopping is permanent or resumable.

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

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

The description gives a clear usage requirement: confirm=true is mandatory. It does not explicitly say when to prefer this over printer_pause or printer_resume, but the safety constraint and action are stated clearly enough for basic invocation.

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 available, the description carries the burden of behavioral disclosure. It usefully discloses FTPS transport and the mandatory confirm=true gate, but does not state whether an existing remote file is overwritten, whether authentication is needed, or what happens on failure. Key side effects remain 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?

One sentence that front-loads the action, target, file types, and the critical confirm requirement. There is no filler; every phrase contributes to the agent's decision and invocation. The compactness is a strength, not a gap.

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 upload with no output schema and no annotations, the description covers the core operation and the important confirm gate. However, remote_name semantics, overwrite behavior, and post-upload effects are missing. It is adequate for a straightforward call but leaves room for guessing.

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 needed to compensate. It partially does by implying local_path is the file to upload and by requiring confirm=true, but it never explains remote_name or its null default. This is insufficient for the three parameters present.

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 the specific operation ('Upload'), target ('printer'), allowed file types, and transport protocol (FTPS). This clearly separates it from read/control siblings like printer_status and printer_pause, though it does not explicitly name 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?

Gives a clear trigger: call this when a sliced file needs to be transferred to the printer. It does not discuss when to prefer printer_print or slice_model_file, and there are no explicit exclusion criteria. The 'Requires confirm=true' note is a precondition rather than a selection guideline.

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 the confirm=true guard, the output format, and the auto-discovery fallback for profiles, which is useful. However, it does not describe side effects such as files written, potential failure modes, or what happens when required profiles are 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?

The description is compact and front-loaded: the primary purpose and the critical confirm requirement appear first, followed by the profile scenarios. Every sentence adds information, though the second paragraph is a bit dense.

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

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

For a tool with six parameters, no output schema, and no annotations, the description covers prerequisites but omits parameter meanings, return/result behavior, and failure handling. It gives the agent enough to attempt a simple case but not enough to use all options confidently.

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 should compensate, but it only meaningfully explains confirm=true and the source-format implications. plate, orient, output, and arrange are left entirely to the agent's inference from their names.

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

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

The description names a specific action ('Slice'), the accepted input formats ('STL/3MF'), and the concrete output ('.gcode.3mf'), so an agent can tell exactly what the tool does. It is clearly distinct from the printer_* sibling tools, which concern printer control rather than slicing.

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 distinguishes two usage scenarios: STL/STEP inputs require machine/process/filament JSON, while a project .3mf with embedded settings does not, and it flags that confirm=true is mandatory. It does not explicitly state when not to use the tool, but the situation-dependent guidance is concrete and actionable.

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