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

The description goes well beyond the annotations by disclosing atomicity, rejection of invalid keys, unsaved changes, and revert-on-preset-reselection behavior. This is critical behavioral context not available from readOnlyHint/destructiveHint alone.

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: purpose and return shape come first, followed by key behavioral caveats and usage guidance. Every sentence earns its place 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?

With only one parameter and no output schema, the description still explains the return value, error semantics, atomicity, persistence behavior, and alternatives. Nothing important is 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 100% and the parameter description is already detailed, including an example, validation behavior, and how to discover keys. The tool description does not need to add parameter semantics, so the baseline of 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?

The description states a specific combined operation: apply config overrides and then slice in one step, and explicitly names the result shape. It differentiates from siblings by referencing set_config, slice_and_wait, and compare_settings as alternatives.

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 an explicit use case: 'Use this to test the effect of a tweak in a single call.' It also clearly routes to alternatives, telling the agent when to use set_config then slice_and_wait, and when compare_settings is more 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?

Annotations already indicate it is neither read-only nor destructive. The description adds important behavioral context about being an async job and needing to poll a status endpoint, which is valuable beyond the annotations. It does not contradict the annotations and clarifies the execution model.

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 entire description is a single, focused sentence with an embedded instruction. It is front-loaded with the core action and adds the necessary async detail in parentheses. 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?

Given the tool has no parameters and no output schema, the description covers everything an agent needs: what it does, that it is async, and how to check completion. It is a complete specification for this simple action.

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?

There are no parameters, so the schema is empty. The description does not need to explain parameter meanings. A baseline of 4 is appropriate since there is nothing to clarify; the tool's behavior is fully described for a parameterless action.

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: 'Auto-arrange all objects on the plate'. It uses a specific verb ('arrange') and resource ('objects on the plate'), and the parenthetical about async job distinguishes it from similar tools like auto_orient by signaling it's a batch operation on all objects.

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

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

The description provides explicit guidance on how to use the tool ('poll get_job_status until idle') and implies the asynchronous nature. However, it does not explicitly mention when to avoid this tool or discuss alternatives such as auto_orient or transform_object, so it falls short of full alternatives 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?

The description discloses that the operation is asynchronous, which is a key behavioral trait beyond the annotations. It also notes that it affects all objects, adding context. The annotations already indicate non-read-only and non-destructive, and the description does not contradict this.

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

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

The description is a single sentence that packs purpose and usage into one line. It is front-loaded and every word adds value, 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?

Given the tool's simplicity (no parameters, no output schema), the description covers the essential behavioral context: it's async and requires polling get_job_status. It might also clarify the return value, but the instruction implies a job handle. Overall, it'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?

The tool has zero parameters, and the schema coverage is complete. Under the rubric, the baseline for 0 params is 4, and the description does not need to elaborate on any parameters.

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

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

The description clearly states the tool's function: auto-orient all objects for printing, with a specific verb (auto-orient) and resource (all objects). This distinguishes it from sibling tools like arrange_plate or transform_object.

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

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

The description provides clear usage context by noting it's an async job and instructing to poll get_job_status until idle. This is a crucial operational guideline, but it does not explicitly state when to prefer this over alternatives like transform_object or arrange_plate.

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

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

Annotations indicate this is a mutating action (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral context: it can unwedge stale 'slicing' states and is safe when idle, which goes beyond the simple annotation flags. No contradiction.

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

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

Two concise sentences cover the main action, an edge case, and a safety note. Every phrase adds value with no waste.

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 parameterless action with no output schema, the description is complete: it states what it does, when it applies (including stale state), and its safety profile. No further context is needed.

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 coverage is 100% trivially. The description doesn't need to add parameter details; the baseline for zero-parameter tools is 4, and the description adequately explains the action.

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 ('Abort') and identifies the resource ('a running slice'), and also explains the secondary purpose ('unwedge a stale slicing state'). It clearly distinguishes from siblings like slice and get_slice_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 provides clear context for when to use the tool (aborting a running slice, resolving stale state) and includes a safety note ('Safe when idle'). It doesn't explicitly name alternatives or say when not to use it, but the usage is well implied.

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?

Beyond the readOnlyHint annotation, the description discloses that it uses object footprint rather than sliced toolpath, excludes skirt arcs/travel/wipe, and is approximate. This is rich behavioral context that helps manage 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?

The description is front-loaded with the core purpose, followed by return info and limitations. It is succinct, well-organized, and every sentence provides value.

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

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

Despite no output schema, the description fully explains return values (per-object fit, bbox, clearance, overflow) and limitations. It is complete for an agent to decide when and how to use the tool.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters; it adds no param-specific semantics, but none are required.

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 estimates whether objects fit in the printable area, including skirt/brim. It distinguishes itself from siblings like get_slice_warnings by emphasizing it is an approximate first-pass estimate.

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 says when to prefer this (fast first-pass) and when to use the alternative (get_slice_warnings for tight margins). Also notes the limitation 'single-instance objects only', helping an agent decide when not to use it.

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

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

Annotations declare readOnlyHint=true, and the description adds the behavior of fetching live config, overlaying proposed changes, running math, and the significance of the blocked verdict. This is valuable, non-contradictory context beyond the annotation.

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

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

Two sentences, front-loaded with the main purpose, followed by a clear action directive. 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 pre-save check tool with one optional parameter and no output schema, the description covers purpose, key behavior, the critical blocked verdict, and its place in the workflow via the save_preset reference. Complete and actionable.

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

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

The schema has 0% description coverage for the single parameter `changes`. The description clarifies it as an 'optional proposed changes' object, giving it meaningful semantics. However, it does not detail the expected structure, though the open-object schema makes this less critical.

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 it is a 'Deterministic pre-save gate' that fetches live config, overlays optional changes, and runs flow/temperature/geometry/cooling math. It distinguishes itself from save_preset by explicitly instructing to run before saving.

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 states 'RUN THIS BEFORE save_preset' and warns 'verdict=blocked means DO NOT SAVE,' providing clear when-to-use guidance and a critical exclusion condition.

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

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

Annotations mark the tool as readOnlyHint=true, and the description adds an explicit guarantee that the original value is restored even on error. This provides useful behavioral context beyond the annotation, though it does not detail the return format of stats/warnings.

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

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

The description is two sentences, front-loaded with the primary action and then a safety note. Every word earns its place; there is no redundant or filler 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?

The description covers the core behavior and non-destructive guarantee, but omits what the collected stats/warnings look like and the role of 'extra'. Without an output schema, the agent lacks clarity on return values, making the description 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%, so the description must compensate. It clarifies that 'values' are iteratively assigned to 'key', giving meaning to these params. However, the 'extra' parameter is completely unexplained, and the expected format of 'values' is not specified, leaving a significant 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?

The description clearly states that the tool iterates over values for a key, slices, collects stats/warnings, and restores the original. This specific verb+resource structure distinguishes it from sibling tools like get_slice_status or get_slice_warnings, which focus on single aspects.

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 clearly implied: use this tool to compare how different values of a setting affect the slicing outcome. It does not explicitly name alternatives or exclusions, but the action of iterating over values makes its purpose distinct from siblings like slice_and_wait or get_slice_warnings.

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?

The description extensively discloses behavioral details beyond the readOnlyHint annotation: variants are applied over the original config and reset between runs, the config is restored exactly, and slice validity is left false. It also explains that all deltas and percentages are precomputed and should be relayed as-is, which is valuable context for the 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 dense but every sentence carries relevant information: purpose, variant format, reset/restore behavior, output contents, recommendation logic, and performance caveats. It is well-structured and free of filler, earning a top score for a tool of this complexity.

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

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

For a 4-parameter tool with no output schema, this description covers inputs, outputs, side effects, and performance guidance. It explains the returned headline/table_markdown/variants structure and the meaning of recommended and recommended_is_dominant, making the tool fully self-contained 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?

With 0% schema coverage, the description compensates well by defining the variants structure, the meaning of changes={}, baseline default behavior, and the effect of detail=True. The timeout parameter is not mentioned, but it is a conventional integer with a default; the other three parameters receive clear semantic explanation.

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

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

The description opens with a specific verb+resource: 'Slice the current plate under several named variants and compare the cost of each.' This clearly states the tool's function and differentiates it from siblings like slice, compare_settings, or slice_and_wait.

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 clear context for when to use the tool (comparing costs across variants) and gives explicit guidance on when to set detail=True and how to present results with many variants. However, it does not explicitly name alternative tools or state when not to use it, 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?

Annotations provide readOnlyHint=true, so the agent knows it is a safe read operation. The description adds valuable behavioral context: it composes principles per situation, never returns preset bundles, and falls back to other tools if empty. This goes beyond the annotation without contradicting it.

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 efficient and front-loaded. The first sentence states the core purpose, followed by a critical usage rule, a fallback note, and a practical recommendation guideline. Every sentence adds value with no redundancy or filler.

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

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

Given the tool's single parameter, read-only annotation, and no output schema, the description covers the essential aspects: what it retrieves, when to call it, its fallback behavior, and how to use its output. However, it does not elaborate on the exact content of 'slicing knowledge' or the structure of the returned principles, which could be 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 schema has one required 'query' parameter with no description (0% coverage). The description partially compensates by clarifying the query can be a topic, symptom, or intent, but it does not specify expected format (e.g., natural language vs. keywords) or provide examples, leaving room for ambiguity.

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 retrieves curated slicing knowledge and saved context notes for a topic, symptom, or intent. It uses a specific verb (retrieve) and resource (slicing knowledge + context notes), and differentiates from siblings by noting it composes principles per situation rather than returning preset bundles.

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

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

Explicitly instructs to 'ALWAYS call before deriving or changing settings for a user goal,' which is a clear when-to-use directive. It also mentions fallback to find_config_keys/web search, providing an alternative path, and gives presentation guidance for recommendations, all of which help the agent decide when to invoke this tool.

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

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

Beyond the destructiveHint/referenceReadOnly annotations, the description discloses that deletion is permanent within the session, cannot be undone through the API, preserves other object ids, and invalidates the last slice. This is exactly the behavioral context an agent needs.

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 core action is first, followed by permanence, prerequisite steps, side effects, and a specific edge case. Every sentence earns its place with no 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 single-parameter tool with no output schema, the description fully covers prerequisites, irreversibility, side effects, and object identity nuances. An agent has everything needed to invoke delete_object correctly and predict the consequences.

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

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

The schema already covers object_id well by specifying it comes from list_objects and not from array index or file name. The description adds extra semantic nuance by explaining how it applies to duplicate_object copies, which goes beyond the schema and supports correct selection of the id.

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

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

The description opens with a specific verb and resource: 'Remove one object from the current plate by id.' It clearly distinguishes this from related object tools like duplicate_object and transform_object, and the object-vs-preset distinction is clear given sibling delete_preset.

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 explicit actionable guidance: call list_objects first to get the id, re-slice afterwards because the last slice becomes invalid, and pass the copy's id when removing a duplicated object. This tells the agent exactly when and how 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?

Annotations already declare destructiveHint=true, and the description adds valuable behavioral constraints: system presets and the currently-selected one are refused. This goes beyond the annotations by clarifying edge cases where deletion will not occur. It could still describe the exact error behavior or confirm permanence, but the provided context is meaningful.

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: a clear action statement and a compact type enumeration. Every word earns its place, and the most important information (delete, user preset, refusals) is front-loaded. 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 simple destructive operation with annotations covering the safety profile, the description is reasonably complete. It states what it deletes, the constraints, and the type values. It does not describe return values, but no output schema exists, and the operation is straightforward. Slightly more detail about consequences (e.g., permanent deletion) would improve completeness, but the current description is 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?

With 0% schema description coverage, the description compensates partially by enumerating allowed values for 'type' (print|filament|printer). The 'name' parameter is not explicitly described, though it is implied as the preset name from the tool's purpose. The added type enumeration provides some meaning beyond the bare schema, but the lack of any name description keeps this from being higher.

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 verb 'Delete' and the resource 'USER preset', and explicitly distinguishes from sibling tools by defining the scope (user presets only) and constraints (system and currently-selected presets are refused). It also provides the type enumeration, making the tool's purpose 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?

The description gives clear context for when to use the tool: when deleting a user preset of a specific type. It implicitly differentiates from siblings like edit_preset or rename_preset by focusing on deletion, and the refusal of system/selected presets acts as a usage precondition. However, it does not explicitly mention alternatives or when not to use it beyond the stated refusals.

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?

Beyond the readOnlyHint annotation, the description discloses valuable behavioral details: the result is cached per slice, the G-code is still downloaded each call to detect a new slice, copies of one object are aggregated, and the return format includes an error shape for missing slices. This gives an agent a realistic model of side effects and edge cases.

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 dense but every clause adds operational value: purpose, output contents, reliability guidance, error behavior, aggregation semantics, caching, and bbox coordinate formatting. It is front-loaded with the core purpose and uses structured semicolon-separated details rather than padding.

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

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

Given no output schema, the description compensates thoroughly by listing what the result contains, including a summary sentence, error response, per-copy footprint behavior, and bbox format. An agent has enough information to invoke the tool and interpret its output correctly.

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

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

There are zero parameters, so the schema fully covers the input surface. With no params to document, the description's additional explanation of output semantics and coordinate convention is a reasonable baseline-plus contribution.

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

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

The description opens with a precise statement: it provides machine-readable plate facts from the last slice's G-code, per object, for answering orientation and placement questions. It enumerates the specific facts it returns (footprint, overhang bands, supports, seams), which clearly distinguishes it from sibling tools like render_plate or diagnose_plate.

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 that this tool is for answering orientation and placement questions 'instead of guessing from Euler angles or a picture,' and says it requires a valid slice with a specific error otherwise. It does not explicitly name alternative sibling tools, but the usage context is clear enough for an agent to select it appropriately.

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?

The description adds meaningful behavioral context beyond the readOnlyHint annotation by stating it is 'Read-only and offline, so it works even when OrcaSlicer is not running.' This tells the agent about availability and side-effect profile. It could also mention error behavior, but the schema already covers unknown keys returning an error.

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 paragraphs: the first defines the tool's output and offline/read-only nature; the second gives usage context and alternatives. Every sentence earns its place, and the most important information is front-loaded.

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

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

For a simple single-parameter lookup tool with no output schema, the description fully compensates by listing the returned fields. It also covers offline behavior, usage timing, and how to find keys. Nothing essential for invoking the tool correctly is 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 100% and the single 'key' parameter is well-documented with examples and guidance to use search_settings or find_config_keys. The description itself does not add much parameter-specific meaning beyond the schema, so the baseline of 3 is 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 opens with 'Authoritative definition of one OrcaSlicer setting' and enumerates exactly what is returned (label, tooltip, type, unit, valid range, enum values, default). This clearly specifies the verb and resource, and distinguishes it from sibling search tools by noting that search_settings is for finding candidate keys.

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 explicitly states the intended use: 'Use it to learn a setting's exact type and allowed values before writing it with set_config or edit_preset.' It also routes to an alternative: 'To find candidate keys by keyword first, use search_settings.' This gives clear when-to-use and alternative 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?

Annotations already declare readOnlyHint=true, and description adds meaningful context: that it aggregates multiple data sources, that slice warnings are only as complete as the fork exposes, and that it's a starting point. This goes beyond the annotation by explaining the tool's synthetic nature and caveats.

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

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

Two sentences, front-loaded with the main purpose, and the second sentence adds important caveats and pairing advice. No wasted words or repetition of schema/annotation info.

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 zero parameters and no output schema, the description is the primary source of semantic info. It lists the key categories (app/slice status, objects, bed settings, warnings), notes the limitations of warnings, and points to complementary tools. This is complete enough for an agent to understand the tool's behavior and decide when to invoke it.

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, so baseline is 4. The description does not need to explain parameters; instead it compensates by explaining the tool's scope and what it checks, enriching the agent's understanding despite the absence of inputs.

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

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

The description uses a specific verb ('diagnose') and resource ('plate'), and enumerates exactly what it covers (status, objects, bed settings, warnings). It distinguishes itself from sibling tools by positioning as a one-call aggregation that avoids chaining status->objects->config.

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 provides when to use ('Start here for why won't this slice / fit'), and names alternatives/partners: 'see get_slice_warnings' for completeness and 'pair with check_placement' for bed fit. This is clear guidance on usage vs. alternatives.

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

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

Annotations indicate non-read-only and non-destructive behavior. The description adds value by specifying the copy is offset from the original, and that it operates by object id. This gives concrete behavioral context beyond the annotation flags.

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

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

The description is a single sentence that front-loads the verb and object, includes the key detail (offset copy), and contains 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 tool with one parameter, no output schema, and non-destructive annotations, the description fully captures the action and outcome. It explains what happens (adds a copy) and how the copy is positioned (offset), making it complete for the tool's complexity.

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

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

Schema coverage is 0%, so the description must compensate for the sole parameter. The phrase 'by id' clearly indicates that object_id is the identifier of the object to duplicate, adding semantic meaning beyond the raw type in the schema.

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

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

The description uses a specific verb ('Duplicate') and resource ('an object on the plate by id'), clearly indicating the operation. It also adds 'adds a copy, offset from the original', which distinguishes it from sibling tools like delete_object or transform_object.

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

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

The description provides clear context: it duplicates an existing object, implying when to use it (when a copy is needed). It does not explicitly name alternative tools or state exclusions, but the context is unambiguous enough for an agent to select this over siblings.

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?

The description goes well beyond the annotations. It discloses that changes are applied atomically, that a physics gate (check_profile_physics) runs first, and that it returns error=physics_blocked for changes that would introduce new failures. It also clarifies that pre-existing failures do not block unrelated edits. This adds significant behavioral context. The destructiveHint is consistent with 'overwrites stored settings'.

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 information-dense. It front-loads the core purpose, then adds essential details (atomicity, physics gate, error behavior) without redundancy. Every sentence adds value, and the structure is well-organized: purpose, execution steps, and validation/error handling.

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 mutation tool with no output schema, the description covers the key aspects: what it does, the atomic apply, the physics gate, and error handling. It does not explain the return value, but that may be less critical for a write operation. The main gap is the ambiguous 'type' parameter, which prevents full completeness. Overall, it is quite thorough for its complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies 'name' (the preset's name) and 'changes' (the settings to edit), but 'type' is left entirely unexplained. The description does not indicate what values 'type' should take, how it relates to 'name', or the structure of the 'changes' object beyond being a nested object. This is a significant gap for an agent to invoke the tool 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's function: 'Edit a named preset's settings and persist them.' It specifies the action (edit), the resource (named preset), and the outcome (persist). The title 'overwrites stored settings' and the detail about saving under the same name further distinguish it from sibling tools like save_preset or delete_preset.

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

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

The description provides clear context for when to use the tool: to modify and persist an existing named preset. It does not explicitly list alternatives or exclusions, but the phrase 'selects it ... saves under the same name' implies editing existing presets rather than creating new ones. Sibling tool names (save_preset, delete_preset, rename_preset) help contextualize, though the description does not directly reference them.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that it matches keys containing the substring, but does not disclose case sensitivity, return format, or pagination. This is acceptable given the annotation coverage, but not rich.

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 one sentence, front-loaded with the action, and includes only essential context. 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?

The tool is simple: one required parameter, read-only, no output schema. The description explains purpose and parameter usage adequately for a search/discovery tool. It does not describe return values, but that is implied for such a tool.

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

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

Schema description coverage is 0%, so the description must clarify the parameter. It explains that 'substring' is what config keys must contain, giving clear meaning. It does not add syntax details like case sensitivity, but for a single string parameter this is sufficient.

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 it finds config keys by substring, using specific verb and resource. The parenthetical about ~600 keys adds helpful context and differentiates it from direct get/set config tools as a discovery aid.

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 to discover config keys among the ~600 available. It does not explicitly contrast with sibling tools like search_settings, so exclusions are absent, but the intended use case is evident.

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 annotations already declaring readOnlyHint=true, the description adds valuable behavioral context by mentioning 'merged config values' and the optional filtering to 'keys'. It does not contradict the annotations and enriches the understanding of what the tool returns.

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 clear sentence, front-loaded with the verb 'Read', and contains no unnecessary words. It is concise and well-structured.

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

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

For a simple read-only tool with one optional parameter and no output schema, the description covers the core functionality and parameter usage sufficiently. The read-only nature is already annotated, and 'merged config values' conveys the expected return content.

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

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

The schema has 0% description coverage for the 'keys' parameter, but the description explicitly states it filters config values by 'keys', giving essential semantic meaning. This compensates well for the lack of schema documentation.

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

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

The description 'Read merged config values' uses a specific verb and resource, clearly indicating a read operation on the merged configuration. It also notes the optional filtering by keys, which distinguishes it from related config tools like get_preset_config or set_config.

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 use for retrieving the effective merged configuration but provides no explicit guidance on when to use this tool versus alternatives like get_preset_config or find_config_keys. There are no exclusion conditions or named sibling tools.

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?

The readOnlyHint: true annotation already indicates a safe read operation. The description adds useful context by specifying that it retrieves text and refers to the 'last successful slice', but it does not disclose behavior such as what happens if no slice has been performed or whether it triggers any side effects. This is additional but not extensive context.

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, concise sentence that front-loads the action and outcome. Every word contributes to meaning, with no redundancy or unnecessary 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?

Given the tool's simplicity (no parameters, no output schema), the description is nearly complete: it explains what is retrieved and in what form. However, it does not specify the behavior when no successful slice exists, which could be a relevant edge case. The readOnlyHint annotation covers the safety profile, so this 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 has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings since there are none. It correctly focuses on the return value instead.

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 'Retrieve' with a clear resource ('G-code') and qualifier ('last successful slice', 'as text'). It clearly distinguishes from sibling tools like 'slice' (which generates) and 'get_slice_status' (which checks progress).

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 'last successful slice' implies this tool should be used after a successful slicing operation, but it does not explicitly state when to use it instead of alternatives or mention exclusions. The usage context is implied rather than articulated.

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

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

Annotations already declare readOnlyHint=true, and the description reinforces this with 'Read-only.' It adds genuinely useful behavior beyond the annotation: the idle/running semantics, the polling requirement, and the reason (settled layout vs mid-move state). No contradicting claims.

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, purposeful sentences. The status meaning is front-loaded, followed by a concrete usage warning; no filler or repeated schema data.

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, read-only status poll with no output schema, the description covers what the tool reports, how to use it, and why the timing matters. An agent has enough to call it correctly without further documentation.

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 100% schema coverage by default, so the description does not need to explain parameters. The baseline 4 applies because there is nothing to document.

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

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

States a specific verb ('get') and resource ('plate's background job worker'), and clarifies it reports whether the worker is 'idle or still running'. This distinguishes it from related status/slice tools by focusing on background job state and its async relationship to arrange_plate and auto_orient.

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

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

Explicitly instructs to poll until idle before reading object positions or slicing, explaining that arrange_plate and auto_orient launch async jobs. It tells the agent when to use the tool and what to avoid (acting on a mid-move state), making workflow selection 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?

Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the side-effect-free behavior ('without selecting it') and the type enumeration, which is useful context. It doesn't disclose return format, error conditions, or prerequisites, but with annotations the bar is lower.

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 the main verb and object front-loaded. The second sentence adds the essential type clarification without any fluff. 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?

Given the low complexity (2 required params, no output schema) and the readOnlyHint annotation, the description covers the core purpose, side-effect behavior, and type restrictions. It could specify the return format in more detail, but 'full settings' is reasonably informative for a simple read tool.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'type' takes print|filament|printer values and implies 'name' is the preset name, which provides some meaning beyond the bare schema. However, it doesn't elaborate on validation, case sensitivity, or how to discover valid names, leaving 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 uses a specific verb ('Read') and resource ('full settings of a named preset') while adding a key qualifier ('without selecting it') that distinguishes it from sibling tools like select_preset and get_config. It also clarifies the allowed types, making the purpose 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?

The description clearly establishes when to use this tool: to inspect a preset's settings without applying it. The phrase 'without selecting it' implies this is a read-only inspection and implies that other tools handle selection, though it doesn't explicitly name alternatives or 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?

Beyond the readOnlyHint annotation, the description discloses significant behavioral details: the stateless predicted-vs-observed check, the 'prediction_check' flag for 'clamped' speed, and the degraded response format on incompatible builds or missing slices. This adds substantial transparency about return values and edge cases.

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 concise and well-structured: it starts with the primary purpose, then details the return data fields, and ends with degradation behavior. Each sentence adds value, with no redundancy or irrelevant 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?

Given no output schema, the description fully enumerates the return types (per-role time/filament, speed/flow ranges, global distributions, per-layer aggregates, prediction_check) and explicitly mentions degradation scenarios. For a zero-parameter tool, this is complete and self-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?

The tool has zero parameters, and the schema coverage is 100%, so there is nothing to add. The baseline for 0 params is 4, and the description compensates by clearly describing the output semantics, which is the relevant aspect here.

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 explicitly states the tool's function: 'Per-feature breakdown of the last slice + a stateless predicted-vs-observed flow check.' It answers 'which feature is the time hog' directly, clearly distinguishing this from sibling tools like get_slice_status or get_slice_warnings by focusing on per-feature time/flow breakdown.

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 when-to-use guidance: 'Answers which feature is the time hog directly instead of trial slicing.' It also states when it cannot be used: 'Degrades to {"available": false, "reason": ...} on fork builds that don't emit the breakdown, or when there is no valid slice.' This gives clear context and 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?

The readOnlyHint annotation already marks this as a safe read, and the description adds useful behavioral context: it is a polling endpoint, 'idle' represents no/cancelled slice, and warning/error details are included. No contradiction with annotations.

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, front-loaded with the most important state semantics, and every sentence earns its place. It explains behavior, caveats, and alternatives 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?

For a no-parameter, read-only status tool without an output schema, the description is complete: it covers states, stats, warnings, polling guidance, and idle meaning. The sibling references prevent misuse.

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, so there is no schema gap to compensate for. The description goes beyond the schema by explaining what the returned state field contains, which is the closest relevant semantic info.

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 exact resource (slice status), the kind of information returned (state, stats, warnings/errors), and the possible state values. It also distinguishes itself from sibling tools by naming what get_slice_warnings and get_slice_breakdown cover.

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 says to poll after slicing to track progress and read results, defines what 'idle' means, and points to siblings for narrower or different data. This gives an agent clear selection 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?

Beyond the readOnlyHint annotation, the description discloses a significant API limitation: the current fork build may report valid with an empty warnings list even when the GUI shows a plate-boundary toast, explaining the fork must populate the plater warning list. This is rich behavioral transparency about potential false negatives.

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 opening sentence is a clear, front-loaded purpose statement. The NOTE adds a necessary caveat but is slightly verbose/run-on; could be tightened while preserving the important behavioral limitation.

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, read-only tool with no output schema, the description covers what it returns (warnings/errors plus validity), why to use it, and a critical edge-case limitation. The caveat about fork behavior makes it a complete, self-contained reference.

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; the description appropriately avoids adding parameter details. Baseline 4 for zero-param tools applies, since there is nothing to explain.

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 returns warnings/errors and validity from the last/current slice, positioning it as the fast 'did anything go wrong' check. This distinguishes it from sibling status/breakdown tools by focusing exclusively on warnings/errors and the fix-cleared confirmation.

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 explicitly frames usage as the fast health check and the way to confirm a fix cleared, giving clear context for when to call. It lacks explicit references to alternatives or when-not-to-use, but the context strongly implies selecting this over heavier status/breakdown endpoints.

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?

The annotation readOnlyHint=true already declares the read-only nature; the description reinforces it and adds meaningful behavioral context: it is a point-in-time snapshot that reports dirty preset keys and whether a slice is running. No contradiction exists.

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

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

Two sentences with no filler. The first sentence front-loads the core snapshot contents; the second provides usage guidance. Every clause adds 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-argument read-only status tool without an output schema, the description covers the return categories and the call context sufficiently. It could theoretically enumerate exact return keys, but the provided categories give an agent enough to decide when to call it.

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 and the schema is empty, so the baseline is 4. The description contributes to output semantics by referencing slice_result_valid but does not need to explain parameters.

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 noun-plus-scope ('Snapshot of the current OrcaSlicer session') and enumerates the exact contents (app/project info, presets, dirty keys, slice validity, running slice). This clearly differentiates it from siblings like get_slice_status, get_config, or get_job_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?

It explicitly directs the agent to 'Call it first' before slicing/editing and gives three concrete triggers: orienting, discovering drifted settings, and checking slice_result_valid. It stops short of naming alternatives or when-not-to-use, so it earns a 4 rather than 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?

Annotations already declare readOnlyHint=true, covering safety. The description adds meaningful behavioral detail: it notes that the id is 'stable', which is valuable for agents that need to persist references across calls. It also explicitly discloses the data fields returned, which is especially useful because no output schema is provided. However, it doesn't discuss ordering or pagination, though that may be unnecessary for a simple list tool.

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

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

The description is a single, front-loaded sentence that directly states the action and the data returned. Every word earns its place; there is no fluff or repetition of the title. The colon and the field list are efficient and scannable.

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

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

For a simple read-only list tool with no parameters and no output schema, the description is complete: it identifies the operation scope (current plate) and the exact fields returned. The readOnlyHint annotation covers the safety profile, and the field list suffices without a formal output schema. No additional context is needed for an agent to use this correctly.

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

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

The input schema has zero parameters, so the baseline is 4. The description provides all necessary semantic context by indicating that it operates on the 'current plate', which is the singular implicit context. No parameter clarification is needed.

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 starts with a clear verb+resource: 'List objects on the current plate.' It enumerates the returned fields (id, name, size_mm, transform), making the purpose unambiguous. It is distinct from sibling tools like list_presets, which list presets rather than plate objects.

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

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

The description clearly implies usage: call when you need to see the objects currently on the plate and their properties. It does not explicitly name alternatives or exclusions, but the scope is well-defined. Sibling tools like set_object_config or transform_object suggest mutations; list_objects is the read-only counterpart, which is evident from context.

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?

Beyond the readOnlyHint annotation, the description reveals key behavioral traits: default filtering to user presets plus the selected preset, the 'noise' of ~400 system presets, and the hidden_system counter for filtered entries. This gives the agent significant insight into expected behavior and output.

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 well-structured: first sentence states the purpose, second explains default behavior and parameter usage, third describes the hidden_system output. No unnecessary words or 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 only two optional parameters, a readOnlyHint annotation, and no output schema, the description covers the essential contextual information: default filtering, parameter effects, and a key return field (hidden_system). It is sufficient for an agent to invoke the tool correctly.

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

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

The input schema has no parameter descriptions (0% coverage), but the description fully explains both parameters: include_system=True for the full list, and type='print'|'filament'|'printer' to restrict to a category. It also clarifies the default behavior associated with leaving parameters unset.

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 lists print/filament/printer presets with flags for system/selected/visible. This specific verb+resource+scope differentiates it from sibling preset tools like save_preset, delete_preset, and select_preset.

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

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

The description provides clear context on when to use the tool (listing presets) and how to adjust behavior via include_system and type parameters. However, it does not explicitly name alternative tools for exclusions or when-not-to-use scenarios, so it misses the 'alternatives' criterion for 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?

The description goes beyond the minimal annotations by disclosing accepted file formats and version-specific STEP support. It also notes that large STEP files can take a minute to tessellate and that the call waits, which gives the agent a realistic expectation of blocking behavior. This is valuable context the annotations do not provide.

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

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

The description is exceptionally concise, packing the core action, supported file types, and a performance caveat into two sentences. Every clause adds value, and the main action is front-loaded, making it easy for an agent to quickly understand what the tool does.

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

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

For a single-parameter tool with no output schema, the description is largely sufficient. It covers the operation, accepted formats, and potential blocking for large STEP files. However, it does not explicitly mention what the tool returns after loading or whether it replaces or adds to the current plate, which leaves a small but non-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?

The schema only defines a 'path' string with no description, so the description adds crucial meaning by clarifying the path is on the OrcaSlicer host and listing how the available formats, suggesting what file types are acceptable. While it could be more explicit about path format (absolute vs. relative), it compensates well for zero schema coverage.

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 loads a model file from a host path onto the current plate, using a specific verb and resource. It distinguishes itself from sibling tools like delete_object or transform_object by focusing on the import action. The added list of supported formats further sharpens its scope.

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

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

The description provides clear context: use this tool to import supported model files from the host into the current plate. It also includes the useful caveat that large STEP files may cause a wait. Although it doesn't explicitly mention alternatives or when not to use it, the purpose is unambiguous enough for a single-purpose load 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?

Beyond the readOnlyHint annotation, the description discloses substantial behavioral details: geometry-first matching, fallback to model_name when the slicer is offline, returning available=false when no outcome store exists, and the dangerous fallback of returning recent prints of ANY model with matched_by='recent' while warning never to attribute them to the current model. This is exactly the kind of edge-case transparency that helps an agent avoid misuse.

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 longer than average but every sentence adds meaningful information about matching, return values, timing, and fallback behavior. The 'Read-only.' sentence is redundant with the annotation, but the overall structure is dense and front-loaded with the core 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 read-only tool with two optional parameters and no output schema, the description covers the main call context, return content, and important edge cases. The only notable omission is the effect of the limit parameter on the number of returned prints, and there is no explicit mention of the output structure beyond listing 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?

With schema description coverage at 0%, the description compensates for model_name by explaining it is used when the slicer is offline and for matching. However, the 'limit' parameter is not explained at all, leaving its behavior to inference from the default value. Partial compensation only.

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 recalls past prints of the current model, matching by geometry or model_name and returning results, verdicts, and settings. It is specific about the resource and action, though it does not explicitly name sibling tools like 'remember' to differentiate them.

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 explicitly says 'Call this BEFORE slicing', giving a clear temporal context for when to use the tool. It does not, however, mention alternative tools or when not to use it, so it stops short of full exclusions and alternative 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?

The description goes beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing storage details: 'local plain files' and 'user-readable and deletable'. This adds meaningful context about the tool's side effects and accessibility, which annotations do not provide.

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 concise: two short sentences with no filler. It front-loads the core purpose and then efficiently packs scope formats and storage behavior. 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 two-parameter tool with no output schema, the description is fully sufficient. It covers purpose, parameter semantics, and behavioral details, leaving no critical gaps for an agent to invoke it correctly.

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

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

With schema coverage at 0%, the description compensates well for the 'scope' parameter by enumerating valid formats ('machine:<printer>/<filament>', 'user', 'project:<name>'). The 'note' parameter is self-explanatory from its name. This adds necessary semantic meaning beyond the bare schema.

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

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

The description clearly states the tool's function with a specific verb ('Persist a context fact') and resource ('for future sessions'). It distinguishes itself from all sibling tools, which focus on slicing/printing operations. The scope examples further clarify its unique role.

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 usage through the scope examples (machine, user, project), indicating when this tool is relevant. However, it does not explicitly state alternatives or when not to use it, though no sibling offers similar functionality. This is clear context without explicit 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?

The annotations only indicate readOnlyHint=false and destructiveHint=false, but the description goes much further: it reveals the copy-then-delete sequence, that the renamed preset becomes active, that unsaved config overrides are discarded, and that the slice becomes invalid requiring re-slice. This is exactly the kind of behavioral context that annotations cannot convey.

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 purposeful paragraphs: the first gives the core mechanism and limitation, the second details side effects. Every sentence adds unique, actionable information without fluff.

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

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

Given the rich schema (100% coverage) and annotations, the description covers the full behavioral picture, including constraints and post-conditions. There is no output schema, so return-value details are not expected. An agent has everything needed to decide when and how to invoke this tool and what to expect afterward.

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?

All three parameters already have descriptive text in the schema (100% coverage), so the description does not need to add parameter meaning. It does not, but the schema alone is sufficient for understanding old_name, new_name, and type.

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 specific operation: renaming a user preset via copy, select, and delete. This distinguishes it from related symbols like delete_preset, save_preset, and select_preset by naming the exact mechanism used.

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 explicitly states when the tool is applicable (user presets only) and when it is not (system presets are read-only). It also compares behavior to select_preset, giving context for expected side effects, though it stops short of naming alternative tools or explicitly saying 'use X instead.'

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

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

Annotations only declare readOnlyHint=true, so the description adds value by explaining view semantics, default frame selection per view, and the visual nature of output. It does not mention potential failure cases (e.g., preview before slice) but discloses the key behavioral distinction between editor and preview. No contradiction with the read-only annotation.

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 well-structured with line breaks and purposeful sections. Each sentence adds information: the opening defines the output, then view definitions, angle list, and frame details. There is no redundant wording, and the format aids scanning.

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 five optional parameters, no output schema, and no enums, this description gives enough context for correct invocation: it explains the two main views, angle options, frame defaults, and when to override frame. The only gap is the width/height parameters, but these are generic and unlikely to cause misuse. Overall it is nearly complete for the tool's complexity.

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

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

With 0% schema description coverage, the description must compensate. It explains 'view' values (editor vs preview), 'angle' options, and 'frame' behavior and defaults. However, width and height parameters are left entirely undocumented; though self-explanatory, they receive no semantic explanation, so the coverage is not complete.

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

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

The description opens with a clear, specific statement: 'Render a PNG picture of the current plate so you can SEE it.' It then distinguishes between editor and preview views, which directly separates it from sibling tools that manipulate models or slicing. The purpose is unambiguous and action-oriented.

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

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

The description provides concrete when-to-use guidance for each view: editor view for checking orientation/contact before slicing, preview view for checking support after slicing. It also explains when to pass the frame parameter explicitly (side view of a small part). However, it does not explicitly mention alternatives among sibling tools or state when not to use this tool, so it falls short of full 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?

Annotations only show readOnlyHint=false and destructiveHint=false. The description adds substantial behavior: never overwrites existing files, applies -2/-3 suffixes on collision, writes into fallback directories based on environment and folder existence, creates the gcode folder if missing, and still saves the file when the outcome store fails, setting outcome_recorded to False. This far exceeds the annotation coverage.

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 long but every sentence carries distinct, necessary information: purpose, return value, default naming, collision handling, directory fallback, and failure behavior. It is front-loaded with the main purpose and then structured logically, with no filler or redundant restating of the title.

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

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

The description is very complete for a tool with no output schema: it covers return path, file-save fallback logic, and failure reporting. However, it doesn't mention what happens when there is no last successful slice (e.g., error behavior) and doesn't fully specify the success response shape beyond 'Returns the saved path'. These are minor gaps against an otherwise thorough definition.

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

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

The schema has one optional filename parameter with no description (0% coverage). The description compensates fully by explaining the default filename pattern (<object>_<timestamp>.gcode), the collision-suffix behavior, and that the filename is the saving name. This adds meaningful semantic detail beyond the schema's bare type/default.

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 saves the last successful slice's G-code and records the slice under a filename, with a specific purpose for later print-outcome tracking. This is a specific verb+resource ('save ... G-code and record the slice'), but it does not explicitly differentiate itself from sibling tools like get_gcode or slice, relying instead on unique context.

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 workflow context: use after a successful slice, then pass the returned path to klipper-mcp's start_print. It also explains naming, collision handling, and fallback directory behavior. It doesn't explicitly state when not to use it or name alternative tools, so exclusions are absent.

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?

The annotations already indicate destructiveHint=true, and the description adds valuable behavioral context: the tool 'overwrites stored settings' (in the title), creates/updates, is visible in the GUI immediately, and handles inheritance via the detach parameter. It also adds the important safety precondition about not saving when verdict=blocked, going well beyond what annotations provide. No contradiction with annotations.

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, front-loaded with the primary action, and every sentence serves a purpose: purpose, parameter meanings, and safety precondition. It avoids wasted words and is easy to parse.

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

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

Given the tool has no output schema and moderately simple parameters, the description covers all essential aspects: what it does, parameter semantics, side effects (GUI visibility), and a critical precondition. It is complete for an agent to decide when and how to invoke it correctly.

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

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

Schema coverage is 0%, so the description carried the burden of explaining parameters. It explicitly defines the allowed values for 'type' ('print|filament|printer') and explains the effect of 'detach=True'. The 'name' parameter is self-evident as the preset's name but lacks explicit uniqueness or format details. This is solid compensation, though one parameter remains implicit.

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 ('Save') and resource ('currently edited settings as a named user preset'), and clearly distinguishes this from sibling tools like list_presets or delete_preset by adding 'create or update, visible in the GUI immediately'. It unambiguously identifies the tool's scope and differentiates it from related operations.

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

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

The description provides explicit preconditions for use: 'Run check_profile_physics first; do not save when verdict=blocked.' It also clarifies the supported type values. However, it does not explicitly discuss alternatives like edit_preset, though 'create or update' largely covers that distinction, so it is clear but not fully exhaustive.

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

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

Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable behavioral details: it searches across specific fields (key, label, tooltip), returns a compact structure (key, label, category, short tooltip), and ranks results with key/label matches first. The 'Offline' note is an additional behavioral trait not present in annotations. This goes beyond what structured fields provide.

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, each earning its place. The first sentence states the action and scope, the second describes the result format and ranking plus an offline note. No fluff, and the key information is front-loaded. This is an example of concise, well-structured documentation.

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 search tool with two parameters and no output schema, the description covers the core purpose, return shape, and an operational detail (offline). It doesn't specify pagination or behavior on no matches, but these are not critical for a search tool of this simplicity. With annotations covering read-only safety, the description is sufficiently complete for an agent to use it effectively.

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 explains the 'query' parameter by stating the search is 'by keyword' and enumerates the fields searched (key/label/tooltip), adding meaning. However, it does not mention the 'limit' parameter or its default behavior (25), leaving part of the semantics undocumented. The description partially compensates but not fully for both parameters.

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 'Search settings by keyword across key/label/tooltip', naming the exact verb, resource, and scope. This immediately distinguishes it as a search tool over settings, and the return format ('compact matches... ranked key/label first') further clarifies its role. It stands apart from sibling tools like 'get_config' or 'find_config_keys' by stating its unique behavior.

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 when you need to find settings by keyword, and what results look like (compact matches, ranked by key/label). It doesn't explicitly name alternative tools or state when not to use it, but the purpose is so well-defined that an agent can infer appropriate usage. No exclusions are mentioned, but the context is sufficiently clear for 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?

The description goes well beyond the annotations by disclosing side effects: it discards unsaved set_config overrides, reverts settings to stored values, and invalidates the last slice, recommending re-slicing. This is exactly the kind of behavioral context an agent needs, and it does not contradict the readOnlyHint/destructiveHint annotations.

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: the first states the core action, the second covers critical side effects and reset semantics, and the third gives practical usage advice. There is no filler, and the most important caveat is front-loaded.

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

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

For a simple two-parameter tool with no output schema, the description is complete: it explains what happens, what data is lost, how to get valid names, when to save first, and the need to re-slice. An agent has everything needed to use the tool correctly.

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

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

The input schema already has full 100% coverage with detailed descriptions for both parameters, including the allowed groups and the requirement for exact names from list_presets. The description adds minimal new parameter-level information, so the baseline score of 3 is 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 opens with a precise action: 'Make the named preset the active one for its group (print, filament, or printer).' It clearly identifies the resource (preset) and distinguishes it from sibling tools like list_presets and save_preset by stating exactly what selecting does.

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 explicit usage guidance: 'Use list_presets for valid names, and save_preset first if unsaved edits should survive the switch.' It also explains that this is 'the canonical way to reset dirty config,' which tells the agent when this tool is the right choice over alternatives.

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

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

The description discloses many behaviors beyond the sparse annotations: atomic rejection of invalid keys, return shape {applied, errors}, visibility in get_status, no writes to preset files, reverting on preset reselect, slice invalidation, and skipping the physics gate. It greatly enriches the agent's understanding of side effects.

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?

Every sentence earns its place. The main behavior and atomicity are front-loaded, then return info, persistence semantics, invalidation, physics-gate caveat, and the alternative tool are each covered in compact sentences. No filler or 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?

For a tool with no output schema, this description is remarkably complete: it explains the return format, persistence model, side effects, prerequisites, and alternatives. The only input parameter is fully documented in the schema, so nothing an agent needs to call this correctly is 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 coverage is already 100%, so the baseline is 3. The description adds behavioral meaning to the changes parameter: invalid keys cause whole-batch rejection, values must match setting types, and percent settings use string form. This goes slightly beyond the schema's own explanation.

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

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

The description opens with a specific verb and resource: 'Apply config changes to the active project as unsaved overrides'. It clearly distinguishes itself from edit_preset (edits stored presets) and implies scope as project-level rather than object-level. The atomic all-or-nothing behavior is also stated up front.

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 explicitly tells the agent when to use an alternative: 'To edit a stored preset rather than the live project, use edit_preset.' It also instructs when to run check_profile_physics for temperature/speed/acceleration/flow keys, and to re-slice after applying. These are concrete, actionable usage rules.

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?

The description discloses behaviors beyond the annotations: passing the same min_z/max_z updates the band, clear=True removes every band, and bands invalidate the last slice requiring re-slicing. The annotations only declare readOnlyHint=false and destructiveHint=false, so the description adds meaningful side-effect context without contradicting them.

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 with the core behavior, followed by update/clear semantics, side effects, and an alternative tool. Every sentence carries operational value 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?

Despite no output schema and sparse annotations, the description covers the object id source, band semantics, clear behavior, side effect on slicing, and the correct alternative tool. Together with 100% schema coverage, an agent has everything needed to call this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds extra semantics by explaining the relationship between parameters: passing the same min_z/max_z updates an existing band, and clear=True removes all bands. This goes beyond the schema's individual field descriptions.

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

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

The description states a specific verb and resource: 'Override the layer height over a Z band of one object', with a concrete example. It also explicitly distinguishes itself from set_layer_height, making the tool's scope immediately clear.

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 explicit when-to-use context ('For a single height across the whole object use set_layer_height instead'), tells the agent to re-slice after use, and directs where to get the object id from list_objects. This fully routes the agent to the correct call.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false, which the description aligns with by describing a non-destructive mutation. It adds valuable behavioral context: what 'adaptive' does, the quality range, and that 'reset' restores uniform layers, going beyond the minimal annotation hints.

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 long, front-loaded with the core purpose, and every clause adds value. It efficiently covers modes, parameters, and aliases without unnecessary 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 tool with three parameters and no output schema, the description adequately covers the main behaviors and parameter semantics. It lacks explicit mention of return values or error conditions, but these are less critical for a simple setter tool and are not required by the schema 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?

With schema description coverage at 0%, the description compensates by explaining the 'mode' values and the 'quality' scale (0..1, higher = finer). It does not explicitly explain 'object_id', but it is naturally implied by 'for one object' in the description and the parameter name itself.

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

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

The description clearly states the tool's purpose: setting variable layer height for one object, with specific modes ('adaptive' and 'reset'). It distinguishes itself from sibling tools like 'set_height_range' by explicitly scoping to a single object.

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

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

The description provides clear context for when to use this tool: to generate an adaptive layer height profile or restore uniform layers. It does not explicitly mention when not to use it or name alternatives, but the mode-based behavior makes the usage context 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?

It discloses atomicity ('nothing applied if any key is invalid'), which is important behavioral context beyond the annotations. The example also clarifies expected input format. No contradiction with readOnlyHint=false or destructiveHint=false.

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

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

Two sentences, front-loaded with the core action, followed by an illustrative example and the atomic guarantee. 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?

Given the tool's moderate complexity (mutation, two params, no output schema), the description covers purpose, example, and atomicity. It does not mention return values or error behavior beyond atomicity, but these are not critical for selection and 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?

With 0% schema coverage, the description compensates by referencing 'by id' for object_id and providing an example for the changes object. However, it does not fully elaborate parameter types or the structure of valid keys/values beyond one example.

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 sets per-object config overrides by object id, with a concrete example. This specific verb+resource+scope distinguishes it from the global set_config sibling.

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 'per-object config overrides' implies this is for object-specific settings, contrasting with global config, but it does not explicitly state when to use this versus set_config or provide exclusions. Usage guidance 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?

Annotations only provide readOnlyHint and destructiveHint. The description goes well beyond them by disclosing asynchronous execution, immediate return, the exact response values, the already_valid behavior, and the conflict condition when a slice is already running.

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 well-structured: core behavior first, response semantics second, and follow-up alternatives last. Every sentence provides operational value with 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 no-parameter, fire-and-forget tool with no output schema, the description fully covers what the call returns, what can go wrong, how to monitor progress, and when to prefer the synchronous sibling. Nothing needed to invoke or interpret the tool correctly is 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?

The tool has zero parameters and schema coverage is complete, so there is no parameter semantics to add. With no parameters, the baseline of 4 applies because nothing is 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?

The description states a specific action ('Start slicing the current plate') and clearly distinguishes this tool from slice_and_wait by emphasizing background execution and immediate return. It also enumerates the possible replies, making the tool's purpose unmistakable.

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 explicitly says to prefer slice_and_wait when finished stats are wanted in one call, and tells the agent to poll get_slice_status or use cancel_slice for follow-up. This gives clear when-to-use and when-not-to-use guidance relative to siblings.

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?

The annotations only say readOnlyHint=false and destructiveHint=false, so the description carries the burden of behavior. It discloses that the call blocks, returns stats and warnings, and avoids re-slicing if the plate is already sliced and unchanged. This adds meaningful behavioral context, though it doesn't elaborate on timeout behavior or what happens to concurrent slices.

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 paragraphs with no filler. The core behavior is front-loaded, and the second paragraph adds valuable sibling routing without redundancy. Every sentence earns its place.

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

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

For a tool with one optional parameter and no output schema, the description covers the blocking behavior, return value, cache semantics, and alternatives. Together with the schema's timeout documentation, an agent has enough to invoke it correctly.

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

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

Schema coverage is 100% and the only parameter, timeout, already has a full description in the schema including default and guidance. The tool description adds no further parameter-specific detail, so the baseline of 3 is 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 states a specific verb and resource ('Slice the current plate'), the blocking behavior, and the output ('final stats and warnings in one call'). It also differentiates itself from siblings by mentioning the non-blocking alternative and the cached-result behavior for unchanged plates.

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 says when this is the usual approach ('when you want the outcome immediately'), and names alternatives: 'use slice then poll get_slice_status' for non-blocking, and 'compare_settings' for sweeping settings. This is clear 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?

Annotations already indicate the tool is not read-only and not destructive. The description adds useful behavioral details like units (mm, degrees), relative vs absolute transformations, and the 'at least one' requirement. Does not disclose side effects or return behavior, but with annotations the bar is lower.

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

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

Two concise sentences contain all necessary information: action, parameter specifications, and usage constraint. No fluff, front-loaded.

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

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

For a medium-complexity tool with no output schema, the description covers the essential invocation details completely. It could mention return values or edge cases, but the core usage and parameter semantics are adequate.

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 compensates fully. It explains each transform parameter: translate (relative mm), rotate (relative degrees), scale (absolute factor), and implies object_id as the target. The array formats are explicitly shown, leaving no ambiguity.

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?

Description clearly states the action (move/rotate/scale) on a specific resource (object by id), distinguishing it from siblings like set_object_config or delete_object. The verb and target are 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?

Provides clear context on when to use (transforming an object) and the constraint to provide at least one transform parameter. Does not explicitly mention alternatives or exclusions, but the usage context is clear.

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

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

Annotations declare readOnlyHint=true, and the description adds behavioral context beyond that by specifying the bounded window and the specific event categories collected. This gives the agent a clear sense of the tool's scope and duration without needing to infer it from annotations alone.

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, well-structured sentence that front-loads the action ('Collect') and packs key details (event types, bounded window) without 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?

The tool is simple (one param, no nested objects, no output schema). The description covers what it does and gives the event types and time bound. It doesn't explain the return format, but for a streaming tool this is less critical, and the readOnly annotation plus bounded window give sufficient 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?

The schema has one parameter 'seconds' with a default of 10, but description coverage is 0%. The description mentions 'bounded window' which hints at the seconds parameter, but it does not explicitly explain that seconds controls the collection duration. This adds some meaning but is still somewhat ambiguous.

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 'Collect' and identifies the exact resource ('live events') with a scoped set of event types (slice.*/config.changed/project.opened). It clearly distinguishes from sibling tools like get_slice_status which provide status snapshots, not streaming events.

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 usage for watching live changes over a bounded window, which provides clear context. However, it does not explicitly state when to prefer this over polling or mention alternatives, so it falls 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.