Kiln
Server Quality Checklist
Latest release: v1.3.1
- Disambiguation1/5
Dozens of tools overlap so heavily that selection is genuinely ambiguous: run_quick_print/slice_and_print/run_reslice_and_print/print_plate_object all slice+print, eight-plus estimate_* variants split near-identical estimates, and families like validate_*/monitor_*/analyze_* each contain 5-10 near-synonyms. The many cross-referencing docstrings admit the problem rather than solve it, and kept deprecated aliases (print_status_lite, render_model_preview, repair_mesh_advanced) add further confusion. Even knowing the domain, an agent will routinely pick the wrong tool.
Naming Consistency3/5Mostly snake_case verb_noun style is used consistently (start_print, pause_print, list_webhooks, get_material, set_fan), and compound pipeline tools share understandable prefixes like run_/slice_/generate_. But the pattern is diluted by informal outliers (check_my_tier, hand_back_printer), near-duplicate ordering (firmware_status vs check_firmware_status), plural/singular variations (cancel_queued_job vs cancel_queued_jobs), and retained deprecated names. Recognizably the same language throughout, but with enough drift that a strict pattern can't be assumed.
Tool Count1/5468 tools is an overwhelming, unmanageable surface — roughly nine times the 50+ threshold that already indicates extreme excess. No single-purpose server can justify this many entry points; the real value is concentrated in the core print/slice/monitor/design workflows that would be well-served by 30-50 tools at most. This is the definition of a shotgun approach to tool surface.
Completeness3/5The print → monitor → slice → design → order lifecycle is exhaustively (often redundantly) covered with almost no dead ends: every operation exists in at least one form and cross-references abound (submit_job → job_status → queue_summary is a complete example). However, this is completeness through accumulation rather than coherence, and huge swaths of the surface are effectively gated behind paywalls (Pro/Business/Enterprise), so the claimed coverage is often aspirational. The surface area is so broad that 'coverage' stops meaningful as a differentiator.
Average 4.1/5 across 446 of 468 tools scored. Lowest: 2.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 3 of 14 community issues answered or closed in the last 6 months
- 966 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only says 'Check the status', implying read-only, but it does not confirm idempotency, side effects, or any behavioral traits like required authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, but it lacks important context. It is not overly wordy, but it sacrifices comprehensiveness for brevity. A score of 3 reflects that it is minimally concise without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description should explain what the response contains (e.g., possible statuses, error conditions). It fails to do so, leaving the agent without critical information to handle the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description needed to add meaning to the parameter 'model_id'. It merely restates it as 'The model ID of the feedback loop', which adds no value beyond the schema's 'Model Id' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool checks the status of a generation feedback loop using 'Check the status'. However, it does not distinguish itself from the sibling tool 'get_feedback_loop_status', which appears to have a very similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided about when to use this tool versus alternatives or any context on prerequisites. The description solely states the action without any usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action and lists parameters, with no mention of side effects, permissions, rate limits, or whether the plan is generated on call. This is insufficient for a tool that likely returns a substantial plan object.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and well-structured with a clear one-line summary followed by a formal Args section. Every sentence serves a purpose, though the parameter descriptions are minimal. It could be slightly more informative without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description does not explain the return value (what the recovery plan contains) or any prerequisites. For a tool that provides a plan for recovery, crucial context is missing, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by enumerating valid values for 'failure_type' (nine options), which is not present in the schema (no enum defined). However, 'printer_name', 'has_power_loss_recovery', and 'has_filament_sensor' receive no additional explanation beyond the parameter names and types already in the schema. Since schema coverage is 0%, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to get a recovery plan for a specific failure type. It identifies the resource (recovery plan) and the action (get). This distinguishes it from sibling tools like 'plan_failure_recovery' which suggest creation or planning. However, it doesn't specify if the plan is retrieved from storage or generated on the fly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Among many recovery-related siblings (e.g., 'plan_failure_recovery', 'start_print_recovery'), the description does not provide criteria for selecting this tool. The missing context makes it hard for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose whether the operation is read-only, requires authentication, or has side effects. It only states 'Retrieve,' leaving behavioral traits like idempotency and data sensitivity unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences and front-loaded purpose. However, the 'Args' section is redundant with the schema and consumes space that could be used for more useful guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should mention what the tool returns (e.g., design data or metadata) and possible error conditions. It provides none, leaving an agent unaware of the response format or failure scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds that 'design_id' is 'The cached design's identifier,' but does not explain how to obtain it, its format, or any validation rules. The schema only defines type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Retrieve' and resource 'cached design' clearly indicate the tool's function. The name differentiates from siblings like 'list_cached_designs' (list vs single) and 'cache_design' (store vs retrieve), though it does not explicitly contrast with 'get_cached_model'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'list_cached_designs' or 'cache_design'. The description omits any context about prerequisites or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states it gets status, implying a read operation, but omits any side effects, auth requirements, or output details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes an 'Args' section. It is mostly efficient, though the docstring format adds a line for 'Args' which could be more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many related recovery tools, the description lacks context on possible status values, how to interpret them, and how this tool fits into the recovery workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The parameter description 'The session_id to query' is minimal and does not explain what a session_id is, where to obtain it, or its expected format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('recovery session status'). It is specific enough to distinguish from unrelated tools, but does not explicitly differentiate from sibling recovery tools like 'get_recovery_plan' or 'get_recovery_statistics'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't mention that the session must be started first or that this is for monitoring progress.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states it gets 'detailed information' without specifying what that entails, any side effects, or permissions needed. Vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, one sentence. However, it could be expanded slightly without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and low schema coverage, the description fails to specify what 'detailed information' includes, making it incomplete for an agent to fully understand the tool's return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter 'name' is described as 'Plugin name,' which adds minimal value beyond the schema's title. With 0% schema description coverage, the description should explain format or constraints but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a specific plugin, using a specific resource. It implicitly distinguishes from 'list_plugins' but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives like 'list_plugins'. No prerequisites or context given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as response format, error handling, or potential side effects. It is a read operation but lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences plus parameter list. Purpose is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema. Description lists only three example metrics, not a comprehensive set. Lacks details on return format or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter name 'printer_name' without adding meaning beyond the schema. With 0% schema description coverage, the description does not compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets aggregate statistics for a printer, listing specific metrics. It is a specific verb+resource combination, but does not explicitly distinguish from sibling tools like 'printer_trend_analysis' or 'printer_usage_summary'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Among many printer-related siblings, no usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'caches for faster access and version tracking' but does not disclose behavioral traits like whether it overwrites existing caches, requires authentication, has storage limits, or if version tracking is automatic. The description is too brief to provide meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences plus parameter list) but lacks structure. It front-loads the purpose, which is good, but the parameter descriptions are in a list format inside a docstring, which is acceptable. However, it could be improved by including a brief example or clarifying the output. It earns its place but barely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no annotations, and no output schema, the description is incomplete. It does not explain what happens after caching (e.g., return value, side effects like file storage location), whether the operation is reversible, or any errors that might occur. For a tool with moderate complexity, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 lists all three parameters with basic explanations: 'Path to the design file to cache', 'Human-readable label for the cached design', 'Intended material for this design'. These add meaning beyond the schema's titles, but are still minimal. For example, 'label' and 'material' could benefit from constraints or examples. Baseline 3 is appropriate given the descriptions are present but not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: caching a 3D design file for faster access and version tracking. It uses a specific verb ('Cache') and resource ('3D design file'), and the mention of 'faster access and version tracking' differentiates it from general caching utilities. However, it doesn't explicitly distinguish from similar tools like 'cache_design_with_source' or 'cache_model', but the context helps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., cache_model or cache_design_with_source). It also lacks any 'when not to use' or prerequisites. The tool appears to be for storing a design for faster access, but no context is given about when caching is appropriate or when to use other caching tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'check', implying read-only, but does not confirm idempotency, auth needs, or rate limits. Lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Short description with purpose at the beginning. The docstring format for args is clean. Could be slightly more structured but overall concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema and description does not mention return values or status format. For a status tool, the output structure is important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains both parameters: job_id as the ID from generate_model, and provider as 'meshy' or 'openscad'. Adds meaning beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it checks the status of a model generation job, with specific verb and resource. However, it does not distinguish from sibling tools like 'job_status' or 'provider_job_status' that may serve similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only states what it does, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only versus destructive nature, authentication requirements, or side effects. The tool is potentially mutative (recovery steps), yet no safety or permission context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the main purpose. However, the Args section is redundant with the schema, making it slightly less concise but still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, and the description does not explain what the returned G-code steps look like or any error cases. Given the simple parameter set, more context about the response format would aid the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds basic meaning to the 'session_id' parameter: 'The session_id to get steps for.' This is minimal and does not specify format, allowed values, or constraints beyond the required flag.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the G-code/commands for executing a recovery,' specifying the verb and resource. It distinguishes itself from sibling tools like 'get_recovery_plan' and 'get_recovery_session_status' by focusing on the G-code steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'get_recovery_plan', 'plan_print_recovery'). It lacks context or exclusions, offering only a basic statement of function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only says 'Check the status' without disclosing side effects, required permissions, or what 'status' entails. Minimal behavioral info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus argument listing. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, so description must explain return values. It does not mention what status information is returned or possible error conditions. Incomplete for a status-checking tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%. The argument description 'The order ID to check' adds no meaning beyond the parameter name and type. It does not explain format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check the status of a print service order,' which is a specific verb-resource combination. It distinguishes from sibling tools like cancel_print_service_order or create_print_service_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the tool configures and starts cloud sync, but omits critical details like side effects (e.g., overwriting existing config), blocking behavior, or error handling. This lack of transparency could lead to unexpected outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear one-line purpose followed by a structured args list. It is front-loaded with the key action. The format is efficient, though it could be slightly more detailed without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a configuration tool that likely has side effects and dependencies, the description is incomplete. It does not mention whether the sync runs in the background, whether network connectivity is required, or what happens on failure. Related sibling tools suggest a need for usage context that is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's args section adds minimal meaning beyond the input schema, such as 'Base URL of the cloud sync endpoint' for cloud_url, which is slightly more descriptive than the schema's title 'Cloud Url'. However, with 0% schema description coverage, the description should provide more comprehensive explanations, especially for required parameters like api_key.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Configure and start cloud sync', which clearly identifies the action (configure and start) and resource (cloud sync). However, it does not explicitly differentiate from sibling tools like 'cloud_sync_now' and 'cloud_sync_status', which could cause confusion about when to use this tool instead of those.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not specify that it is for initial setup, whether it can be called multiple times, or any prerequisites. Without such guidelines, an agent may misuse the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits like irreversibility, permissions required, or side effects. The agent is left uninformed about the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, but it includes a redundant 'Args' section that duplicates the schema. While not verbose, it could be more efficient by omitting the repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete operation, the description is minimally adequate but lacks important details like error handling (e.g., profile not found) or confirmation of success.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only restates the schema property ('Profile name to delete') without adding meaningful context, type, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (delete) and the resource (saved local shipping profile). It is specific and distinguishes from sibling tools like save_shipping_profile and list_shipping_profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus alternatives, such as listing profiles first or saving before deleting. The agent receives no context about prerequisites or consequences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits like side effects, permissions required, or whether it is read-only. For a tool that exports data, safety and mutability are unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, and uses a clean list for args. Every sentence adds value; no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description does not explain what the result looks like (file, string, config object). It also lacks error handling info or prerequisites beyond the plan source. More detail on output format and constraints is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning to both parameters: explains plan_data comes from generate_adaptive_slicing_plan, and slicer lists allowed values. However, plan_data structure is not detailed beyond being a dict.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and resource 'adaptive slicing plan', and distinguishes it from siblings like generate_adaptive_slicing_plan by specifying it converts to slicer-compatible configuration, listing specific slicers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after generating a plan via the mentioned function, and provides context on slicer targets, but no explicit when-not-to-use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get the status' without disclosing any behavioral traits like authentication requirements, error behavior, or whether it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes an Args block, but the format is somewhat redundant for a single parameter. It could be more streamlined, but it is not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter, no output schema, and numerous siblings, the description is too sparse. It does not explain the response format, possible statuses, or how this tool differs from similar status tools, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats 'job_id: The orchestrated job's identifier' but the input schema already provides the parameter name and type. With 0% schema description coverage, the description adds no meaningful semantic value beyond what the schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the status of a fleet-managed print job' with a specific verb ('get') and resource ('status of a fleet-managed print job'). It distinguishes from sibling tools like 'job_status' and 'provider_job_status' by explicitly mentioning 'fleet-managed'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'job_status' or 'fleet_submit_job'. There are no contextual hints about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It only says 'return details' without mentioning side effects, permissions, or read-only nature. Critical behavioral info is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the purpose. Every word serves a clear function, no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter, the description is too minimal. It fails to explain what 'details' include, error conditions, or output format, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 'cache_id: The unique cache ID of the model,' adding meaning beyond the schema title. However, it lacks detail on format or source, so it is minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return details for a specific cached model,' which specifies the verb and resource. It distinguishes from siblings like 'list_cached_models' and 'delete_cached_model' but could be more explicit about what 'details' entails.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context about prerequisites or scenarios, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the basic function and parameters, without mentioning read-only nature, pagination, default ordering, or any side effects. This is insufficient for a complete understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded with the purpose followed by arguments. Every word is used efficiently, though it could still include more useful information without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters, no output schema, and no annotations, the description is incomplete. It does not explain what 'cached designs' are, how the list is ordered, or whether the result set is bounded. This leaves significant gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides brief explanations for 'material' (with examples) and 'limit' (maximum results). This adds value but lacks details like default behavior, case sensitivity, or accepted formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List cached designs' with optional filtering by material, which is a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'list_cached_models' or 'search_cached_models', which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention when not to use it or any conditions for using filtering. The description lacks explicit when-to-use and when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic action without indicating if the deletion is permanent, what permissions are required, or what happens on error.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with one sentence and parameter list. Could benefit from a brief note on return value, but for a simple tool it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a single required parameter, the description covers the basic operation but lacks details on return values, error handling, or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description adds no additional meaning beyond the schema's parameter title and type, merely repeating 'spool_id' as unique identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Remove') and the target resource ('a filament spool from inventory'). It distinguishes from sibling tools like add_spool or list_spools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites, and no mention of 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries the full burden of disclosing behavior. It only states the precondition and the cancellation action, omitting details on side effects, idempotency, error handling, or permissions, which are critical for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with no extraneous words. The precondition and parameter are stated concisely. However, the parameter description is redundant, slightly reducing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cancellation tool with one parameter and no output schema, the description fails to mention return behavior, error conditions, or how to obtain the order_id. It lacks completeness for an agent to reliably use the tool without external context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no value beyond the schema for the 'order_id' parameter, merely restating its purpose ('to cancel'). With 0% schema coverage, the description was expected to provide format, constraints, or context, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Cancel) and the resource (print service order), with a specific precondition that only unstarted orders can be cancelled, effectively distinguishing it from sibling tools like cancel_print or cancel_job.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear condition for when the tool can be used ('orders that have not started printing') but does not explicitly guide when to choose this tool over alternatives like cancel_print or cancel_job, nor does it mention 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses monitoring aspects and anomaly detection, which is useful. But with no annotations, it lacks details on side effects (e.g., whether it's read-only, requires locking, or has rate limits).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Short and front-loaded with the action. However, the args section is redundant with the schema. Still efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers basic purpose but misses return value format, prerequisites, and behavioral context. Adequate but incomplete for a comprehensive tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter with 0% schema description coverage. The description adds 'Name of the printer to check,' which is minimal and just restates the schema. Does not compensate for the lack of schema detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a comprehensive health check on a printer, specifying what it monitors (temperature stability, print progress, anomalies). However, it does not differentiate from siblings like 'check_print_health' or 'printer_status' which may have similar functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Absence of when-not to use or prerequisites. With many sibling tools, explicit usage context is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, description only says 'decrypt and return', lacks disclosure of security implications, authentication needs, or side effects for a sensitive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short but includes redundant yaml-style Args block; could be streamlined. First sentence is clear and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing critical context for a security-sensitive credential retrieval tool, such as usage guidelines and behavioral transparency; overall insufficient for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds doc for parameter 'credential_id: The credential's unique identifier', providing basic semantics beyond schema field title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Decrypt and return a stored credential', specific verb and resource, distinguishes from sibling tools like 'store_credential' and 'list_credentials'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use vs alternatives, no exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions validation checks but does not disclose if the tool modifies the file, whether it is read-only, or what the response format is. Without annotations, the description should provide more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening sentence, a bulleted list of checks, and an Args section. The Args section slightly duplicates the schema but overall is well-structured and not verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain what the validation returns (e.g., pass/fail, detailed errors). It also omits prerequisites like file existence. For a single-parameter tool, more detail on outcomes is expected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains that file_path is a path to an STL, OBJ, or GLB file, adding value beyond the schema's simple string type. With 0% schema description coverage, the description effectively compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a 3D mesh for printing readiness, listing specific checks (file format, dimensions, polygon count, manifold). This is a specific verb+resource combination, but it does not explicitly distinguish from sibling tools like 'validate_and_prepare_mesh' or 'analyze_mesh_geometry'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'repair_mesh', 'validate_and_prepare_mesh'). The description lacks context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It does not disclose side effects, permissions, or whether the operation is read-only. It only states the action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single clarifying sentence and an args list. No unnecessary words, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description is adequate but incomplete. It fails to describe the return value or the meaning of the fields mentioned, which an AI agent would need to correctly use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning: it labels the parameter as 'template identifier'. With 0% schema coverage, this provides some context, but does not specify format, valid values, or how to obtain it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets one template's public discovery and safety-floor fields. It specifies the resource (template) and the action (get). However, it doesn't explain what 'public discovery' and 'safety-floor' fields are, which could be ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list_design_templates or search_design_templates. The description does not mention prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the tool lists summaries, but does not confirm it is a read-only operation, nor does it mention any side effects or authoritative requirements. The description is minimal in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose. No fluff or redundancy. It is front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema, no annotations), the description is incomplete. It does not explain what a 'discovery summary' contains or the output format. This leaves agents without enough context to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter meaning. Baseline is 4 per guidelines for 0-parameter tools. The description does not add any parameter info, which is acceptable since no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists public design-template discovery summaries. It uses a specific verb ('List') and resource ('public design-template discovery summaries'). However, it does not explicitly distinguish from the sibling 'list_design_templates', which likely has a similar purpose, leading to ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool over alternatives like 'search_design_templates' or 'list_design_templates'. No context is given about the data being public-only or when to prefer this over other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It mentions planning and distribution but does not disclose side effects (e.g., resource reservation, state changes), auth needs, or whether it is read-only. The lack of behavioral context leaves the agent uncertain about consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two lead sentences and an 'Args' block. It front-loads purpose. Minor redundancy between first and second sentence, but overall no wasted words. Could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (3 params, no output schema, no annotations), the description lacks critical context. It does not explain the return value (e.g., a plan ID, status), error conditions, or post-conditions. Incomplete for an agent to safely invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's 'Args' block adds basic meaning to each parameter. File_path, copies, and material get one-line definitions. However, it does not specify formats, constraints (e.g., copies > 0), or valid material values. Adequate but not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('plan') and resource ('parallel printing of multiple copies across printers'). It distinguishes from siblings like 'multi_copy_print' by emphasizing distribution across printers for maximum parallelism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The description does not mention any prerequisites, exclusions, or comparison to siblings like 'multi_copy_print' or 'plan_failure_recovery'. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states that the tool confirms and starts processing, which likely mutates state, but offers no details on side effects, irreversibility, permissions, or what 'start processing' entails. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action. It uses a structured Args section. However, the Args section mostly repeats the schema's parameter names, but it adds value by providing source for order_id. Could be more concise without repeating schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about return values or confirmation details, especially since no output schema exists. It is part of a workflow with many siblings but does not explain the full context or sequence. Missing return info and workflow steps reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 order_id comes from create_print_service_order and lists possible option values. This adds meaning, but does not explain what each option does or provide further context. It adds value but is not comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool confirms a print service order and starts processing. The verb 'confirm' and 'start processing' are specific. However, the tool name 'print_service_quote' suggests a quote, but the description indicates confirmation and processing, causing slight mismatch. Still, the purpose is distinct from siblings like create_print_service_order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after create_print_service_order by referencing that tool for the order_id. It also lists possible options. However, it does not explicitly state when to use this tool vs alternatives like fulfillment_quote, nor does it provide exclusions or prerequisites beyond having the order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'check the progress' without disclosing if it is read-only, what side effects exist, or what constitutes progress (e.g., status string, percentage).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (two lines) but includes an 'Args:' section that is somewhat redundant for a single parameter. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description does not explain what the return value represents (e.g., status, percentage). For a simple tool, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so parameter details rely on description. It adds 'The plan ID returned by submitting a split plan,' which tells where to get the ID but lacks format or constraints. Baseline 3 for one parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check the progress of a split plan,' which is a specific verb+resource. It distinguishes from siblings like cancel_split_plan and plan_assembly_split.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It implies use after submitting a split plan, but does not explicitly state prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions validation but does not disclose return format, side effects (e.g., read-only), error behavior, or required permissions. For a mutation-free validation, this gap is significant.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively concise but includes an 'Args' section that largely duplicates schema information. Could be more front-loaded and remove redundancy to improve efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema or annotations, description lacks information on return value (e.g., boolean, list of errors), error handling, or prerequisites. A validation tool should clarify what the output represents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds meaningful context: scad_code is 'OpenSCAD source code string' and material is 'Optional material ID (e.g., pla, petg)'. However, it could specify allowed material IDs or format more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states validation of OpenSCAD parameters against material design limits and gives specific examples. It distinguishes from siblings like validate_openscad_code (which likely checks syntax) by focusing on parameter values vs material limits, but could explicitly name the sibling for clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage before compilation/printing ('Catches issues before compilation and printing'), but does not explicitly state when to avoid or mention alternative tools. With many sibling tools, more direct guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers minimal behavioral insight. It does not disclose side effects, permissions needed, or whether operations are destructive (e.g., stopping a stream).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with purpose, followed by a clear argument list. Every sentence adds value, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does not explain what the tool returns (e.g., status info, success/failure). It also omits prerequisites or side effects, leaving the agent uncertain about the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains printer_name (target printer, omit for default), action (one of start/stop/status), and port (default 8081), adding meaningful context beyond types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool controls an MJPEG webcam streaming proxy, with explicit actions (start, stop, status). This distinguishes it from sibling tools, none of which relate to webcam streaming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor when not to use it. The description implies it's for controlling streaming, but does not explicitly state prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the function but does not disclose consequences (e.g., mutability, reversibility, or error handling). The tool modifies a print record, but safety or side effects are unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence for the main action, followed by a brief parameter list. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required parameters, the description covers the core function and parameter meaning. However, it omits behavior for edge cases (e.g., appending vs. overwriting notes, handling nonexistent print IDs) and does not describe the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args:' section that explains each parameter beyond the bare schema (e.g., 'job_id: The job ID of the print to annotate,' 'notes: The annotation text to attach'). Since the input schema lacks property descriptions, this adds meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('add notes to a completed print record') and gives examples ('quality observations, issues'). The verb 'annotate' is specific, distinguishing it from recording other outcomes. However, it doesn't explicitly differentiate from siblings like 'record_print_outcome' which may also accept notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for completed prints but provides no guidance on when to use this tool versus alternatives (e.g., 'record_print_outcome' for structured data). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral traits. It states the basic behavior and return similarity to search_models, but omits details about side effects, authentication needs, rate limits, or pagination limits beyond per_page max.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, covering the tool's purpose, parameters, and a note on related tools in a compact block. The structure (paragraph with inline arguments) is efficient, though not highly formatted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description covers the essential input semantics and references list_categories. It lacks return format details beyond a vague reference to search_models, which limits completeness for an agent needing to process results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It explains browse_type (three options), page, per_page (default and max), and category with an example slug. It adds value beyond the schema but does not fully define all parameter nuances (e.g., behavior of default values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (browse) and the resource (Thingiverse models) with specific sorting criteria (popularity, recency, category). It differentiates from 'list_categories' by mentioning that tool for category slugs. However, it does not explicitly distinguish from sibling 'search_models' beyond noting similar return format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (browsing by type/ category) and references 'list_categories' for valid slugs. It lacks explicit guidance on when not to use this tool (e.g., versus searching) or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool exports data (read operation) but lacks details on side effects, rate limits, or security requirements beyond being an enterprise feature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with an introductory sentence, a note on enterprise feature, and a structured parameter list. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description adequately covers tool purpose and parameters but does not specify the return format details (e.g., file type for CSV/JSON) or how the output is delivered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description explains all 6 parameters with clear purposes (e.g., 'Unix timestamp lower bound (0 = no filter)') and the output format options. This significantly adds value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports the safety audit trail in JSON or CSV format with optional filters. However, it does not explicitly differentiate it from sibling tools like 'safety_audit' or 'list_interception_sessions'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions 'Enterprise feature' but provides no guidance on when to use this tool versus alternative audit or export tools. No exclusions or comparisons are made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states that the tool returns 'every catalog entry sharing the same material family', which implies a read operation, but does not disclose authentication needs, rate limits, or any side effects. For a safe read tool, more clarity on behavior is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences: the first states the purpose, the second explains the return value, and the third clarifies the parameter with examples. No wasted words, and it front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lookup tool with one parameter and no output schema, the description gives the essential information. However, it lacks any mention of pagination, sorting, or format of results. Given no annotations, slightly more detail on the output structure would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds concrete examples (e.g., 'pla', 'petg', 'resin') and explains that it is a family name. This provides meaningful semantic context beyond the raw schema, compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Find' and the resource 'materials in a given family', with examples of families. It implies a filtering function but does not explicitly contrast with sibling tools like 'list_materials' or 'find_material_substitute', so it loses a point for lack of sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'useful for finding compatible substitutes' but provides no explicit guidance on when to use this tool versus alternatives (e.g., find_material_substitute, list_material_catalog). No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It only states it returns info (metadata, command counts, telemetry) but doesn't disclose behavioral traits like read-only nature, required session state (active?), or potential errors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences clearly stating purpose, parameter, and return. Every sentence adds value; no verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and presence of an output schema, the description covers essence: param and return types. Could mention that session must be active, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description compensates by documenting session_id as 'Target session ID.' This adds meaning but lacks format or constraint details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets status and statistics for an interception session, with the required session_id parameter and return types (metadata, command counts, telemetry). This distinguishes it from siblings like list_interception_sessions or get_interception_history, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., list_interception_sessions, get_interception_history). No prerequisites or context for use mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes what is included in the log but does not disclose performance implications, authentication requirements, or side effects. The behavioral disclosure beyond the basic purpose is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, background context, and parameter list. It is concise and informative, but the 'Args' section could be slightly more integrated. Overall, it earns its place without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should explain the return format. It says 'full audit log' but does not specify the structure (e.g., fields, ordering). Additionally, it lacks details on pagination or behavior when limit is exceeded. Given the complexity of a log tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description adds crucial meaning: it explains the session_id parameter (optional, defaults to current session) and the limit parameter (default 100, max 500). This provides clear semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the full audit log for an agent session, explaining what is recorded (tool calls, safety checks, blocked attempts). It does not explicitly differentiate from sibling tools, but the purpose is specific and well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool ('replay exactly what an agent issued during a session'), but does not mention when not to use it or suggest alternatives. No explicit exclusions or comparisons with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not explicitly state that this is a read-only operation with no side effects, nor does it mention authentication needs or rate limits. The licensing info hints at access control but is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose, followed by return details and licensing notes. The args block is somewhat verbose but acceptable. No redundant sentences; every part contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, return content, and licensing, but lacks description of the return format (e.g., JSON structure) and does not differentiate from many sibling slicer tools. With no output schema, this is a notable gap for an AI agent needing to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the single parameter 'printer_id'. The description compensates by providing example values (e.g., 'ender3'), which adds practical guidance but does not clarify format or constraints beyond examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get the full bundled slicer profile for a printer model' with clear verb and resource. It distinguishes from siblings by emphasizing 'full bundled' but does not explicitly contrast with related tools like 'get_material_slicing_profile' or 'list_slicer_profiles'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions free-tier vs. premium profile availability based on license, providing context for when this tool is usable. However, it does not specify when to avoid using it or suggest alternative tools, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description reveals that the tool accesses only public data and excludes engineering enrichment. However, it does not explicitly state that the operation is read-only or idempotent, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with minimal waste. It is front-loaded with the core purpose and adds a clarifying detail. Could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain what the tool returns. It only says 'material identifiers and safety/process summaries', which is vague. It omits details like whether it returns a list of objects, pagination, or any structure of the summaries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers param semantics. The description adds no param-specific detail, which is acceptable given 0 params baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists public material identifiers and safety/process summaries, and distinguishes itself by noting the data source is only public Kiln data without engineering enrichment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like list_materials or search_material_catalog. The description implies it is for public data only, but does not clarify when to prefer it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behaviors like authentication requirements, error handling, or that it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines plus an argument list. Every sentence is relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (1 parameter, no output schema, no annotations), the description covers the basics but lacks any indication of the return format or additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter 'model_id' with 'File hash or listing ID of the model', which is not present in the schema (only 'Model Id'). Schema description coverage is 0%, so this is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a revenue summary for a specific model (verb+resource+scope). It distinguishes from sibling tools like 'revenue_dashboard' by specifying 'for a specific model', but does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'revenue_dashboard' or 'record_revenue'. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states removal without explaining consequences (e.g., permanence, effect on session, error handling). Missing context for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two informative sentences plus concise parameter descriptions. Every word is necessary; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the domain (interception rules), the description lacks information about return values, error cases, or prerequisites. The output schema is present but not described, leaving the agent guessing about success/failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description adds minimal but useful semantics: 'Target session ID' and 'The rule ID to remove'. However, it is brief and could be more precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence 'Remove an interception rule from an active session' clearly states the action (remove) and the resource (interception rule from an active session). It distinguishes from siblings like 'add_interception_rule'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'add_interception_rule' or 'update_interception_telemetry'. The description does not specify prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states it stops a session and returns stats, but does not mention side effects (e.g., ending interception, releasing resources) or whether it is destructive. This is insufficient for an AI agent to understand consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It uses a clear 'Args:' section to document the parameter and a separate sentence for the return value. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema (not shown but implied), the description is minimally complete. It lacks prerequisites, error conditions, or behavioral notes. For a simple stop action, it's adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the single parameter 'session_id' as the one returned by 'start_gcode_interception', providing crucial context beyond the schema (which has 0% coverage). This tells the agent where to obtain the ID. A minor improvement would be to specify the expected format or type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool stops a G-code interception session, which is a specific verb and resource. It clearly differentiates from 'start_gcode_interception' by using the opposite verb. However, it does not elaborate on what stopping entails beyond ending the session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool, such as prerequisites (e.g., an active session) or when not to use it. No alternatives are mentioned, though the sibling list includes related tools like 'get_interception_status' or 'list_interception_sessions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the action without any details on effects, reversibility, permissions, or side effects of canceling a session.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no wasted words. It gets straight to the point with a single action sentence followed by parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple cancellation tool with two parameters and no output schema, the description is adequate but lacks mention of the return value or any post-cancellation behavior. It covers the basics but could be slightly more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema had no parameter descriptions (0% coverage), so the description adds significant value by explaining the purpose of each parameter: 'session_id: The session_id to cancel. reason: Optional reason for the cancellation.' This is clear and helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Cancel an active recovery session', which is a specific verb and resource. This distinctively differentiates from sibling tools like 'complete_print_recovery', 'plan_print_recovery', and 'start_print_recovery'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as when to cancel versus complete a recovery session. No context or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It states 'cancel' but omits details on side effects, reversibility, or what happens to the plan after cancellation. For a mutating tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the key action. The args block is efficient but the overall content is notably brief, leaving some questions unanswered without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should more fully explain the tool's behavior. It does not address what 'cancel' entails (e.g., deletion, status change, impact on related data), leaving the agent uncertain about the outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds value by explaining 'plan_id' as 'The plan ID to cancel.' However, it provides minimal additional context beyond the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Cancel' and resource 'split plan', specifying it applies to pending/in-progress parts. This distinguishes it from sibling tools like 'split_plan_status' (status check) or 'plan_assembly_split' (creation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a split plan is pending/in-progress and needs cancellation, but lacks explicit context on when to use this over other cancel tools (e.g., cancel_job, cancel_print). No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions returned data but does not disclose side effects, idempotency, or constraints (e.g., rate limits, auth needs). Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise with two sentences plus an Args line, front-loading the main purpose. Minor improvement could be formatting the Args as a list, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema. Description covers primary function but lacks details on return format, pagination, and fails to disambiguate from a very similar sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly explains the parameter 'model_id' as 'Model/job ID from a generation job', adding valuable context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets feedback loop history for a generated model, specifying what data is returned. However, it does not distinguish from the sibling tool 'generation_feedback_loop_status' which appears to serve a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'generation_feedback_loop_status' or 'analyze_generation_feedback'. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions ordering and pagination but does not disclose whether the operation is read-only, any rate limits, or the format of returned data. With no annotations, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using only three lines. It front-loads the main action and includes necessary parameter details. Every sentence is useful, though it could be slightly expanded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the essential input behavior. However, it lacks information about the output structure or what fields are returned, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters: limit (max results, default 50) and offset (pagination skip). This adds meaning beyond the schema, which has 0% coverage, making it helpful for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (List), the resource (all models in local cache), and the ordering (newest first). It effectively communicates the tool's core purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like list_cached_designs or search_cached_models. There is no mention of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description lacks behavioral details such as read-only hint, authentication needs, rate limits, or pagination. Only basic functionality is mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with one sentence for purpose followed by clear parameter bullet points. No redundant information; every sentence is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the input parameters well, but given no output schema and many sibling history tools, missing description of return values or additional behavioral details. Reasonably complete for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, and the description adds meaningful parameter explanations (e.g., filter by printer name, status with examples, limit with default). However, status allowed values are not fully constrained (schema allows any string).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get recent print history with success/failure tracking', which is a specific verb+resource. However, it does not differentiate from sibling history tools like 'failure_history' or 'get_model_print_history'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. The Args section explains parameters but does not indicate context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'check status', implying a read operation, but does not disclose behavior on invalid job_id, polling, or idempotency. Lacks depth for a non-annotated tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short (two sentences) but includes an unnecessary 'Args' docstring block. Could be more streamlined. No wasted words, but structure is minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter and no output schema, description covers the basic purpose and parameter source, but lacks information about return values, error handling, or result format. Adequate for a simple tool but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. It provides context that job_id comes from submit_provider_job, which is helpful, but does not elaborate on format or constraints beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'check' and the resource 'status of a provider-managed remote job', which distinguishes it from sibling tools like 'job_status' that may handle non-provider jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage after submit_provider_job by linking the job_id, but does not explicitly state when to use this tool vs alternatives (e.g., job_status). No direct guidance for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It indicates a read-only query but does not explicitly state whether it is safe or idempotent, nor describe any side effects. Minimal behavioral disclosure beyond expected output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no redundant information. Front-loaded with purpose, followed by outputs. Highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description adequately covers what it returns. Could mention if it's read-only but not required given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters with 100% coverage. Description does not need to add parameter semantics; baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves an overview of the print job queue, listing counts, next job, and recent jobs. The verb 'Get' and resource 'overview' are specific, but no distinction from sibling tools is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like job_status or print_history. No mention of prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose side effects, caching, or performance characteristics. Merely states it returns analytics, insufficient for behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and front-loaded: first sentence states purpose, then lists return types, then parameter. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing behavioral details like authentication requirements or response format. With no output schema, description should explain return structure; it lists items but lacks format details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning for the 'days' parameter, explaining its purpose and default. This compensates partially, though minimal for a single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves aggregate revenue analytics, listing specific outputs like total revenue, sales count, top models, etc. This distinguishes it from siblings like community_stats or marketplace_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description does not mention exclusions or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral transparency. It explains that the tool scores printers on material match, availability, queue depth, and historical success rate, and that it recommends the best assignment with scored alternatives. This discloses internal logic but does not mention whether it causes side effects (e.g., does it actually assign the job or just recommend?), or if it requires the printer to be available. It is adequate 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and includes a summary of the tool's behavior and an Args section that lists parameters with brief descriptions. It is front-loaded with the main purpose. It could be slightly more structured (e.g., bullets) but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters (2 required) and no output schema. The description explains the inputs well but does not describe what the output looks like (e.g., the recommendation structure), which is crucial. It mentions 'scored alternatives' but not their format. There is no mention of error conditions or side effects. Given the tool's complexity, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are described with their purpose: file_path, material, quality, and priority. Since schema description coverage is 0%, the description compensates by providing examples and meaning for each, e.g., material example 'PLA', quality preference values. It adds value beyond the schema's bare definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Route a print job to the best available printer in the fleet.' It identifies the verb (route) and resource (print job) and mentions the scoring criteria. However, it does not explicitly distinguish from siblings like 'suggest_printer_for_job' or 'optimize_fleet_assignment', which may have similar purposes, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. There is no mention of when to use it (e.g., for immediate printing vs. planning) or when not to use it. Siblings like 'suggest_printer_for_job' or 'optimize_fleet_assignment' could be alternatives, but no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a write operation but does not disclose side effects, required permissions, behavior on duplicates, or return value. The description lacks behavioral context beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose followed by a labeled list. It is front-loaded and avoids redundancy. Every line adds value, though structuring as a bullet list might improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (5 parameters, no output schema, no annotations), the description is adequate but not thorough. It covers the basic function and parameters but omits validation rules, constraints on material values, and output details. It meets minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that explains each parameter with examples (e.g., material types) and a default value. The schema provides no descriptions (0% coverage), so the description adds significant meaning, though it could be more precise (e.g., color format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a new filament spool to inventory.' The verb 'Add' and resource 'spool' are specific. The tool is distinguishable from sibling tools like 'remove_spool' and 'list_spools' by its name and description context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'suggest_spool_swaps' or 'list_spools'. There is no mention of prerequisites, conditions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It describes the action (storing and attaching), implying a write operation, but does not disclose details such as whether existing cache entries are overwritten, authentication requirements, side effects, or return values. The description provides basic transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, beginning with a one-line summary followed by a short explanatory paragraph and a properly formatted argument list. Every sentence adds value, and there is no unnecessary content. It could be slightly more condensed but remains well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 6-parameter complexity, no output schema, and no annotations, the description covers the core functionality but does not fully equip an agent. It lacks return value details, overwrite behavior, and retrieval instructions. While it explains what is stored, it omits the outcome of the operation and post-call state, limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for parameters, so the description must compensate. It lists all 6 parameters with brief explanations (e.g., 'file_path: Path to the design file'), which adds meaning beyond the schema's titles. However, it lacks details like path format, file existence requirements, or constraints on provider values. The explanations are adequate but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cache a design file alongside its parametric source code.' It specifies the verb 'Cache', the resource 'design file' and 'parametric source code', and explains that it stores the STL/3MF file and attaches the OpenSCAD source and prompt. This distinguishes it from sibling tools like 'cache_design' which likely cache only the file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives such as 'cache_design' or 'cache_model'. It does not mention prerequisites, conditions, or when to avoid using it. The only implicit differentiation is the inclusion of source code, but no explicit 'when-to-use' or 'when-not-to-use' instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It discloses that the tool returns a JSON-serialisable dict that must be passed back, which is crucial for proper usage. However, it lacks details on side effects, idempotency, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences explaining the purpose and return value, followed by a clear args section. It avoids unnecessary detail and is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description covers the essential usage flow (create and pass to subsequent tools). However, it does not explain what an assembly is in this context or any prerequisites, which might be needed for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% parameter description coverage. The description adds 'Human-readable name for the assembly' for the 'name' parameter, which provides semantic context beyond the schema's type-only definition. However, it could give more constraints like uniqueness or length limits.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new empty assembly', identifying the verb (create) and resource (empty assembly). It distinguishes itself from sibling tools like add_assembly_part or compose_assembly_parts by emphasizing 'empty' and noting the return value must be passed to subsequent assembly tools, indicating it is the initial step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used as the first step in assembly creation by stating the returned state must be passed to subsequent assembly tools. However, it does not provide explicit guidance on when not to use it or alternatives among the many sibling assembly tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states the operation is removal, without noting permanence, required permissions, or side effects. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, providing a one-line summary followed by parameter details in a clear format. It could be slightly tighter, but it efficiently covers the key points.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters adequately for a simple delete operation. However, it lacks any information about return values (no output schema) and error conditions, leaving the agent partially blind.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the bare schema: it explains that 'scope' defines the namespace (default 'global') and 'printer_name' targets a specific scope 'printer:<name>'. This clarifies the interplay between parameters, which is crucial since schema descriptions are absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Remove' and the resource 'a stored note or preference', making the purpose unambiguous. It also implicitly distinguishes from sibling 'save_agent_note' which adds notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'save_agent_note'. There is no context on prerequisites, when to avoid, or how it fits into a workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly implies read-only behavior ('View'), but does not disclose other behavioral traits such as data freshness, ordering, or whether results are paginated (though 'limit' parameter hints at pagination). The 'limit' parameter adds transparency but more detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose followed by a bulleted parameter list. Every sentence is necessary and none are wasted. The structure is front-loaded and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no output schema, the description provides the essentials but misses some context. It does not mention the return structure (e.g., list of records) or ordering. Given the complexity is low, it is minimally adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter's purpose ('Filter by printer name', 'Filter by failure type', 'Maximum records to return') despite the schema having no descriptions (0% coverage). This adds significant meaning beyond the raw schema. A higher score would require additional details like accepted value formats or behaviors when both filters are applied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('View') and resource ('failure history'), and specifies the two main filtering dimensions (printer name, failure type). This makes the purpose immediately understandable. However, it does not explicitly distinguish this tool from similar history tools like 'print_history' or 'job_history' among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. No context is provided about prerequisites, scenarios, or exclusions. The user must infer usage from the name and parameter descriptions alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fuzzy-matching behavior, case-insensitivity, and color-based preference for tie-breaking. However, it does not specify the output format (e.g., returns a single entry or list), behavior on no match, or whether the operation is read-only. With no annotations, these gaps reduce transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a purpose line followed by parameter details in a clear list. Every sentence adds value, and the most critical information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fuzzy matching with tie-breaking) and the absence of an output schema, the description falls short by not explaining the return value (e.g., matched catalog entry object). It covers input behavior but not output structure, which is essential for an agent to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant value by explaining each parameter with examples (e.g., vendor: 'Hatchbox', material_type: 'PLA', color: optional for tie-breaking). However, it does not clarify that all parameters are optional or that at least one may be expected for meaningful matching.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: fuzzy-match a catalog entry from spool metadata, matching against vendor and material type as case-insensitive substrings, with optional color tie-breaking. It distinguishes itself by focusing on spool metadata matching, but does not explicitly differentiate from siblings like find_material_substitute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or point to other tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool is read-only (get status) and describes return content, but does not mention safety (idempotence), error conditions, authentication requirements, or polling behavior. The description is adequate but not highly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence defining the purpose, a docstring-style argument explanation, and a return description. No extraneous information, front-loaded with the verb-object structure. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description covers its purpose, input, and output adequately. It could mention that the tool is idempotent or safe to call repeatedly, but the current completeness suffices for a simple status retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must add value. It explains that 'job_id' comes from 'submit_job', which provides necessary context. However, it does not specify format, constraints, or required string patterns, leaving some ambiguity. The explanation is helpful but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'status of a queued or completed print job'. It specifies scope (queued or completed) and mentions return content (full job record including status, timing, and metadata), which effectively communicates the tool's function. However, it does not explicitly differentiate from sibling tools like 'job_history' or 'print_status_lite', though the single-job focus is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It implies usage after obtaining a job_id from 'submit_job', but does not state when not to use it or list alternative tools. Siblings such as 'job_history' (for listing jobs) or 'print_status_lite' (for print status) are not mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool returns all materials with detailed properties, implying a read-only, non-destructive operation. However, it does not mention any constraints like authentication, rate limits, or pagination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence description. First sentence states the action and scope, second elaborates on returned data. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately explains what is returned. However, given the large set of sibling tools, additional context on how this differs from similar list tools would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it lists all 3D printing materials with properties, specifying included attributes. However, it does not differentiate from sibling tools like list_materials or list_material_catalog, which may have similar purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternative material listing tools. The description lacks context for selection, especially given many related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, side effects, permissions, or rate limits. For a listing tool, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes bullet points for clarity. No unnecessary sentences, though it could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and zero parameters, the description covers the tool's functionality well, including template features and connection to generate_from_template. It lacks pagination or output volume details but is sufficient for a simple list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, schema coverage is trivially 100%. The description adds value by explaining the content and structure of templates, going beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists parametric design templates, with a specific verb and resource. However, it does not differentiate from sibling tools like find_design_templates or search_design_templates, lacking explicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by suggesting generate_from_template after listing, but provides no explicit when-to-use guidance or exclusions. No mention of when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic operation. No annotations are provided, so it should describe aspects like data freshness, pagination, or authentication requirements. It only says 'returns all provider-side listings' without further details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action. It is concise but could be slightly tighter by combining sentences. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters or output schema, the description provides minimal but adequate context. However, given the complexity of sibling tools and integration context, it could benefit from additional details about the return format or when to prefer this over 'find_provider_capacity'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% (empty). The baseline for 0 params is 4; the description does not need to explain parameters. It adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists printers registered with connected provider integrations, and distinguishes it from siblings like 'find_provider_capacity' (targeted search) and 'sync_provider_capacity' (sync operation). The verb 'list' is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not indicate prerequisites, when not to use it, or how it compares to similar tools like 'find_provider_capacity' or 'sync_provider_capacity'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the tool 'searches' the local cache, implying a read-only, safe operation, but does not explicitly confirm non-destructiveness, specify authorization requirements, or mention any side effects. With no annotation support, the description is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the core purpose in a single sentence followed by a structured argument list. It is front-loaded and easy to scan. No superfluous words. Could be slightly more compact by integrating argument descriptions into the main sentence, but overall it's efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a basic search tool with 4 parameters and no output schema, the description covers input semantics adequately but omits output format, pagination behavior (beyond the limit default), and expected response shape. With no annotations, the agent lacks information about result ordering, total count, or empty result handling. Adequate but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates well by explaining parameter semantics. 'query' is clarified as free-text search against file name, prompt, and tags. 'source' has an example ('"thingiverse"'). 'tags' is described as comma-separated. 'limit' notes default 20. These add non-trivial meaning beyond the schema types. Minor gap: no format constraints or valid values for source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search the local model cache' with specific filter dimensions (name, source, tags, prompt text). This distinguishes it from sibling tools like search_models (broader) and search_all_models (different scope). The verb 'search' and resource 'local model cache' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., search_models, search_all_models). The description does not specify prerequisites, context, or situations where this tool should be avoided. The user must infer usage purely from the tool name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only partially covers behavior. It mentions updating and returning capacity view, but omits security requirements, idempotency, or what happens when parameters are omitted. The conditional behavior is described but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose upfront followed by parameter explanations. It avoids unnecessary words, though the Args block formatting adds a bit of verbosity. Still efficient for the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has two optional parameters and no output schema. The description covers the conditional update case but doesn't specify behavior when neither parameter is provided. For a simple tool, it's mostly adequate but leaves gaps in expected behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining each parameter's role ('Optional ID' and 'Optional availability update'). It adds meaningful context beyond the schema's titles and types, though it could clarify the update condition more precisely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Sync local printer capacity/availability to the provider integration.' It distinguishes from sibling tools like 'list_provider_capacity' by specifying an update action, making its purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'list_provider_capacity' or 'find_provider_capacity'. The description does not provide context on prerequisites or scenarios where this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions that trusted printers are flagged during discovery, but lacks details on side effects (e.g., overwriting, limits, permissions), reversibility, or error conditions. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences and an Args line, front-loading the main action. No unnecessary words; efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers purpose and parameter meaning. However, it does not indicate return values or failure modes, leaving gaps for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'host' parameter, but the description adds 'The hostname or IP address to trust,' providing basic meaning beyond the schema's title. However, it does not include format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a printer hostname/IP to a trusted whitelist, using a specific verb and resource. It distinguishes from sibling tools like untrust_printer and list_trusted_printers, even without explicit comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to avoid warnings when connecting to a trusted printer) but does not explicitly state when not to use it or mention alternatives like untrust_printer, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It says 'unlock' but does not explain what this entails (e.g., reversibility, side effects), required permissions, or error handling. The enterprise flag is a prerequisite, not a behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, concise and front-loaded with the action. Each sentence adds distinct information (purpose, enterprise, effect). Could be slightly more structured, but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of annotations/output schema, the description is incomplete. It does not cover prerequisites, expected behavior if already unlocked, or any consequences. More details are needed for full usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It specifies 'printer_model' as a 'Profile identifier', adding context beyond the schema title, but lacks details on format or source. Parameter semantics are minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'unlock' and the resource 'safety profile', and distinguishes from siblings like 'lock_safety_profile' and 'get_safety_profile'. It also mentions the enterprise nature and purpose of allowing community profile modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a safety profile is locked and modifications are needed. It notes 'Enterprise feature', indicating a prerequisite, but does not explicitly state when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions preserving comments and formatting and that it finds the named variable declaration. With no annotations, it partially describes behavior but lacks details on return value, side effects, or error handling, which are important for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise introductory summary followed by an Args list. Every sentence adds value, and the most important information is front-loaded. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 no annotations, the description should cover return values and potential errors. It omits what the tool returns (e.g., modified code string) and does not mention validation or failure modes, leaving context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an Args section that explains each parameter (scad_code, parameter_name, new_value) beyond their types and titles, providing clear meaning and usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a parameter value in OpenSCAD code', identifying a specific verb and resource. It distinguishes from siblings like 'modify_scad_module' by focusing on parameter value replacement, but does not explicitly differentiate from other parameter-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to tweak dimensions without regenerating the entire model', implying when to use it. However, it does not specify when not to use or provide alternatives, such as when a full regeneration is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains that the tool examines job record, events, and printer state, and produces a diagnosis. However, it does not explicitly state whether it is read-only or if it modifies any state, so a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 sentences) and well-structured, with a clear purpose statement, process explanation, args section, and output description. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and lack of output schema, the description adequately covers input and process, and describes the output as a structured analysis. It could be more explicit about the output format, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to the single parameter 'job_id' by specifying its source: 'from job_history or job_status'. This goes beyond the schema's minimal definition, though the schema coverage is listed as 0%, the description effectively covers it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: analyze a failed print job and suggest causes/fixes. It specifies the verb (analyze) and resource (failed print job). However, it does not differentiate from sibling tools like 'detect_print_failure' or 'analyze_print_failure_smart', so a 4 is appropriate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It lacks any conditional or contextual advice, earning a 2.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key side effects: it sends cancel via MQTT/REST, optionally preserves temperatures, and warns that without preserve_temperatures the printer cools down, potentially warping the part. It also clearly states that cancellation is irreversible unless a pre-staged resume-mode 3MF exists. These behaviors are explained, though the repetitive phrasing adds noise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely verbose and contains duplicated, nonsensical phrases (e.g., 'which is what this did before it could be aimed' and 'Owning more than one printer is free...'). It repeats the same warnings and parameter explanations multiple times, making it far longer than necessary. The structure is unclear due to this redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides substantial context about temperature preservation, firmware behavior, and irreversible cancellation, suggesting completeness. However, the garbled text and repetition make it difficult to parse, and some context (e.g., exact error conditions) is missing. It covers the main points but not in a clean, coherent manner.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter beyond the schema: printer_name (which printer), preserve_temperatures (whether to keep temperatures), and expected_bed/tool/chamber targets (overrides for temperature preservation when firmware might clear them). This adds meaning to the schema, though the wording is convoluted and repetitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Cancel the currently running print job.' This is specific and distinguishes it from sibling tools like pause_print or emergency_stop. However, the rest of the description contains verbose and garbled text (e.g., 'which is what this did before it could be aimed') that slightly obscures the clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a precondition ('The printer must have an active job') and notes that cancellation is irreversible unless a resume-mode 3MF is pre-staged. It also explains temperature behavior with preserve_temperatures. However, it does not explicitly compare with alternatives like pause_print or emergency_stop, so guidance on when to choose this tool over others is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose any behavioral traits such as side effects, permissions, rate limits, or return value details. Simply states the function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line purpose plus clear parameter descriptions. No wasted text, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains parameters but lacks output specification (e.g., what the check returns). Missing any context about potential limitations or required preconditions. Acceptable for a simple check tool but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: material is described as 'Material ID from the design knowledge base' and environment as 'Natural language environment description'. This clarifies param types and sources, though no format constraints given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'check' and specific resource 'material compatibility with environment'. Distinguishes from siblings like check_material_match which checks material-material compatibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites, exclusions, or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states action without disclosing behavioral traits such as network dependency, data synchronization impact, or potential latency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant words, directly conveys the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal description for a simple action; lacks output schema or behavioral context, but adequate for a straightforward trigger with no params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description trivially adds no additional parameter meaning; baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'trigger' and resource 'cloud sync cycle', distinguishing it from sibling tools like cloud_sync_configure and cloud_sync_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or when to prefer alternatives; lacks context for prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states 'Get', implying read-only, but does not disclose whether it triggers side effects, returns cached data, or requires authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is adequate but lacks detail on what 'status' entails (e.g., sync progress, last sync time). No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, the baseline is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'current cloud sync status', distinguishing it from sibling tools like 'cloud_sync_configure' and 'cloud_sync_now'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as checking status before initiating a sync. No context on prerequisites or ideal scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states that both file and metadata are removed, implying irreversibility, but it does not mention side effects, permissions required, or consequences of deleting a model that may be referenced by other tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two focused sentences. The first sentence states the purpose, and the second lists the argument. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple destructive operation, but the description does not mention return value, error conditions (e.g., cache_id not found), or prerequisites. Given the lack of output schema, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 describes cache_id as 'The unique cache ID of the model to delete,' adding minimal context beyond the schema property name. It does not explain how to obtain the cache_id or format requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'model from the local cache (file and metadata).' This differentiates it from siblings like get_cached_model or list_cached_models, which involve retrieval or listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it, such as if the model is currently in use or if other tools should be preferred for certain scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It mentions cancellation is conditional but does not describe what happens if the order is not cancellable (error? no-op?), nor does it mention side effects, authentication requirements, or idempotency. For a mutation tool, this is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three short sentences. It is front-loaded with the action and resource. However, it could be more structured (e.g., using a clear when statement).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the basic purpose and usage condition. However, it is incomplete in explaining the result of the action, error handling, or prerequisites beyond shipment status. Given the large sibling set, more nuance would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal value beyond the schema for the single parameter order_id. It says 'Order ID to cancel,' which is nearly tautological. With 0% schema coverage, the description should provide more context (e.g., format, source, or validation).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (cancel) and resource (fulfillment order), and explicitly adds the condition 'if still cancellable' and 'Only orders that have not yet shipped can be cancelled.' This distinguishes it from sibling tools like cancel_job and cancel_print which operate on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear condition for when the tool is applicable: orders that have not shipped. This gives the agent a when-not rule. However, it does not explicitly name alternative tools for orders that have already shipped, which would boost the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It states return values but does not declare read-only nature or side effects. No mention of auth requirements or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded purpose sentence followed by args docstring. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lists key return fields (order state, tracking, delivery) but lacks error scenarios, state enum, or mention of pagination. No output schema to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains that 'order_id' comes from 'fulfillment_order', providing essential context beyond schema field name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'status of a fulfillment order', distinguishing it from sibling tools like 'fulfillment_order' (likely create) and 'fulfillment_alerts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as 'fulfillment_alerts' or 'fulfillment_quote'. Does not mention prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavior. It states 'retrieve' implying a read-only operation, but does not explicitly confirm non-destructiveness, required permissions, or error handling (e.g., if design not found). Lacks detail on side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded: two sentences plus an Args block. The Args section largely duplicates the schema, but the main part is efficient. Could be slightly more concise by removing redundant Args, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description lists return values (source, prompt, provider), adding useful context. For a simple retrieval with one parameter, the description covers the essentials. Lacks mention of any potential limitations or edge cases, but sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (design_id) with 0% description coverage. The description adds 'ID of the cached design', providing context that it's a cached design ID, which helps disambiguate. However, no format or validation details are given, leaving room for improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves parametric source code for a cached design, using a specific verb and resource. Distinguishes itself from siblings like 'get_cached_design' or 'get_design_version' by focusing on source code retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for regeneration, tweaking, or inspection via return values, but does not explicitly state when to use this over alternatives like 'get_cached_design' or 'cache_design_with_source'. No exclusion criteria or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses caching with TTL and fallback to fresh fetch, which is key behavioral info. However, it does not discuss error handling, cache miss behavior, or any side effects. The description provides moderate transparency but omits details about what happens when the cache misses or on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a brief bullet list. It front-loads the core purpose and caching mechanism. The bullet list, while not adding much semantic depth, is acceptable given the lack of schema descriptions. No unnecessary words. Could be slightly improved by integrating Args into prose without repeating parameter names trivially.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0% schema coverage, the description should explain what the tool returns (e.g., a quote object with pricing, availability). It explains the caching behavior but omits the return structure and prerequisites (e.g., file_path existence, provider validity). For a simple caching tool, it is adequate but not fully complete for an agent to understand the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The Args section provides minimal one-liners ('Path to the design file', 'Fulfillment provider name', 'Material specification') that add little beyond the parameter names. No formats, constraints, or allowed values are given. The descriptions are too generic to significantly aid an agent in constructing proper arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a cached fulfillment provider quote (or fetch fresh if expired)', which distinguishes it from a fresh quote tool. The verb 'get' with the specific resource 'cached fulfillment provider quote' and the caching behavior make the purpose precise and distinct from siblings like 'fulfillment_quote'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when avoiding redundant API calls via 'Uses TTL-based caching to avoid redundant provider API calls', but it does not explicitly state when not to use it or mention alternatives like 'fulfillment_quote' for fresh quotes. The guidance is implied but lacks clear exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool lists and returns a sorted list from the built-in catalog, implying read-only behavior. However, it does not disclose potential impacts, limitations, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence immediately states the purpose, reflecting good front-loading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 mostly complete for a simple list tool. It clarifies the source (built-in catalog) and order (sorted), but could specify what material IDs look like or whether the list is static.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%. The description adds no parameter details, which is acceptable given zero parameters. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all material IDs in the catalog with a sorted list. However, it does not differentiate from sibling tools like list_materials or list_available_materials, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like search_material_catalog or list_materials. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and optional parameters, omitting details like response format, pagination behavior, or default marketplace behavior. This is minimal transparency for a list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single sentence and an Args block with two parameters. No extraneous information is present, and the structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description covers the core purpose and parameters. However, it does not mention the return type or any limitations, which would be helpful given the lack of an output schema. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description adds value by explaining that marketplace is a filter and limit sets max results. This compensates for the schema's lack of parameter descriptions, though it does not specify allowed values or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists 'models that have been published to marketplaces,' using a specific verb and resource. It distinguishes from sibling tools like search_models or browse_models by focusing on published models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as search_models or list_cached_models. The description implicitly suggests usage for listing published models but lacks explicit contextual direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the module's body is replaced entirely, but does not mention prerequisites (e.g., module must exist), error handling, or side effects. It is adequate but has gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key action, followed by a clear docstring. It is concise and well-structured, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters, but lacks information about return value (e.g., does it return modified code?) and error conditions (e.g., module not found).Given the 3 params and no output schema, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a docstring explaining each parameter (scad_code, module_name, new_module_code) with examples. This adds significant meaning beyond the schema, which has no descriptions. Schema coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'replace' and the resource 'module in OpenSCAD code'. It provides a specific action: 'Finds the named module and replaces its body entirely.' This distinguishes it from many sibling tools, but does not explicitly contrast with all alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Use for major modifications like redesigning a component', implying when to use it, but does not provide explicit guidance on when not to use it or mention alternative tools. It gives some context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the core behavioral trait (prediction degrades gracefully from exact match to geometric similarity to material defaults) and explicitly warns about the v2 caveat with real consequences. It does not, however, mention whether the tool has side effects, requires prior state (like `record_print_dna` calls), or how errors are surfaced when no historical data exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary up front, a succinct algorithm note, then a clean Args block. Every sentence earns its place. It loses a small point for some awkward whitespace/indentation in the raw text and for spending its only prose sentences on already-obvious content while domain jargon like 'DNA data' goes unexplained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and no annotations, the description covers the algorithm and parameter semantics well. However, with 600+ siblings including extremely similar tools like `infer_print_settings`, `recommend_settings`, and `predict_print_failure`, the complete absence of any return-value description or disambiguation is a meaningful gap for an agent choosing purposes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the docstring Args section is the sole documentation, and it fully compensates: all 8 parameters are documented with clear types, units (mm^2, mm^3), ranges (0.0-1.0), and the optional `geometric_signature_v2` receives a purpose-specific note. Slight deduction because there are no format examples or valid-combination guidance for the optional parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Uses a specific verb+resource ('Predict optimal print settings') and clarifies the prediction mechanism via a documented fallback chain (file hash → geometric similarity → material defaults). However, it doesn't differentiate itself from closely-named siblings like `infer_print_settings` or `recommend_settings`, and the 'historical DNA data' phrase is figurative and could be mildly confusing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies when different data sources are used through the fallback ordering, and provides a crucial warning about passing `geometric_signature_v2` to avoid mis-sized predictions. But it never states when to prefer this tool over the many overlapping siblings, does not give exclusions, and prerequisites (e.g., linking to `fingerprint_model` output) are only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: it queries a learning database, returns aggregated recommendations plus raw settings, and details the conditional calibration overlay when kiln-pro is installed. It also notes recommendations are advisory and do not override safety limits. This is comprehensive given no annotations exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary, followed by filtering details, then the conditional calibration behavior, and a note. It is logically structured and reasonably concise, with no extraneous information, though the calibration section could be slightly condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality and the calibration overlay, but lacks details on empty results or error handling. Without an output schema, the agent has limited understanding of the response structure beyond the calibration block. This leaves some gaps for an agent to navigate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides names and types with no descriptions. The description's 'Args' section adds examples and clarifies each parameter's role (e.g., filtering by printer, material, or file hash). This compensates for the 0% schema coverage, though it does not exhaustively specify constraints or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool recommends print settings based on historical outcomes. It specifies filtering by printer, material, and file hash. However, it does not explicitly distinguish itself from sibling tools like infer_print_settings or predict_print_settings, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention scenarios to avoid or recommend this tool over others, leaving the agent to infer usage context from the tool's function alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states the action 'record' without disclosing side effects (e.g., database mutation), idempotency, required permissions, or return value. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a clear, well-structured docstring with a concise single-line summary followed by a parameter list. It is not overly verbose, though the parameter list could be slightly more compact. Overall, it is efficiently organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters but omits return value, side effects, defaults (though in schema), and constraints (e.g., amount must be positive). For a 6-parameter tool with no output schema or annotations, this is adequate but leaves gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully documents all 6 parameters with examples (e.g., marketplace as 'thingiverse', transaction_type values). It adds meaning beyond the schema by providing allowed values and clarifying the purpose of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record a revenue event (sale, royalty, tip, or refund).' It specifies the verb 'record' and the resource 'revenue event', and explicitly lists the allowed transaction types, distinguishing it from siblings like 'record_print_outcome' or 'model_revenue'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., other recording tools or revenue-related tools). It does not specify prerequisites, context, or when not to use it. Given numerous sibling tools, this lack of usage direction hinders correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description indicates a read-like operation ('Query'), but does not explicitly state it is read-only, non-destructive, or whether authentication is required. It lacks safety guarantees or side-effect warnings, which is a gap for a mutation-ambiguous tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a docstring format with a brief summary and an Args section. It is moderately concise but could be shorter without losing clarity. The structure is clear, but there is some redundancy (e.g., 'Returns a record of all safety-relevant operations' followed by examples).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should provide more details about the return structure, pagination, or error behavior. It lists return categories but not fields or shape of records. For an agent, this lack of completeness could lead to misinterpretation of the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must compensate entirely. It fully documents all three parameters: 'action' with enumerated options, 'tool_name' as a filter, and 'limit' with default/max values. This provides essential semantics that the schema alone lacks, enabling correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Query the safety audit log.' It explicitly lists the types of operations returned (tool executions, blocked attempts, rate-limit violations, preflight failures), making the resource and verb specific and unambiguous. Among many sibling tools, none duplicate this exact functionality, so it stands out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying safety-related operations, but provides no explicit comparison to sibling tools like 'export_audit_trail' or 'verify_audit_integrity'. There is no when-to-use or when-not-to-use guidance, so the agent must infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses basic behavior (signals exit, removes from registry) but misses important details such as whether the operation is idempotent, what happens if the watcher ID is invalid, or any required permissions. With no annotations, the burden is on the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two sentences. The main action is front-loaded, and every sentence adds value with no repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple lifecycle tool with one parameter and no output schema, the description provides adequate purpose and parameter context, but lacks details on return state format and idempotency, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the 'watch_id' parameter (0% coverage). The description adds context by specifying that it is the ID returned by 'watch_print', but does not elaborate on format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool stops a background print watcher and returns its final state. It mentions the key resource (watcher) and action (stop), distinguishing it from sibling tools like 'watch_print' which starts a watcher.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after starting a watcher with 'watch_print', but it does not explicitly state when to use it, nor does it contrast with alternatives or mention any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It mentions capturing a snapshot and examining job records, but does not state whether the tool is read-only, modifies data, or requires specific permissions. This leaves significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence of purpose followed by a bullet-style argument list. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description reasonably covers inputs, behavior, and output (quality report with snapshot data, metrics, issues). It could detail the report structure or include usage guidance versus siblings, but is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds essential meaning for all three parameters: explains job_id defaulting, printer_name defaulting, and save_snapshot as an optional file path. This is clear and helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates print quality after a completed job, distinguishing it from real-time failure analysis tools. However, it doesn't explicitly differentiate from sibling tools like analyze_print_failure, limiting precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies 'after a completed print job', giving clear context for when to use. But it provides no guidance on when not to use or mentions alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions exclusive lock, prevention of simultaneous control, and timeout, but lacks details on lock failure behavior, idempotency, automatic release, or side effects. This is insufficient for a tool with no annotation safety net.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement, an explanatory sentence, and a parameter list. It is concise with no redundant information. Could be slightly more compact, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description covers purpose and parameter semantics but omits return value, error handling, and blocking vs non-blocking behavior. For a relatively simple tool, the description is adequate but not fully complete to guide an agent without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no parameter descriptions in the schema. The description includes an explicit 'Args' section explaining each parameter's semantic role (printer_name: Printer to lock, holder: Identifier of the lock holder, timeout_seconds: Maximum time to wait). This adds significant meaning beyond the schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it acquires an exclusive lock on a printer for safe concurrent access. The verb 'acquire' and resource 'lock on printer' are specific. It distinguishes itself from sibling 'release_printer_lock' by focusing on acquisition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context by stating it prevents multiple agents from controlling the same printer simultaneously, implying when to use. However, it does not explicitly state when not to use or mention alternatives like 'release_printer_lock'. Guidelines are implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It states the tool returns feedback (a read operation), but does not explicitly confirm it is non-destructive, nor does it mention any side effects, authentication needs, or rate limits. The description is insufficient given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement and a return value description, followed by a structured parameter list. It is reasonably concise, though the parameter list is somewhat verbose. Overall, it is well-organized and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 8 parameters, no output schema, and many siblings, the description provides basic functionality and parameter info but lacks return value format details, error conditions, or usage context. It does not fully compensate for the missing output schema or annotations, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must provide parameter meaning. It includes a docstring listing each parameter with a brief explanation (e.g., failure_mode: 'Optional failure mode if the model was printed and failed'). These add value beyond the schema's titles and types, though descriptions are minimal. The effort compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a generated model to get feedback for improvement, specifying it returns constraints to add to the generation prompt. This verb+resource pairing is specific and distinguishes it from sibling analysis tools like analyze_print_failure or analyze_warping_risk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you have a generated model to improve, but it lacks explicit guidance on when to use it versus alternatives (e.g., other analysis tools). No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it returns a list of clearance check results and that it checks each interface against requirements. It implicitly suggests a read-only operation, but does not explicitly state that it does not modify the assembly or require specific permissions. With no annotations provided, the description carries full burden and is only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a short summary, a line about return type, and structured parameter descriptions. The 'Args:' section is helpful given no schema descriptions, though it adds some verbosity. Overall efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the purpose and high-level return. It would benefit from specifying the structure of each clearance result (e.g., fields like 'interface_id', 'clearance', 'required', 'pass'), but the current description is sufficient for an agent to understand the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes a clear docstring for both parameters: assembly_json is 'JSON string of the current assembly state' and default_clearance_mm is 'default clearance gap in mm' with a default value. This adds substantial meaning beyond the schema's type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'clearances between all mating parts in an assembly'. It distinguishes the tool's purpose from siblings like 'validate_assembly' by focusing specifically on clearances, though it does not explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites or when not to use it (e.g., the assembly must be valid JSON). There is no mention of context like 'use for clearance verification, not general assembly validation'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses actions performed (validation checks, auto-repair) and return value, but fails to mention side effects like file system writes (output_path), idempotency, or potential destructive behavior. The description is adequate but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, bullet lists of checks, and parameter documentation. It is appropriately detailed but slightly verbose; every sentence contributes value, though could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and no annotations, the description covers the tool's purpose, parameters, and return value. It lacks error handling, prerequisites, or performance details, but is relatively complete for the tool's apparent scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It provides detailed parameter descriptions including defaults, roles, and usage notes for all 7 parameters (file_path, auto_fix, output_path, bed dimensions, printer_id). This fully explains parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a single-call print readiness check with optional auto-repair, listing the specific validation checks. However, it does not explicitly differentiate from sibling tools like 'validate_and_prepare_mesh' or 'analyze_printability', which may overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that it is a comprehensive check, but lacks explicit guidance on when to use this tool versus alternatives, no when-not recommendations, and no exclusions. It only implies usage by listing capabilities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. However, it only states the action (connects/registers) without describing side effects, permissions required, reversibility, error behavior, or impact on existing connections. The mention of 'currently 3DOS' provides limited context but is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (a few sentences), front-loaded with the main purpose, and includes a structured parameter list. No unnecessary information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose and all parameters, but lacks information on return values (no output schema), error handling, prerequisites (e.g., configured provider account), and behavioral context. Given the absence of annotations and the complexity of the sibling toolset, the description is minimally adequate but leaves gaps for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description includes an 'Args' section that explains each parameter with examples and meaning (e.g., name as human-readable, location as geographic, capabilities as optional dict, price_per_gram as price). This fully compensates for the schema's lack of descriptions, making the parameters highly clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: connecting a local printer to a provider account (integration path) and registering it with 3DOS. It uses specific verbs ('connect', 'register') and identifies the resource, differentiating it from sibling tools like 'register_printer' by highlighting the provider integration aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., 'register_printer' or other printer connection tools). It only states the purpose without indicating prerequisites, exclusions, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions returning a quote but does not describe side effects (e.g., order persistence, resource reservation), authentication requirements, rate limits, or potential destructiveness. The word 'create' implies mutation, but no safety details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear first line stating purpose, a usage note, and a clean Args list. It is appropriately sized for 10 parameters and front-loaded, though slightly verbose in the Args section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description only vaguely mentions 'returns a quote with local and fulfillment options.' Missing details on output format, error handling, and prerequisites. Completeness is adequate but not thorough for a 10-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains all 10 parameters, including defaults for material, quantity, prefer_local, and lists example intents (strong, pretty, cheap). This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Print-as-a-Service order and returns a quote. It specifies the mutually exclusive inputs (model_path, model_url, or prompt) and includes a reference to a sibling tool (print_service_quote) for confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some usage guidance (require one of three inputs, call print_service_quote to confirm) but does not explicitly state when not to use this tool or compare with other siblings like print_service_status or cancel_print_service_order.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states 'Requires Enterprise license' but does not mention idempotency, side effects (e.g., duplicate handling), error conditions, or return value. This is a significant gap for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a clear purpose sentence, a contextual paragraph, a structured Args list, and a requirement note. The contextual paragraph adds value but could be condensed. Overall, it is well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain return values and error scenarios, but it does not. It includes the enterprise license prerequisite. For a simple creation tool, the coverage is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description's Args section is critical. It provides meaningful descriptions for all four parameters, including an example for name and clarifying the client as a cost-center identifier. However, it could add constraints (e.g., name length, budget format).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a project for cost tracking, using a specific verb ('create') and resource ('project'). It distinguishes itself from siblings like log_project_cost and project_cost_summary by emphasizing the creation aspect and the usage context for manufacturing bureaus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context that projects are used to allocate costs to client engagements, implying use when a new cost-tracking project is needed. However, it lacks explicit guidance on when not to use this tool or what alternatives exist, such as log_project_cost for adding costs to existing projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior by listing steps and noting that slicing depends on slicer availability. However, it does not mention authorization needs, error handling, or whether the pipeline is destructive (e.g., creates files). Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, enumerated steps, and a param section. It is concise and front-loaded, though the param block adds some length. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 params, no output schema, no annotations), the description explains the pipeline flow and return structure (paths, weight, risks). However, it lacks details on error handling, slicer unavailability, and partial results. Adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a param block that briefly explains each parameter, adding meaning beyond the schema (which has 0% coverage). However, explanations are minimal (e.g., 'Natural-language design description') and lack constraints or allowed values. Adequate but shallow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'End-to-end pipeline: description → template → STL → analysis → GCode.' It enumerates each step, distinguishing it from sibling tools by bundling multiple stages into a single call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a complete pipeline but does not explicitly state when to use this tool versus alternatives like 'generate_model' or 'slice_model'. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It states the tool analyzes the mesh for overhangs, implying a read-only operation, but does not explicitly confirm it does not modify the file or require special permissions. It is adequate but lacks explicit safety declarations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences and parameter explanations. It front-loads the main action and avoids unnecessary words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks key contextual details: it does not describe the output format or units (e.g., volume in cubic mm), nor does it mention error handling or file validity requirements. For a tool that takes a file path, prerequisites like file existence and mesh validity are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for the 0% schema description coverage by explaining the file_path parameter (path to STL or OBJ file) and the max_overhang_angle parameter (maximum overhang angle in degrees, default 45). This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates support volume for a 3D model by analyzing overhangs. It specifies the resource (3D model) and the action (estimate support volume), and distinguishes it from other estimation tools like estimate_print_time or estimate_cost by focusing on supports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like estimate_support_material. It does not mention prerequisites, when not to use it, or how it compares to other estimation tools. The agent is left to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states conversion from STL/OBJ/GLB and auto-generation of output path, but omits whether the tool is read-only, error handling, file size limits, or side effects. This is insufficient for a tool with no annotation safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loads the main action, and separates param docs. It earns its place but the rationale for 3MF is slightly extraneous. Overall well-structured for the information provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema or annotations, so the description must cover return value and behavioral details. It mentions the return dict, but lacks error conditions, overwrite behavior, and validation details. Adequate for a simple conversion but incomplete for robust use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by explaining file_path as input mesh and output_path as auto-generating if empty. It provides clear semantics beyond the schema titles, but could specify allowed formats or path constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports a mesh to 3MF format, specifies input formats (STL, OBJ, GLB), and explains why 3MF is preferred for modern slicers. This distinguishes it from export tools like export_safety_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use (exporting to 3MF for slicers) but does not explicitly exclude cases or suggest alternatives. It could be improved by noting when not to use, e.g., if already in 3MF.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing behavior. It does not mention side effects (read-only nature), error conditions, or what the return value looks like. It only lists input parameters without explaining expected outcomes or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear two-part structure: a general summary and a parameter list. It avoids unnecessary verbosity while providing essential details, though the parameter explanations could be more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete in terms of overall context. It does not specify the output format, the nature of results (e.g., a list of matching model IDs), or any edge cases. Since there is no output schema provided, this missing information is a significant gap for users to understand the tool's full behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description elaborates on each parameter, clarifying the roles of surface_area_mm2, volume_mm3, complexity_score, and importantly explains the distinction between geometric_signature and geometric_signature_v2, noting that using the older signature may lead to incorrect matches. This adds significant meaning beyond the schema's basic type listings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to find similar models in the print DNA knowledge base, using geometric and physical characteristics. This distinguishes it from other find-related tools by specifying the 'print DNA' context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for locating models with similar geometry but does not explicitly state when to use it over alternatives or provide conditions like 'use when you need to identify parts with comparable shape'. It lacks clear when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It mentions combining stock and consumption, but does not disclose whether the tool is read-only, requires permissions, or has side effects. No rate limits or other constraints are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two short paragraphs and a parameter listing. The main purpose is front-loaded. However, the Args block uses Python docstring style, which is slightly verbose and non-standard for MCP, but still clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only two simple parameters and no output schema, the description provides adequate coverage of inputs and behavior. However, it fails to describe the exact output format or structure, which is a gap since there is no output schema to rely on.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), but the description adds meaningful explanations: material_type example 'PLA' and days_ahead default 30. This clarifies parameter purpose beyond the schema's minimal type and default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool forecasts when a material type will run out, combining current stock with historical consumption. It specifies output: remaining days and urgency level. This distinguishes it from siblings like get_material_consumption_history and get_restock_suggestions which focus on past consumption or restocking.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for forecasting depletion, but does not explicitly state when to use it versus alternatives or mention prerequisites like having stock data. No exclusions or alternative tools are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior. It states the tool generates a summary and returns structured metrics, implying read-only operation. However, it does not explicitly confirm non-destructive behavior or mention any side effects or requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two clear sections (Args and Returns). Every sentence adds value, but the Args description is prose rather than structured format; still no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and no annotations, the description is reasonably complete. It explains input source and output nature ('structured summary with key metrics and region breakdown'), but lacks details on error handling or return format specifics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It adds value by specifying that 'plan_data' is a dict from 'generate_adaptive_slicing_plan' or 'quick_adaptive_plan', giving context beyond the generic object type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Generate a human-readable summary') and clearly identifies the resource ('adaptive slicing plan'). It distinguishes from siblings like 'generate_adaptive_slicing_plan' by indicating this is a post-processing step that produces a readable output, not the plan itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implicitly tells when to use by stating that 'plan_data' comes from two specific functions, but it does not explicitly state when not to use this tool or provide alternatives among the many analysis siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It describes the tool as analyzing and recommending, which suggests a read-only operation, but does not explicitly confirm non-destructive behavior or disclose any side effects, authorization needs, or resource requirements. It adds some context with material-specific defaults but lacks full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bullet-pointed examples, and a docstring-style parameter listing. It is concise enough for the purpose, with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description adequately explains the return value as a dictionary of specific slicer settings. It covers material-specific defaults and examples of structural analysis. It is sufficiently complete for an AI agent to understand the tool's inputs and outputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds useful meaning for both parameters: it clarifies 'file_path' as an STL file path and 'material' as a list of filament types. This compensates well for the empty schema, though it does not cover format or constraints for the file path.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Infer optimal slicer settings from structural analysis.' It uses specific verbs and resources, and provides concrete examples. However, it does not explicitly differentiate from sibling tools like 'predict_print_settings' or 'recommend_settings', which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context through examples of structural issues (thin neck, overhangs, etc.), but does not explicitly state when to use this tool versus alternatives or provide any exclusion criteria. Usage is implied, not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states the basic function and benefits, without mentioning read-only nature, idempotency, or any 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose. The additional paragraph about benefits could be slightly trimmed but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the purpose, usage context, and parameter details. However, it does not describe the format of the returned list, which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (category) is explained in the description, stating it is an optional filter and that omitting it lists all components. This adds meaning beyond the schema's default and type, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists pre-built OpenSCAD components from bundled libraries. It specifies the resource and action, and distinguishes from sibling tools like 'list_available_materials' or 'list_cached_designs' by focusing on OpenSCAD components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool, stating these components are better for complex mechanical parts than generating from scratch. However, it does not explicitly state when not to use it or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes the basic operation without mentioning side effects, state changes, prerequisites (e.g., printer locks), or if it is read-only. The agent lacks safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a docstring format. Every sentence provides value (purpose and parameter explanations). It could be slightly more structured but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the main operation and parameters. However, it lacks details on return values, synchronization, or process flow, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description successfully explains both parameters: 'file_paths' as list of assembly files and 'material' with default 'pla'. This adds meaning beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Split' and 'Assigns') and the resource ('multi-file assembly','printers'). It distinguishes from sibling tools like 'plan_multi_copy_split' by focusing on multi-file assembly for parallel printing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for multi-part assemblies for parallel printing but does not explicitly state when not to use or mention alternatives among siblings. No exclusions or context limits are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It mentions validation and optional certificate generation, but lacks details on side effects (e.g., file deletion, overwriting existing listings), error handling, permissions, or rate limits. This is a significant gap for an upload action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a clear first sentence and a bullet list for parameters. It is efficient without being overly verbose. Minor reduction could be made, but overall it is appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and no output schema, the description covers the action and parameter semantics adequately but misses return value information, error conditions, and post-publishing behavior. It is sufficient for basic understanding but not fully complete for an AI agent to anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the schema: examples for category, enumerated license values, purpose of tags ('discoverability'), and defaults for target_marketplaces and boolean flags. While schema coverage is 0%, the description compensates well, though it could clarify data types and constraints (e.g., file_path format, tags as array).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Publish a 3D model to one or more marketplaces.' It specifies the key actions (validates, optionally generates certificate, uploads) and distinguishes from sibling tools like 'list_published_models' or 'browse_models' by focusing on the publishing action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by detailing the steps and optional features, but it does not explicitly state when to use this tool vs alternatives, nor does it provide prerequisites or exclusions. For example, it doesn't mention that the model must be ready or that 'list_published_models' might be used to verify the result.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that a check result is recorded, but does not reveal behavioral traits such as whether multiple checks can be recorded, idempotency, required permissions, side effects on the recovery session, or rate limits. This lack of detail limits the agent's ability to use the tool safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured. The purpose is stated in the first sentence, followed by contextual framing, then a clear docstring-style list of arguments. Every sentence adds value, with no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and 0% schema coverage, the description should provide comprehensive guidance. It lacks information about return values, side effects, prerequisites (e.g., existing recovery session), error scenarios, and limitations like call frequency. This makes it incomplete for an agent to confidently invoke the tool without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful context for each parameter: 'session_id' is identified as the monitoring target, 'passed' clarifies boolean interpretation (check success), and 'notes' is marked optional. This goes beyond the schema's type-only information, though additional details (e.g., format of session_id) could enhance clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'record' and the specific resource 'post-recovery monitoring check result'. It provides context that this is done after recovery execution to verify print correctness. Among sibling tools like 'plan_print_recovery' and 'complete_print_recovery', this tool's purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after recovery execution, but does not explicitly state when to use this tool versus alternatives like 'start_print_recovery' or 'complete_print_recovery'. No prerequisites, exclusions, or ordering guidance is provided, leaving some ambiguity about the tool's place in the recovery workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description discloses that it is a deprecated alias with identical behavior, mentions defaults for parameters, and describes the return type (dict with repair statistics). It also details the inline 3D stage behavior on success, including automatic decimation for oversized meshes. However, it doesn't disclose side effects like file overwriting by default (though output_path defaults to overwriting input, which is implied) or potential error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact but includes essential information: the deprecation notice, the parameter list, and the behavior on success. The paragraph on the 3D stage is additional but relevant behavioral context. However, the restructured-text formatting (':param') is a bit dense and might be more readable as plain text. Overall, it avoids wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 parameters, no output schema), the description covers the core use case (mesh repair with options), the deprecation status, the return type, and the notable side effect of opening the 3D stage. It doesn't explain the statistics dict structure but that may be unnecessary. The 3D stage behavior is a key context that is well-explained. A minor gap is the lack of error handling or edge cases, but it's adequately complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so all parameter semantics must come from the description. The description provides reasonable explanations for each parameter: file_path (path to STL file), output_path (output path, defaults to overwriting), close_holes (boolean, default True), weld_tolerance (weld radius in mm, with special values for auto and '0' disabling). This adds meaning beyond the schema, but some details like the format of the weld_tolerance string and the exact behavior of close_holes could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a deprecated alias for repair_mesh(close_holes=True) and explicitly directs new callers to the preferred tool. The purpose is clear (repair mesh files), and the description distinguishes it from its non-deprecated sibling repair_mesh by noting the identical behavior with a specific parameter set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: existing callers can keep using it, but new callers should use repair_mesh with close_holes=True. This is clear guidance on when to use this tool vs. the alternative, though it doesn't elaborate on other alternative tools or broader usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (e.g., overwriting existing policy), authorization needs, or whether the printer must be idle. Only parameter defaults are listed, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear purpose sentence followed by a bullet list of parameters. It is front-loaded and efficient, though the parameter list could be slightly more integrated into the prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no required fields, and no output schema, the description covers parameter meanings but fails to explain the outcome of the configuration (e.g., whether it returns success/failure) or how it interacts with other leveling-related tools. Adequate but missing return value context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining each parameter in the docstring, including values like G29 or BED_MESH_CALIBRATE for gcode_command. Some parameters, like printer_name, are clearer due to the hint about default printer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it configures an automatic bed leveling policy for a printer, using a specific verb and resource. It distinguishes from siblings like 'trigger_bed_level' by focusing on policy configuration rather than immediate leveling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests when to use by defining parameters, but provides no explicit context regarding when to use this tool versus alternatives like 'trigger_bed_level' or prerequisites. Usage is implied but not clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions creating a recovery session and tracking lifecycle but omits critical behavioral traits such as idempotency, required permissions, whether multiple sessions can exist, or what happens on re-call. This leaves ambiguity 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise: three sentences that front-load the purpose and then succinctly describe parameters. No redundant information, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a tool initiating a recovery workflow, the description does not mention what the tool returns (expected to be a session ID), which is a significant gap given no output schema. Preconditions (must have a recovery plan) are implied but not explicit, leaving the agent without full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description adds meaning by explaining the source of plan_id (a plan_failure_recovery result) and the role of failure_id. This provides context beyond the schema's type and title, but lacks format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states it begins executing a recovery plan and creates a recovery session. The verb 'start' plus 'print_recovery' clearly identifies the action and distinguishes from sibling tools like 'plan_failure_recovery' and 'complete_print_recovery'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description specifies that plan_id must come from a plan_failure_recovery result and failure_id is the addressed failure, providing clear context for when to use this tool. However, it does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action itself without disclosing potential side effects, destructiveness, reversibility, authentication needs, or error behavior (e.g., untrusting an untrusted host). This is insufficient for an agent to fully understand the impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence) and front-loaded with the action. It is concise but could benefit from slight expansion to cover usage guidelines and return behavior without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers core purpose but lacks details on error handling, success/failure indicators, or prerequisite conditions. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single 'host' parameter with no description. The tool description adds 'hostname/IP', clarifying what the parameter accepts. This provides meaningful semantic context beyond the schema, though further specificity (e.g., IPv4/v6, hostname format) would improve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove a printer hostname/IP from the trusted whitelist', specifying the verb (Remove) and resource (printer hostname/IP from whitelist). It effectively distinguishes from the sibling tool 'trust_printer', which adds to the whitelist.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to remove a trusted printer), but it does not explicitly state when to use it versus alternatives like 'trust_printer' or 'list_trusted_printers'. No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the action (assign printer to site) and the license requirement, but does not explain behavioral details such as whether the operation is destructive (overwrites existing site), idempotent, or what the result looks like. For a mutation tool, more transparency about side effects is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The following 'Args' section is well-structured, listing each parameter with examples. Every sentence adds value, though the format could be slightly more streamlined (e.g., removing the colon after 'site' in the example). No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description covers the essential aspects: purpose, parameters, and license requirement. However, it lacks information about return values (e.g., success indication), error conditions, and potential side effects. For a basic assignment tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema lacks parameter descriptions. The description compensates by explaining each parameter: 'name' is the registered printer name, 'site' is a physical location label with clear examples ('nyc-lab', 'chicago-floor-2'), and 'tags' are comma-separated key=value pairs with an example. This adds significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Assign a printer to a physical site/location with optional tags,' providing a specific verb (assign) and resource (printer to site). The tool's name 'update_printer_site' reinforces this, and among siblings there is no other tool that specifically performs this site assignment, making it easily distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when assigning a printer to a site) and notes a prerequisite ('Requires Enterprise license'), but does not provide explicit guidance on when not to use it or suggest alternative tools (e.g., register_printer if the printer is not yet registered). The usage context is clear but lacks comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions it uses heuristics and suggests recovery steps, but does not disclose side effects (e.g., whether it modifies state, logs data, or requires specific permissions). The behavioral impact is under-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise 6-line docstring that front-loads the purpose and uses, then lists args efficiently. No redundant or irrelevant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's inputs and high-level behavior but omits the output format (e.g., how recovery steps are structured). Given no output schema, this gap leaves the agent uncertain about the return value's structure. Still adequate for an analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section adds meaning for all 4 parameters: progress range (0.0-1.0), error_message, printer_name, job_id. This compensates significantly for the schema lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies a print failure and suggests recovery steps, using heuristics based on error messages, progress, and failure history. This distinguishes it from sibling tools like 'analyze_print_failure' (likely simpler) and 'detect_print_failure' (detection only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a print failure occurs to get classification and recovery steps, but does not explicitly state when not to use or compare to alternatives. Sibling tools are not mentioned, and no exclusions or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description describes the analysis but does not explicitly state that it is read-only or non-destructive. For a tool with no annotations, the burden is on the description to disclose behavioral traits; it partially meets this by describing the checks but omits safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus an args line. It front-loads the action and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema, no annotations), the description covers the purpose and checks but lacks specification of return value (e.g., score, boolean) and error cases. Moderate completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter file_path is described as 'Path to the snapshot image file,' providing context beyond the schema's type string. With 0% schema description coverage, this compensation is adequate but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a webcam snapshot for print monitoring quality, listing specific checks (brightness, variance, resolution, format) and the output determination (usability). It distinguishes itself from sibling tools like analyze_print_file by focusing on snapshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for webcam snapshots but does not explicitly state when to use this tool vs alternatives (e.g., analyze_print_failure). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It describes the analysis outputs but does not disclose whether the tool is read-only, modifies the file, has side effects, or requires specific file validity. A read-only analysis tool should state 'does not modify the file' for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary and bulleted outputs, then a clarifying example. The example sentence is slightly verbose but adds value. Overall efficient for the detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return dictionary keys and the reasoning approach. It covers what the tool does and the main input requirement. Missing error conditions or limitations, but for a single-parameter tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'file_path' is described as 'Path to the STL file', adding format specificity beyond the schema's 'File Path'. However, it does not clarify if the path must be local or remote, or if file existence is checked. With 0% schema coverage, the description partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes load-bearing characteristics from mesh geometry. It lists specific outputs (primary_load_axis, load_surfaces, etc.) and contrasts with simple material lookup, distinguishing it from sibling tools like analyze_mesh_geometry.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when geometric reasoning is needed (e.g., 'this bracket should be printed on its side'), but does not explicitly state when not to use or suggest alternative tools. The example helps contextualize, but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that a copy of SQLite database is created and sensitive fields are redacted by default. No annotations provided, so description carries full burden. It adds basic behavioral details but omits potential side effects like database locking or performance impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with purpose. The Args section adds clarity but is slightly formal. No wasted sentences; every sentence contributes information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 2 parameters, no output schema, and no annotations, the description covers purpose, default behavior, and both parameters adequately. It lacks error scenarios or prerequisites but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates well. It explains output_path default pattern and redact default and meaning. This adds significant value beyond the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Back up the Kiln database with optional credential redaction,' using specific verb and resource. Among sibling tools, none are database backup, so it is well-differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives or when not to use it. With hundreds of sibling tools, lack of usage context makes it hard for an agent to select this tool appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and it does well: it discloses the inline 3D stage behavior, automatic decimation for oversized meshes, and the fallback link for unsupported hosts. It also notes optional validation, though it doesn't explain what validation entails. This adds meaningful behavioral context beyond just 'download'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with a clear structure: the main purpose, then arguments, then a detailed note about the inline stage. The stage paragraph is long but introduces important side effects. It avoids redundancy and is front-loaded with the core action, so it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the parameters and the inline viewer side effect, but it omits details about return values (e.g., file path, success message) and does not explicitly state the prerequisite that the generation job must be completed (though the name implies it). It also doesn't mention error conditions or when validation is triggered. For a tool with no output schema, more context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly explains all three parameters: job_id ('Job ID of a completed generation job'), provider ('Provider that owns the job (meshy or openscad)'), and output_path ('Directory to save the file. Defaults to system temp directory'). This fully compensates for the 0% schema coverage and gives clear meaning beyond raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads a completed generated model and optionally validates it. It identifies the key resource (generated model) and the action (download). The name itself is specific and distinguishes it from generic download tools like 'download_model', but the description could more explicitly contrast with siblings like 'preview_generated_model'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the tool requires a completed generation job (implied by 'completed generated model') and explains the parameters (job_id, provider), but it does not explicitly state when to use this tool versus alternatives (e.g., download_model, preview_generated_model). There's no guidance on when not to use it or what substitutes exist, so the context is thin.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses it's a ballpark estimate, depends on slicer settings, and works directly on mesh files. However, it does not state whether the tool is read-only, what happens on invalid meshes, or any constraints like file size. The disclaimer about slicer dependence adds some context but not comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise at 6 lines, front-loads the purpose, and uses docstring style. However, the parameter list could be more compact. Every sentence adds value, so it earns a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions the return value as a dict with estimated time, layer count, and note, which is helpful but lacks detail on key names or types. With 4 parameters and moderate complexity, the description is adequate but not thorough. Missing details like error handling or file format compatibility beyond the listed formats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only provides minimal docstring-like explanations (e.g., ':param file_path: Path to mesh file.'). These add little beyond parameter names and defaults already in the schema. For example, 'material' parameter is not explained beyond 'Material hint (affects per-layer overhead).' This is insufficient to fully understand the parameters' roles in the estimate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a rough print time estimate from mesh geometry (STL/OBJ/GLB) and explicitly distinguishes itself from the sibling tool estimate_print_time, which uses slicer profiles. The verb 'estimate' and resource 'mesh print time' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells when to use this tool (before slicing, directly on mesh files) and contrasts it with estimate_print_time, but does not explicitly state when not to use it or mention other alternatives besides that one sibling. The guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states the tool returns matching listings but does not mention side effects (likely none), authentication requirements, rate limits, pagination, or any other behavioral details. For a query tool with no annotations, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear front-loaded purpose and succinct parameter explanations. Every sentence provides value without redundancy. The structure is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no annotations), the description covers purpose and parameters adequately. However, it lacks details about the output format, pagination behavior, error handling, or any behavioral constraints. For a fully standalone description, this leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The JSON schema has 0% description coverage, so the description compensates by providing meaningful parameter descriptions. It includes examples for 'material' (e.g., PLA, PETG) and clarifies that 'location' is optional with a geographic example. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find available provider capacity by material/location', specifying the action (find), resource (provider capacity), and filtering criteria (material/location). This distinguishes it from sibling tools like 'list_provider_capacity' which likely returns all capacity without filtering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when filtering by material/location is needed, but it does not explicitly state when to use this tool versus alternatives like 'list_provider_capacity'. No exclusions or prerequisites are mentioned, leaving guidance somewhat vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, and the description only mentions that the tool 'Reads the STL file', which gives a hint about input but does not state whether the operation is read-only, if it modifies anything, or if it requires special permissions or network access. This lack of behavioral transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly repetitive, repeating the list of fingerprint contents (hash, counts, bounding box, etc.) twice and the explanation about geometric_signature_v2 also twice. This verbosity reduces clarity and could be condensed into a single concise statement, making the structure less efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and output contents, including which signature to use downstream. However, it lacks details about error handling, file size or format constraints, and the exact structure of the returned fingerprint object, leaving some contextual gaps that might affect its completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter file_path is clearly described as 'Path to the STL file to fingerprint.' The description provides enough context for its meaning, and since it is the only parameter, there is no ambiguity about its purpose or required format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a geometric fingerprint for a 3D model file, listing all components including SHA-256 hash, triangle/vertex counts, bounding box, surface area, volume, overhang ratio, complexity score, and two geometric signatures. It also specifies which signature (geometric_signature_v2) should be used downstream, 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a fingerprint is needed for downstream tools like record_print_dna, predict_print_settings, find_similar_prints, and contribute_community_print, as it explicitly states which signature to carry into those tools. However, it does not explicitly contrast with alternative tools or provide conditions when not to use this tool, so the 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the operation but does not disclose any side effects, required permissions, state changes, or preconditions. The agent cannot infer if this tool is safe to call without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear summary followed by parameter details. It is front-loaded with the main purpose. However, the parameter list could be slightly more structured (e.g., using bullet points) to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and parameters, but it does not describe the output format (the generated plan structure) or any prerequisites (e.g., must call analyze_model_geometry first). Given the lack of an output schema, this leaves the agent with gaps in understanding the full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds detailed meaning for all parameters. For example, 'regions' is described as a list of dicts from analyze_model_geometry with specific keys, and 'mode' lists the four allowed values. This provides essential context beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates a per-layer adaptive slicing plan with variable heights, speeds, and cooling. It distinguishes from sibling tools like 'quick_adaptive_plan' and 'estimate_adaptive_time_savings' by specifying the output is a per-layer plan based on geometry regions and material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning geometry regions and material constraints, but does not explicitly state when to use this tool over alternatives like 'quick_adaptive_plan' or when it is appropriate. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool queries print history and builds a certificate, implying a read-only operation. However, it does not specify behavior for missing file_path, empty history, or potential side effects (none expected, but unstated). Annotations are absent, so description carries the burden but is only moderately complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the primary purpose, and followed by a clear bullet of what the certificate contains. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is adequate but lacks details on return format, error handling, or edge cases (e.g., missing history). It covers the core functionality but leaves minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that explains file_path as 'Path to the 3D model file,' adding meaning beyond the schema's type-only definition. Schema coverage is 0%, so description compensates well for this single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: generate a print 'birth certificate' for a 3D model by querying print history and building a certificate with specific contents. This is a unique verb+resource combination that clearly distinguishes it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_model_print_history or analyze_print_failure. The description does not specify prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the return types (Amazon search links and manufacturer URLs) and the effect of the color parameter. However, it does not mention any potential failure modes, side effects, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, conveying purpose and parameter details in a few sentences. It is front-loaded with the main action, and the args are clearly listed. No redundant information, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 parameters, no output schema), the description adequately covers the input parameters and output type (URLs). It explains what the function returns and how parameters affect behavior. It is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 includes an explicit 'Args' section explaining each parameter: material_id as a catalog ID with an example, and color as optional for URL personalization. This adds meaningful context beyond the schema's type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves purchase URLs for a material, specifically Amazon search links and manufacturer URLs, and explains color substitution. This effectively distinguishes it from sibling tools like 'get_material' or 'get_material_info' which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or how it compares to other material-related tools. The usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'list all' implying read-only, but fails to disclose ordering, pagination, authentication requirements, or any side effects. More detail is needed for safe usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action and resource, containing no extraneous words. It is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at what information each spool entry contains (e.g., id, material, weight). It only says 'filament spools' without return structure, leaving the agent uncertain. However, for a simple list tool, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, described fully by the schema (100% coverage). The description adds no parameter information, but none is needed. Baseline for 0 params is 4, and the description doesn't detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'list' and resource 'tracked filament spools in inventory', clearly distinguishing it from sibling tools like add_spool and remove_spool. It accurately states the tool's purpose without any vagueness or tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other list tools (e.g., list_available_materials). Since it has zero parameters, usage is straightforward, but explicit context about when to prefer this over alternatives is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects (e.g., whether logging is immutable, modifies project state), permissions beyond Enterprise license, idempotency, or rate limits. The description focuses on parameters rather than behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by a clean Args list. Every line is informative, no fluff. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers parameters and license requirement adequately. However, it lacks information on return values, error conditions (e.g., invalid project_id), validation behavior, or examples. This makes it minimally complete for a simple logging tool but leaves some uncertainty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 all 6 parameters with meaningful context: category with specific enum values, amount in configured currency, optional printer_name and job_id for traceability. This adds significant value beyond the schema (which only provides names, types, and titles). Minor gaps: no format constraints on 'amount' (e.g., positive) or 'description' length.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Log a cost entry against a project.' This is a specific verb ('Log') and resource ('cost entry') with clear scope ('against a project'). It distinguishes from siblings like 'create_project' (creates projects) and 'project_cost_summary' (summarizes costs).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Requires Enterprise license' as a constraint but does not explicitly state when to use this tool vs alternatives (e.g., estimate_cost, project_cost_summary). It implies usage for recording actual costs to existing projects but lacks exclusions or guidance on alternative tools. Given the large sibling list, some differentiation would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states what the tool returns but does not disclose side effects, authentication needs, rate limits, or whether it is read-only. The lack of behavioral disclosure is a gap for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and front-loaded with the purpose. It includes examples in a structured list. A minor improvement would be to trim the initial repetition of the purpose in the first two lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (import lines, example usage, parameters, guidance) and gives examples. Without an output schema, this is adequate. Missing error handling or limitations, but sufficient for a simple one-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'description' is explained as 'Natural language description of the design' and illustrated with examples. Given that the schema has 0% coverage (no parameter descriptions), the description compensates effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Find pre-built library components matching a design description' and elaborates on returning import lines, example usage, and parameters. Examples clarify the input-output mapping. It distinguishes from sibling tools like list_design_components and match_design_requirements by focusing on natural language matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for finding components from a design description but does not explicitly state when to use it versus alternatives (e.g., list_design_components). No when-not-to-use guidance is provided, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It describes the extraction process and output content, but does not explicitly state that the operation is read-only or non-destructive. This leaves ambiguity about 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient with three clear sentences covering purpose, behavior, and usage context. It is front-loaded with the core action and avoids unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description covers the main aspects. However, it does not mention the return format or any edge cases, leaving room for improvement for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with 0% description coverage. The description only repeats the parameter name and a generic type ('OpenSCAD source code string'), adding no additional meaning or formatting details beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Parse' and the resource 'parameter variables from OpenSCAD code', with specific details about what is extracted (values, units, descriptions, ranges). It distinguishes itself from siblings like analyze_scad_code and validate_openscad_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this after generating OpenSCAD code to discover which parameters can be adjusted.', providing clear context and purpose. However, it does not mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses core behavior: continues from next unfinished step. No annotations provided, so description carries burden. Missing details like error conditions (e.g., pipeline already running), authentication needs, or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus an Args line. No redundant information, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-param tool, description covers purpose, parameter, and behavior. Nearly complete but lacks prerequisites or return value info (no output schema).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, description adds minimal meaning: parameter is 'pipeline execution ID'. Does not explain format, origin, or required constraints beyond what schema's title provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool resumes a paused pipeline from where it stopped, using specific verb 'resume' and resource 'pipeline'. Distinguishes from sibling tools like pipeline_pause, pipeline_abort.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for resuming paused pipelines, but no explicit guidance on when not to use or alternatives. Lacks context like 'only use on paused pipelines' or comparison to pipeline_retry_step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses that the tool analyzes mesh geometry and returns risk scores with fix suggestions, implying read-only behavior. However, it does not mention side effects, performance, or data handling, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences stating purpose and analysis scope, followed by parameter docs. No wasted words, front-loaded with the verb and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description specifies the return type (Dict with verdict, risk score, failure list) and covers key inputs and behaviors. It could detail the output structure more, but it is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes :param documentation for all four parameters, explaining their meaning (file_path, min_wall_mm, max_bridge_mm, max_overhang_deg) and defaults. This fully compensates for the 0% schema description coverage, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool predicts common 3D printing failure modes from mesh geometry and lists specific failure types. However, it does not differentiate from sibling tools like analyze_print_failure or detect_print_failure, which may have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With many sibling tools for print failure analysis, the lack of usage context or exclusions leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'Requires Enterprise license' as a behavioral constraint and describes the return value. However, it does not state whether the tool is read-only or has side effects, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, front-loading the purpose and return details. It could be slightly tighter by merging the first two sentences, but overall it is efficient and well-structured with a clear separation of purpose, returns, args, and requirements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description adequately covers purpose, return values, parameter meaning, and a key prerequisite (Enterprise license). It does not mention data freshness or aggregation details, but for a summary tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds important context for the single parameter 'project_id' by specifying it is 'the project ID returned by ``create_project``'. This clarifies the origin and expected format beyond the schema's simple type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get cost breakdown for a project' with specific return details (total costs, per-category breakdown, budget utilization). This distinguishes it from sibling tools like 'estimate_cost' which focus on estimation rather than retrieving actual summarized data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The only prerequisite mentioned is 'Requires Enterprise license', but there is no discussion of use cases, when not to use, or comparison to sibling tools like 'log_project_cost' or 'estimate_cost'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral traits. It implies read-only behavior by stating it 'analyses' and 'suggests,' but does not explicitly confirm non-destructiveness, permission requirements, or other behavioral aspects like impact on system state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a short paragraph with a clear summary sentence, explanatory detail, and an 'Args' section for the parameter. Every sentence adds value, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 1 parameter (complex object) and no output schema, the description adequately covers the input requirements but lacks description of the output format (e.g., structure of swap suggestions). It is fairly complete but could be improved by specifying what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by specifying that each job dict should contain 'material_type' and 'required_grams'. Since schema coverage is 0%, this provides essential guidance that the raw schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb+resource: 'Suggest minimal spool swaps to run all queued jobs.' It explains the analysis and distinguishes from siblings like 'suggest_material_for_order' or 'suggest_printer_for_job' by focusing on physical spool changes for queued jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have queued jobs and want to minimize spool swaps, but it does not explicitly state when to use this tool versus alternatives (e.g., 'suggest_material_for_order'), nor does it mention prerequisites or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the confirmation step and that the upload is executed upon calling this tool. However, it does not mention any side effects, whether the operation is irreversible, permissions required, or what happens on success/failure. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of three short, clear sentences. It is well-structured: first sentence states purpose, second explains the mechanism, third describes the parameter. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool with one parameter and no output schema, the description covers the essential flow. However, it omits return value/status, error cases, and prerequisite that upload_file must be called first. While the token explanation is good, the lack of post-call behavior details leaves the agent guessing about outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its single required parameter 'token'. The description adds meaning by stating: 'The confirmation token returned by upload_file().' This clarifies the parameter's source and purpose, compensating for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Confirm and execute a pending file upload.' It specifies the two-step flow where upload_file returns a token when KILN_CONFIRM_UPLOAD is enabled, and this tool uses that token. This effectively distinguishes it from the sibling tool upload_file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when a token from upload_file is available) and mentions the enabling condition (KILN_CONFIRM_UPLOAD). However, it does not explicitly state when NOT to use it, nor does it mention alternatives like direct upload without confirmation. The guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description describes the analysis and returns a risk assessment, but does not disclose behavioral traits such as read-only nature, required permissions, or computational intensity. It lacks full disclosure of side effects or safety information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, details on what it examines, output fields, parameters, and examples. It is concise enough while being thorough; each section adds value, though some wording could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides comprehensive information about return fields (risk_level, score_deduction, etc.), parameters with defaults and examples, and the overall workflow. It covers all necessary context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by explaining file_path as 'Path to STL or OBJ file', material with examples and default, and printer_id with its purpose. This compensates for the schema's lack of descriptions, effectively covering all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes warping risk for a 3D model based on geometry and material. It distinguishes itself from sibling tools like 'analyze_printability' by focusing specifically on warping risk factors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does and provides examples, but does not explicitly state when to use this tool over alternatives like 'analyze_printability' or 'analyze_model_geometry'. No when-not or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses return values (status, upgrades, notes) and suggests no destructive behavior. However, it does not mention auth requirements, rate limits, or error conditions, which are relevant for a query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear structure: one-line purpose, return format, usage case, and Args section. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-param tool with no output schema, the description adequately explains inputs, outputs, and typical use case. Could mention if printer/material must be in a known catalog, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage (no descriptions on properties). The description compensates by providing example values, format (underscores, lowercase), and context for both printer and material parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks printer-material compatibility and returns status, upgrades, and notes. It uses specific verb+resource, but does not explicitly differentiate from sibling tools like check_printer_material_support.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context with a user question example. Offers format guidance for parameters (e.g., 'use underscores, lowercase'). Lacks when-not-to-use guidance, but the example sufficiently frames when to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes what is shown but fails to disclose whether the tool is read-only, if any side effects occur, or authorization requirements. The name and content imply retrieval, but no explicit behavioral traits are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a list of returned details, and a parametric docstring. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (one simple param, no output schema), the description is fairly complete. It explains what the tool returns (Dict with details and file paths). However, it lacks examples or clarification of terms like 'proven settings'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning by specifying that 'name' is a 'Decoration name or slug', which clarifies the parameter beyond the schema's type/title. Additional context like return type also aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves full details about a saved decoration, listing specific attributes like settings, paths, and tags. It distinguishes from siblings like 'list_decorations' (which lists all) and 'save_decoration' (which creates/modifies).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like 'list_decorations' or 'save_decoration'. It implies usage for a specific decoration but lacks context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It lists what it reports (encryption active, key configured, library installed) but fails to disclose behavioral traits like permissions required, side effects, or whether it is read-only. It lacks sufficient transparency for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the main purpose. Every sentence adds value without redundancy or fluff. Perfect structure for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and low complexity, the description covers the essential information: what it checks and that it's enterprise-only. It is marginally complete but could benefit from indicating the output format or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema description coverage is 100% (trivially). The description adds no parameter information because there are none. Baseline for 0 parameters is 4, and the description does not detract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check G-code encryption status and configuration', which is a specific verb and resource. It distinguishes from sibling tools like 'rotate_encryption_key' (which modifies) and 'license_status' (which checks license), making its purpose unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is an 'Enterprise feature', implying usage restrictions, but does not explicitly state when to use this tool versus alternatives (e.g., rotate_encryption_key). No exclusions or alternative suggestions are provided, only the types of information reported.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It explains the load_across_layers parameter's effect on capacity derating but omits the output format, algorithm assumptions, or limitations. It adds value beyond parameter names but leaves behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear introductory sentence followed by a structured Args block. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains parameters well but omits critical context: the output format (units, whether it's max load or factor), error handling for invalid materials, and underlying assumptions. For a structural load tool, these gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so the description must fully explain each parameter. It provides clear explanations for all four parameters, including examples for material, units for dimensions, and a detailed rationale for load_across_layers. This adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool estimates safe structural load for a cantilevered section, a specific engineering task. It distinguishes from broader analysis tools like analyze_structural_risks or assess_load_bearing by focusing on a single cantilevered section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like assess_load_bearing or analyze_structural_risks. It only describes the tool's functionality without exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention side effects, permissions, or return type. While 'Find' implies a read operation, the description fails to confirm read-only behavior or any other traits like rate limits or scope (e.g., public vs user-specific).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and a clear argument block. Every part is useful: the verb, resource, parameter name, and examples. No unnecessary repetition. Front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one required parameter, no output schema, and low complexity, the description is sufficient to understand the tool's intent. However, it omits what the returned summaries contain (e.g., text, images) and how to proceed after finding one. Still, for a simple search tool, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage for the single parameter 'use_case'. The description compensates by providing concrete examples ('enclosure', 'gear train', 'battery cover', 'vase'), which adds meaning beyond the bare schema definition. However, it does not specify format or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Find') and the resource ('public design-template summaries') with a specific filter ('for a use case'). It distinguishes from siblings like 'search_design_templates' by emphasizing 'public' and 'summaries', and from 'list_design_templates' by requiring a use case parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when you need to find templates for a specific design task) but does not explicitly guide when not to use it or mention alternatives like 'search_design_templates' or 'list_design_templates_catalog'. The context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses basic behavior and return fields but does not clarify what happens if no slicer is found (e.g., returns null/error) or system-specific behavior. Basic transparency is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two front-loaded sentences. No unnecessary words or repetition. Efficiently conveys purpose and return information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description covers the main functionality. However, it could improve by specifying behavior when slicer is not found or addressing potential errors. Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so schema coverage is 100%. Baseline score of 3 applies; description adds no parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool checks if a slicer (PrusaSlicer/OrcaSlicer) is available, and specifies return fields (path, name, version). It distinguishes itself from sibling tools like get_slicer_profile and list_slicer_profiles by focusing on availability detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking slicer availability but does not explicitly state when to use it versus alternative tools like get_slicer_profile or list_slicer_profiles. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the return type as a summary and implies a read-only operation, but does not explicitly state side effects (none expected), permissions required, or behavior in edge cases (e.g., empty fleet). This is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action verb 'Aggregate', and every word adds value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequately explains what it returns. However, it could be slightly more complete by mentioning whether data is real-time or cached, or what happens when no materials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds meaning by detailing the structure of the output (per-material summary with stock, spool counts, printers, colours), which exceeds the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates material inventory across all printers and spools, and specifies the return fields (total stock in grams, spool counts, printers loaded, available colours). This distinguishes it from sibling tools like fleet_analytics (broader) or get_material (single material).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. While the purpose implies a fleet-level overview, it does not mention when not to use it (e.g., for specific printer material status) or provide any comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the aggregation and conversion behavior but does not disclose the output format or handle edge cases (e.g., no completed prints). With no annotations, the description should provide more detail on return structure and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with front-loaded purpose. Two sentences plus a parameter line efficiently convey the tool's functionality without any extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is mostly complete. It covers the main operation, aggregation logic, and parameter semantics. However, describing the return format would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'days' is well-described as a lookback window with a default of 30. This adds meaning beyond the schema's type and default, clarifying its purpose and usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves material consumption history from completed prints, aggregates per material type, and converts filament length to grams. This is specific and distinct from siblings like 'forecast_material_consumption' or 'get_material'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'forecast_material_consumption'. While the purpose is clear, the description lacks explicit context for selection, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool 'returns a machine-readable description' but does not disclose if the operation is read-only, potential side effects, authentication needs, or rate limits. This lack of behavioral detail is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the primary action. It is well-structured and avoids unnecessary details, though it could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is fairly complete for a simple info retrieval. It explains the purpose and when to use, but lacks specifics on output format (e.g., JSON) and exact contents, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100%. According to guidelines, baseline is 4. The description doesn't need to add parameter info, and it correctly omits any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb 'Get' and the resource 'skill manifest', specifying it is for agent self-discovery. It distinguishes the tool from 200+ siblings by its unique purpose of providing a machine-readable description of Kiln's capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'when first connecting to understand what Kiln can do and what configuration is needed.' It provides clear context but does not mention alternatives or when not to use it, which is acceptable given the unique function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses key behaviors: error handling for missing backend (code='NO_BACKEND' with remedy), output format auto-selection, and the 3D stage side effect. However, it does not mention file writing side effects or other potential failures, and the repetitive structure obscures these details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively verbose and repetitive. The core content is duplicated almost verbatim multiple times, making it bloated and hard to parse quickly. Many sentences do not earn their place due to redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers conversion, backends, output format, validation, and error handling, providing a fairly complete picture. However, the repetition hinders clarity, and it omits details like success return values or file system effects beyond the 3D stage mention.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to all parameters. It explains output_format's 'auto' behavior with conditions, merge_bodies' effect on STL output, output_dir's default, and file_path is self-evident. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: importing STEP files and converting them for Kiln's mesh pipeline. It specifies the input format, conversion behavior, and output formats, distinguishing it from other file operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool (import STEP) and what to do before/after (check_step_support, diagnose_mesh). It also explains output format selection rules, giving the agent clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses ordering behavior and default limit via the 'limit' parameter description, but lacks details on pagination, total count, or potential side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, using four sentences covering purpose, parameters, and returns. No redundant information, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool without output schema, the description covers the essential context: what it does, parameters, and ordering. Lacks mention of pagination or difference from 'search_design_versions', but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The 'Args' section in the description adds meaning to both parameters: design_id is explained as 'the design whose versions to list', and limit includes default and maximum semantics. Since the schema has 0% description coverage, this significantly aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'version history for a design', and specifies ordering ('newest first'). This distinguishes it from the sibling tool 'search_design_versions', which implies filtering or searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention when to prefer 'search_design_versions' over listing all versions, nor any context for usage limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The tool has no annotations, so the description carries the burden. It describes a read-like operation (listing), which is likely safe, but it does not explicitly state that it is non-destructive or has no side effects. Given the simplicity, this is acceptable but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is front-loaded with the verb and resource, and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 complete enough. It states what it lists and what information is provided (status). There are no gaps for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description adds the detail that it lists status, which provides meaning beyond the empty schema. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all discovered plugins and their status. The verb 'List' and resource 'plugins' are specific, and it distinguishes from sibling list tools by focusing on plugins, which is a distinct resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It is implied that it is used to obtain plugin information, but there is no mention of prerequisites or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to state read-only nature or output format. 'List' implies safety, but behavioral traits are minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded, no fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers what it does and gives context (examples). Could mention the return type or typical use, but largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. No additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available pre-validated print pipelines' with concrete examples like quick_print and calibrate, distinguishing it from siblings that perform specific pipelines or actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied for listing pipelines, but no explicit when-to-use or alternatives are given. Given the simplicity, it suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that include_addresses defaults to False to avoid exposing personal details. No annotations exist, so description carries burden. No mention of permissions, rate limits, or return behavior beyond the parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for purpose, one for parameter. No extra verbiage. Front-loaded with core purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks response format, pagination, error handling, or confirmation. With no output schema, description should explain what a 'shipping profile' contains. Adequate for its simplicity but incomplete for full agent self-sufficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but the description fully explains the parameter: why it defaults to False, what it includes (full contact/address fields), and the rationale for defaulting. Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'list' and resource 'saved local shipping profiles'. Distinguishes from sibling tools like save/delete_shipping_profile. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like save_shipping_profile or search tools. No when-not or prerequisite context. Implied usage is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It clearly states the tool is a read-only check and describes the output (list of sources, status, credential presence). It does not discuss side effects, rate limits, or authentication, but given the tool's simplicity, this is arguably sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, and contains no extraneous information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 params, no output schema), the description provides enough context to understand what it does and when to use it. It does not cover edge cases or data freshness, but these are reasonable omissions for a status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks which 3D model marketplaces are connected and available, and specifies the return values. However, it does not explicitly differentiate from sibling tools like marketplace_diagnostics or marketplace_info, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete use case ('Use this to verify marketplace access before searching or downloading models'), but it does not mention when not to use this tool or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool performs physical calibration steps (homing, auto bed leveling) and returns printer-specific guidance from an intelligence database. However, it does not detail side effects, safety implications, or the state of the printer after execution, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear summary paragraph and a separate parameter list. It avoids redundancy and is well-structured, though the parameter listing could be integrated more seamlessly. It earns its place with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (full calibration pipeline), no output schema, and 0% schema coverage, the description explains what the tool does and what it returns (intelligence tips). However, it lacks details on return format, error conditions, and prerequisites, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by labeling 'printer_name' as 'Registered printer name' and 'printer_id' as 'Printer model ID for calibration guidance'. However, both parameters are optional with no clarification on required scenarios or behavior when omitted, partially compensating but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Full calibration pipeline: home + bed level + printer-specific guidance (recommended)' and distinguishes from sibling 'calibrate_direct' by noting it is higher-level and orchestrates the full sequence. The specific verb 'run' and resource 'calibrate' with explicit steps (homing, auto bed leveling) make 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies when to use this tool by stating it is 'recommended' and higher-level than 'calibrate_direct'. It provides clear context but does not explicitly state when not to use it or list alternatives beyond the sibling comparison, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the checkpoint's purpose and how it's used by other functions, but does not discuss side effects (e.g., overwriting previous checkpoints), error conditions, or authentication requirements. Adds context but lacks some behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat long due to the parameter list, but it is well-structured: a clear purpose sentence, followed by explanation, then a parameter block. Could be slightly more concise, but overall efficient and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain return values. It does not mention what the tool returns (e.g., success confirmation, checkpoint ID). Given the complexity (9 parameters, no output schema), this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 provides a full parameter list with explanations for all 9 parameters, adding meaning beyond the schema (which only has titles and types). This is excellent compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save a checkpoint during an active print for accurate resume', specifies the resource (checkpoint), and explains the keying mechanism and integration with other functions. This distinguishes it from siblings like 'start_print', 'pause_print', etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the benefit of using this tool (more accurate resume_z_mm) but does not explicitly state when to use it vs alternatives, nor does it provide exclusions or when not to use it. Usage is implied but not clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: slicer auto-detection, auto_center crash prevention, and return format. However, it omits side effects, file modifications, or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro and an Args section. The auto_center explanation is longer but justified. Overall concise, though slightly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 params, 1 required, no output schema), the description covers most aspects: input, outputs, and follow-up tools. It lacks error handling or permission details, but is adequate for a slicing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to all 6 parameters beyond the schema (which has 0% coverage). It explains defaults, auto-detection, and the auto_center crash mechanism in detail, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool slices 3D models (STL/3MF/STEP) to G-code using specific slicers. It is specific about the verb and resource but does not differentiate from sibling tools like slice_and_estimate or reslice_with_overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. The description implies it is for general slicing, but given many sibling tools also slice, it fails to provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals that the tool 'iteratively adjusts parameters' and returns solved/violated constraints. It does not disclose potential side effects, performance limits, or error handling, but covers the core behavior adequately for a solver tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a one-line summary followed by detailed explanation and parameter definitions. It is slightly verbose but every sentence adds value. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (solving constraints), the description explains the iterative algorithm, constraint format, and return structure. It does not cover unsolvable cases or timeout behavior, but covers the essential aspects well for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, but the description provides detailed semantics for both parameters: template_id with an example ('shelf_bracket'), and constraints with a full JSON example and supported keys (min, max, equals, ratio). This compensates fully for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Solve' and resource 'parametric constraints' with a clear goal 'to find valid template parameters'. It immediately conveys the tool's purpose and distinguishes it from other tools like 'generate_template_variations' or 'optimize_template_params' by focusing on constraint solving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. Without explicit usage context, the agent may struggle to select the correct tool among siblings like 'optimize_template_params'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses what information is returned but does not explicitly state that the operation is read-only or has no side effects. The 'Enterprise feature' hint adds some transparency about access restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence clearly states the purpose, and the second lists the return fields. Efficient use of words without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 adequately explains what the tool returns. However, it does not explicitly mention that this is a read-only operation, which would enhance completeness for an enterprise admin tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not add parameter information. Baseline score of 4 is appropriate as there is no schema information to supplement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Check' and the resource 'SSO configuration status', and lists specific return fields (configured, protocol, issuer, allowed domains, role mapping). This distinguishes it from related sibling tools like configure_sso, sso_exchange_code, and sso_login_url.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'Enterprise feature', which implies intended audience but lacks explicit guidance on when to use this tool versus alternatives like configure_sso. No when-not-to-use or context about prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral traits. It mentions that the job is 'provider-managed' and returns a reference, implying asynchronous behavior, but does not disclose specifics like authentication requirements, rate limits, failure modes, or side effects (e.g., costs). This minimal disclosure is insufficient for a tool that integrates with external services.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It begins with a clear purpose statement, followed by a bulleted list of arguments with explanations, and ends with the return value and follow-up suggestion. Every sentence adds value; there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 3-parameter tool with no output schema, the description covers the input parameters and the return value (a job reference). It mentions a follow-up tool for tracking. However, it does not address prerequisites (e.g., need a connected provider account), error conditions, or the async nature of the operation. These omissions leave some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining each parameter's purpose: 'file_url' as a public URL, 'material' with examples, and 'printer_id' with the auto-assignment behavior. With 0% schema coverage, the description compensates adequately. However, it lacks details on valid URL formats, material list restrictions, or printer ID format, preventing a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Submit a print job') and the context ('through a connected provider integration'). It distinguishes this tool from siblings by specifying that it works with a provider integration, as opposed to direct submission. The verb 'submit' and resource 'print job' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for the optional printer_id parameter ('If omitted, provider auto-assigns'), giving some guidance on when to use it. It also directs users to use 'provider_job_status' for tracking, indicating a follow-up step. However, it does not explicitly state when to use this tool versus alternatives like 'submit_job', nor does it mention prerequisites (e.g., having a connected provider account). There is no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool searches a database, returns causes/fixes, and for Bambu HMS codes echoes the code with a link and optionally a decoded cause with Kiln Pro. It implies read-only behavior but does not explicitly state it has no side effects. With no annotations to rely on, the description provides moderate transparency but could be more explicit about traits like non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, examples, and argument explanations. It is front-loaded with the tool's purpose and avoids unnecessary information. However, it is somewhat verbose with multiple examples, earning a score of 4 rather than 5 for perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the input parameters well and hints at the output (echoed code, link, decoded cause). However, it lacks details about the overall response structure, error handling, or additional context for non-Bambu printers. It is functional but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 3 parameters but no descriptions. The tool description explains each parameter: printer_id as model identifier, symptom as problem description (optional if hms_code given), and hms_code as optional Bambu error code. This adds significant meaning beyond the bare schema, clarifying usage and optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Diagnose a printer issue by searching the known failure modes database.' It specifies the action (diagnose), the resource (failure modes database), and provides concrete examples of symptoms and HMS codes, distinguishing it from sibling tools like 'troubleshoot_print_issue' which may have a different scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage instructions: describe the symptom or pass an HMS code for Bambu printers. However, it does not explicitly state when to use this tool versus alternatives (e.g., other diagnostic tools in the sibling list) or when not to use it. The guidance is present but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It correctly states the tool checks HMAC signatures and returns counts and status, implying a read-only operation. However, it does not explicitly confirm it is non-destructive or mention any prerequisites (e.g., access to audit logs). Some ambiguity remains about whether it modifies any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences that immediately convey the purpose ('Verify HMAC signatures') and the outcome ('Returns counts...'). Every sentence adds value, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 aspects: what it does and what it returns. It lacks details on error handling, prerequisites, or how the integrity status is determined (e.g., boolean or string), but these are minor omissions for a straightforward verification tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100% (since no parameters exist). According to the rubric, with 0 parameters the baseline is 4. The description does not need to add parameter information, and it correctly focuses on the tool's action and output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Verify' and specifies the resource ('HMAC signatures on all safety audit log entries'). It distinguishes the tool as a security-focused audit verification, which is unique among many sibling tools that are about printing, design, and management.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. Given the large list of siblings, including tools like 'safety_audit' and 'export_audit_trail', the description should clarify that this tool specifically checks integrity via HMAC, not general auditing or export. The absence of such guidance reduces its helpfulness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the tool's function and parameter details but does not disclose side effects, auth needs, or return behavior. The description is adequate but lacks full behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear parameter documentation in a bullet-like format. It is slightly verbose but each sentence adds value. No redundancy, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers parameter semantics but omits the return value or effect on the assembly state. With no output schema and 7 parameters, the missing return behavior is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides rich, detailed explanations for every parameter, including defaults, special cases (e.g., negative clearance for interference fit), and constraints (e.g., magnet polarity only meaningful for magnetic joints). This adds significant value beyond the schema's bare titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a mating interface between two parts in an assembly, specifying joint type and clearance. It distinguishes itself from sibling tools like 'add_assembly_part' by focusing on interfaces between parts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for validation and clearance checking but does not explicitly state when to use this tool vs. alternatives like 'compose_assembly_parts' or 'validate_assembly'. No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses that the tool 'parses parameters, modules, and library imports' to understand architecture, implying a read-only analysis. However, it does not explicitly state that it is non-destructive or mention any limitations or 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. The inclusion of an 'Args' section with parameter description is useful, though slightly redundant with the schema. Every sentence contributes valuable information with minimal fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should specify the return format or structure to inform the agent's next steps. It mentions understanding architecture but does not describe the output (e.g., list of modules, parameters, imports). This leaves the agent without sufficient guidance on how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds crucial meaning by stating 'OpenSCAD source code' for the 'scad_code' parameter. This clarifies what the string should contain beyond the bare type, though further detail like encoding or size limits is absent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Analyze the structure of OpenSCAD code' with a specific verb and resource. It details what is parsed (parameters, modules, library imports) to understand architecture, distinguishing it from sibling tools like 'compile_scad' or 'modify_scad_module'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises 'Use this before modifying code to know what modules exist and what each one does,' providing clear when-to-use context. It implicitly positions itself as a prerequisite for modification tools, though it does not mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains return format (risks list with locations) but does not disclose whether tool modifies the file, requires permissions, or has side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with bullet points for risk types and clear sections for returns and parameters. Slightly verbose but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (multiple risk types, three parameters, no output schema), description covers key aspects: risks, coordinate return, param details. Could mention output schema or severity scale, but still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% parameter descriptions, but description includes :param section explaining file_path, min_cross_section_mm2 (with default), and sharp_angle_threshold_deg (with default). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it analyzes STL mesh for structural weak points, listing specific risk types (thin_neck, stress_concentration, etc.) and contrasting with printability analysis. This distinguishes it from siblings like analyze_printability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for structural analysis beyond printability but does not explicitly state when to use this tool versus alternatives like assess_load_bearing or analyze_warping_risk. No exclusions or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors (evaluation, scoring, optional write) but lacks details on side effects (e.g., does writing a new STL overwrite the original? Permissions needed?). Without annotations, more explicit behavioral context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence followed by bullet-like parameter explanations. It is concise, with no redundant or irrelevant information. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main functionality and parameters, but lacks detail on return values (no output schema) and scoring criteria. For a tool with moderate complexity and no annotations, more completeness on output behavior would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It does so for all five: file_path, candidates, nozzle_diameter, apply, output_path, including defaults and conditional use. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose ('Find the optimal print orientation for a 3D model') and details how it works (evaluates rotations, scores based on adhesion, supports, etc.). It distinguishes itself from siblings like 'optimize_print_orientation' by specifying the evaluation criteria and optional file writing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when needing optimal orientation) but does not explicitly state when not to use or mention alternatives. Given sibling tools like 'optimize_print_orientation' and 'analyze_model_geometry', more explicit guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: file copying to '~/.kiln/model_cache/', metadata storage in a database, and duplicate detection via SHA-256. This goes beyond the schema, especially since no annotations are provided. It clearly indicates a write operation and explains the caching mechanism.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary followed by parameter details in an 'Args:' block. It is front-loaded with the purpose. A slight reduction in parameter detail (e.g., more compact format) could improve conciseness, but it is already efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, 2 required, no output schema, and zero schema description coverage, the description provides complete coverage: explains all parameters, gives examples, describes the caching process and duplicate detection. It is self-sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden. It provides detailed explanations for all 7 parameters, including examples for 'source' (enum-like list), 'tags' (comma-separated example), and 'dimensions' (JSON object with bounding box format). This adds significant meaning beyond the schema's type-only fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a 3D model to a local cache for reuse across jobs, with specific details about storage location and metadata. While the verb and resource are specific, it does not explicitly distinguish from sibling tools like 'cache_design' or 'get_cached_model', leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus alternatives like 'cache_design' or 'delete_cached_model'. There is no mention of prerequisites, when not to use, or when to prefer another tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by detailing parameters and providing examples, but it does not disclose side effects (e.g., whether SSO is immediately activated, whether existing config is overwritten) or return behavior. Essential behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear single-line summary and organized as an Args block. It is slightly lengthy but justified given the complexity of 7 parameters. Every sentence adds value, though could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers parameters well but omits return value information, prerequisites (e.g., admin role), and potential failure modes. The tool's complexity warrants more contextual depth.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries full burden. It adds significant meaning by explaining each parameter with examples, defaults, and optionality (e.g., client_secret optional for public clients, role_mapping JSON string). This greatly aids agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures SSO for enterprise authentication, specifying protocols (OIDC/SAML) and listing identity provider examples. It distinguishes well from unrelated sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (enterprise feature, setting up SSO) but does not explicitly state when to use this tool over related siblings like sso_status, sso_login_url, or sso_exchange_code. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the algorithm (overhang analysis) but omits details like error handling, file size limits, or permission requirements. The behavior is adequately outlined but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and follows with a concise algorithm explanation. The docstring format (param/returns) adds minor verbosity but remains efficient. Nearly every sentence adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter and no output schema, the description defines the return dict (volume, weight, overhang stats) and explains the estimation process. It is fairly complete for a simple tool, though it could mention prerequisites like manifold geometry.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'file_path' has no description in the schema (0% coverage), but the description adds critical context: accepted file formats (.stl, .obj, .glb). This compensates for the schema gap, adding meaningful semantics beyond the raw type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates support material for a mesh, with a specific verb ('estimate') and resource ('support material'). It distinguishes from siblings by detailing the algorithm (analyze overhang triangles, project to build plate).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for support material estimation from mesh files but lacks explicit guidance on when to use this versus alternatives like 'estimate_supports' or 'estimate_mesh_weight'. No when-not-to-use or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as authentication requirements, rate limits, or side effects. It implies a safe read operation by estimating a timeline, but without explicit statements, the agent has limited behavioral insight. The description itself is straightforward and does not contradict any annotations (none present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (few sentences), front-loads the purpose, then lists parameters with explanations, and ends with return structure. No redundant or vague statements; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the input parameters and return value (stage-by-stage timeline with estimated days). It does not address error handling or prerequisites (e.g., requiring a quote for shipping_days). However, given the tool's simplicity and lack of output schema, it provides sufficient context for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the tool description fully documents each parameter's meaning (e.g., technology lists enum values, shipping_days optional, quantity adds production time, country for fallback). This adds significant value beyond the bare schema, enabling correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Estimate order-to-delivery timeline with per-stage breakdown.' It specifies the verb and resource, but does not explicitly distinguish from sibling tools like estimate_print_time or estimate_cost. While the focus on order-to-delivery with stages is unique, it could be more explicit about its differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for parameters (technology, shipping_days, quantity, country) but does not explicitly state when to use this tool versus alternatives like estimate_print_time. It lacks when-not conditions or specific prerequisites, leaving the agent to infer usage from parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the experimental nature, that printing does not start, and general safety concerns. However, it lacks details on validation failure handling, preview format, upload implications, and prerequisites like printer lock, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with a clear two-paragraph structure: first paragraph explains purpose and warnings, second lists parameters. It could be slightly more streamlined, but it earns its sentences without excessive verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, no output schema, many sibling tools), the description covers the main workflow and cautions but omits return values, preview mechanism, and prerequisites like printer lock. This leaves gaps for an agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining each parameter: prompt (text), provider (with example values), style (optional hint), printer_name (default omitted), profile (slicer path), printer_id (with example), and timeout (default 600). Some parameters like style lack detail, but overall adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a full pipeline: generate, validate, slice, and upload to preview. It distinguishes from start_print and implies it is a combined operation, but doesn't explicitly differentiate from other pipeline tools like validate_and_prepare or slice_and_print.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call start_print separately after reviewing preview results, warns against printing AI-generated models, and recommends downloading from marketplaces as an alternative. This provides clear guidance on when to use the tool and when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains that omitting the goal returns a compact overview, while providing it returns a complete guide. It also lists example values for goal. No contradictions; behavior is well described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It uses a clear header, describes the two modes, and then breaks down arguments with examples. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description covers the essential behavior: what happens with and without the optional parameter. It could mention that this is public help (not authenticated), but overall it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by providing examples for material and possible values for goal. It clarifies that goal is optional and lists specific values like 'surface_finish', 'paint', 'strengthen'. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves post-processing help for a given material and optional goal. The verb 'Get' and resource 'post-processing help' are specific. However, it does not explicitly distinguish from sibling tools like troubleshoot_print_issue, but given the context of post-processing vs troubleshooting, it's clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two modes (with or without goal) and what each returns, which helps in deciding how to use it. However, it does not compare to alternatives or state 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It describes scanning for triggers and returning results, but does not disclose side effects, authorization needs, or rate limits. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and includes a helpful example. It is well-structured without wasted words, though minor reduction could make it even terser.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter and no output schema. The description mentions returning 'matched constraint sets with rules and guidance' but does not detail the structure of the output. This is adequate for a simple tool but leaves some ambiguity about the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter 'description' with 0% schema description coverage. The tool description compensates by explaining the parameter's meaning: 'What the object needs to do' and provides an example ('outdoor hook that holds a heavy hanging planter'). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying functional requirements from a natural language description of a design task. It lists specific requirement triggers and indicates the output is matched constraint sets with rules and guidance. This distinguishes it from siblings like 'analyze_design_requirements' by focusing on scanning language for triggers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this to understand WHAT constraints apply before getting the full design brief,' implying it is a preliminary step. However, it does not explicitly state when not to use it or mention alternatives, leaving room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the optimization criteria (minimize spool swaps, prefer color matches) and that the tool returns assignments (not executing them). However, it does not clarify if the tool modifies any state, requires printer locks, or handles edge cases like insufficient materials.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single-line summary followed by a bullet-point parameter explanation. Every sentence adds value with no repetition. It is front-loaded with the core purpose, making it easy for the agent to quickly understand the tool's role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the input format and optimization objective. However, it fails to describe the return structure explicitly (e.g., type of assignments, mapping of jobs to printers), which is needed for the agent to parse the output correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with a generic array of objects. The description adds critical meaning by specifying the expected job dict fields (file_name, material_type, required_grams, optional color) and their purpose. This compensates well for the schema's lack of detail, though it could further explain constraints on the job list (e.g., maximum size).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Assign print jobs to printers by material availability.' It specifies what the tool does (optimize assignments) and the resource (print jobs and printers), distinguishing it from siblings like 'route_print_job' which likely focuses on routing individual jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a list of print jobs to assign optimally based on material availability and color preferences. However, it does not provide explicit guidance on when not to use this tool or mention alternatives such as 'route_print_job' for single-job assignment, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It fails to disclose behavioral traits such as whether the tool is read-only, requires authentication, or has rate limits. The description only states what is shown, not how it behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using only two short paragraphs and one sentence for the core purpose. Every sentence adds value: the first states what is shown, the second provides enterprise context and pricing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is adequate for a simple summary tool, it lacks details like the time period covered (current month? all time?), data recency, and whether it includes historical data. Given no output schema, the description could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description must convey all meaning. It does so by describing the output (printer count, allowance, overage charges) and pricing details. Schema coverage is 100%, but the description adds necessary context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show printer count, included allowance, and overage charges.' This specifies the action (show) and the resource (printer usage summary), making the purpose unambiguous and distinct from sibling tools like troubleshoot_print_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Enterprise feature,' which provides context on when this tool is applicable (enterprise users). It does not explicitly state when not to use or list alternatives, but the context helps narrow usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains basic behavior (unlock) and parameter constraint (holder must match acquire), but does not disclose side effects, error handling, or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise; one-line purpose followed by parameter descriptions. No fluff, all sentences are informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, so description should cover return values, error states, and idempotency. It provides basic functionality but lacks edge case details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond schema: explains each parameter's purpose and notes that holder must match the acquire call. Schema has 0% description coverage, so this adds necessary context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Release an exclusive lock on a printer', using specific verb and resource. Additionally, it distinguishes from the sibling tool 'acquire_printer_lock' by its opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Context implies usage after acquiring the lock, but no explicit guidance on when to use or when not, nor mention of alternatives beyond the sibling tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It indicates the tool 'shows' and 'displays' settings, implying read-only operation, but does not explicitly state it has no side effects or required permissions. The lack of behavioral details is a gap, though the tool is simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core purpose, followed by brief details and a usage recommendation. Every sentence serves a clear role without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a straightforward purpose, the description is reasonably complete. It explains what the tool shows and when to use it. However, it could mention the return format or that it is safe to call, which would slightly enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so no parameter semantics are needed. The description adds no parameter information, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Show current safety and auto-print settings' and specifies what it displays (auto-print status for marketplace and AI models). However, it does not differentiate from sibling tools like 'safety_status' which may also show safety settings. A more explicit distinction would improve clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description suggests 'Call this early in a session to understand what safety protections are active,' which implies when to use it. However, no when-not-to-use guidance or alternative tools are mentioned. Given the large set of sibling tools, explicit exclusions would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the fuzzy matching behavior, fields searched, and return format. Since annotations are absent, it adequately covers the main behavioral aspects, but does not explicitly state that it is read-only or mention error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It front-loads the core purpose, then details matching behavior, return format, and parameter descriptions in a clear, efficient manner without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the matching mechanism, parameters, and return format, which is nearly complete for a search tool. However, it does not mention edge cases (e.g., empty results) or explicitly state the read-only nature, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: query as a natural-language string, max_results as a default of 10, and category_filter as an optional filter. It provides examples and clarifies the return structure, adding significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the template library using natural-language descriptions and fuzzy matching. It distinguishes from sibling tools like 'list_design_templates' by focusing on search and scoring, but does not explicitly contrast with 'find_design_templates', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as 'find_design_templates' or 'list_design_templates_catalog'. The description only explains the search mechanism, not the context of usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that the tool sends a G-code command, which is a key behavioral trait. However, it omits details such as whether the operation is synchronous, whether it requires the printer to be idle, or what the response/return value indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with three sentences covering purpose, behavior, and parameters without redundancy. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description adequately covers basic usage. However, it lacks details on return values, side effects (e.g., printer movement), or prerequisites (e.g., printer homing), which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds meaningful information for the only parameter ('printer_name: Target printer. Omit for the default printer.'), compensating for the schema gap and providing clear semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers a bed leveling/mesh probe and specifies the G-code commands (G29 or BED_MESH_CALIBRATE), distinguishing it from related sibling tools like bed_level_status (which reports status) and set_leveling_policy (which configures settings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (triggering leveling) but does not explicitly advise against using alternatives like bed_level_status or set_leveling_policy. It implies usage for performing the action but lacks explicit when-not or exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It describes the algorithm and output but does not state side effects (e.g., file modifications, permissions required). The tool appears to be a read-only arrangement, but this is not explicitly confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, algorithm explanation, and parameter list. It is informative but slightly verbose; however, the detail is justified given the lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all parameters, algorithm, and output keys. It lacks explanations of error handling (e.g., missing files) and prerequisites, but overall it provides sufficient context for a tool with no output schema and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 provides detailed parameter descriptions in a docstring format, including defaults, examples, and expected formats (e.g., JSON arrays for file_paths, dict for copies). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Pack multiple STL files onto a virtual build plate.' It specifies the verb 'pack' and the resource 'STL files onto a build plate,' distinguishing it from sibling tools like 'auto_arrange_parts_on_plate' by emphasizing configurable parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the algorithm and what the tool reports but does not explicitly state when to use this tool versus alternatives like 'auto_arrange_parts_on_plate.' It lacks guidance on context or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it details precision cutting of crossing faces, capping behavior, per-zone closed-solid output, generation of STL/3MF files, zero cloud dependencies, and the inline 3D stage including automatic decimation of oversized meshes and browser fallback. This is exemplary behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description opens with a strong one-line summary followed by tightly organized behavioral details and a clearly labeled 'INLINE 3D STAGE' callout. It's longer than typical but every sentence contributes distinct information; slight wordiness in the inline-stage section keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there's no output schema and no annotations, the description goes far: it documents parameters, return structure, file formats, and interactive viewer behavior. It's complete for the tool's complexity, though the return dict's edge cases (e.g., what happens with fewer colors than requested) are left speculative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate — and it does via reST-style parameter docs: binary STL for input_path, default 4 for num_colors, and hex list defaults for color_palette, plus returns documentation. Loses a point for not noting valid ranges, format validation, or error behavior, but it adequately makes up for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Split[s] a 3D model into horizontal color zones by Z-height' — a specific verb+resource+scope. It's readily distinguishable from siblings like auto_color_by_region conceptually, but it doesn't explicitly reference or contrast with that sibling, so it doesn't fully earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied through the description of Z-height banding and the 3MF output for AMS/MMU printers, suggesting when this tool is appropriate. However, there is no explicit 'use this instead of X' guidance, no exclusions, and no mention of when to choose a region-based or alternative coloring tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly indicates a non-destructive read operation, but does not disclose any side effects, permissions, or behavioral details beyond the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two short sentences and a brief args section. Every word adds value, with no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check with one optional parameter and no output schema, the description is adequate. It explains what the tool does and the single parameter. However, it could mention the return format or status indicators.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to the single parameter 'printer_name' beyond the schema (which only provides type and default). It clarifies the purpose and default behavior, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Check' and clearly states the resource 'bed leveling status' and what it determines ('whether leveling is needed'). It effectively distinguishes from sibling 'trigger_bed_level' which performs a different action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking leveling status but provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, limitations, or 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does a solid job: it discloses the transformation applied, the output_path default of overwriting the input, the return value, and the inline 3D stage side effect. It falls short only of explaining failure/edge-case behavior such as what happens for meshes larger than the bed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear summary, followed by structured parameter documentation and a useful inline-stage note. The only minor redundancy is that the second sentence restates the first, but overall every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity, lack of annotations, and absence of an output schema, the description is largely complete: it covers purpose, all parameters, defaults, return value, and a notable side effect. It could be more complete by describing conflict behavior between printer_id and explicit bed dimensions, but it is sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the tool description documents every parameter with meaning: file_path is the STL file, bed_x_mm and bed_y_mm are build plate dimensions with defaults, printer_id optionally supplies bed size via printer intelligence, and output_path defaults to overwriting the input. This fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Center a mesh on the build plate and place at z=0.' It clearly defines the operation and its effect, distinguishing it from sibling tools like rotate_model or auto_orient_model by focusing on horizontal centering and z=0 placement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives such as auto_orient_model, rescale_model, or rotate_model. The description implies its use case through its purpose, but it does not state when-not-to-use it or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description discloses behavior such as the record vs. sensor distinction, the three possible match values, and guidance on the 'sensed' field.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose with the explanatory paragraph about record and three answers, but remains structured and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains the output semantics (match true/false/null, sensed) giving sufficient context for a check tool, though no explicit output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning to both parameters: expected_material is the print file requirement, printer_name is the target printer with omission resolving to the active printer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks whether the recorded material matches the print's expected material, distinguishing from sibling tools by focusing on the record vs. sensor distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to act (e.g., stop on false match, check spool on null) but does not explicitly compare with alternative tools like get_material or set_material.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of transparency. It discloses that insufficient material triggers suggestions, but does not clarify if the check is read-only, the output format, or edge cases. Moderate transparency, but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then behavior details, then parameter list. It avoids unnecessary fluff but could integrate the tier limitation more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers core functionality and suggestions, but lacks details on output format, edge cases, and behavior when material is sufficient. More context needed 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema has 0% description coverage, the description compensates by listing each parameter with a brief explanation. This adds meaning beyond types and required status, though more detail on formats or allowed values would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if a printer has enough material for a print job, with a specific verb and resource. It distinguishes itself from siblings by emphasizing that this check is for a single printer and works on every tier, while fleet-wide suggestions require a different tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool (checking a specific printer's sufficiency) and notes that fleet-wide suggestions need Kiln Business. However, it does not explicitly name alternative tools for fleet-wide checks, leaving some guidance gaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It describes the state transition but does not mention side effects, permissions required, or whether the action is reversible. More transparency about what happens after confirmation would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The main purpose is stated in the first line, followed by a brief explanation and a properly formatted Args section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the essential aspects: what it does, when to use it, and what input is needed. It could be more complete by noting idempotency or failure cases, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning to the single parameter 'session_id' by stating 'The session_id to confirm.' With schema description coverage at 0%, the description provides some context but lacks richer details like format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and resource: 'Confirm that a recovery plan should proceed.' It specifies the state transition from 'awaiting_confirmation' to 'executing', which distinguishes it from sibling tools like 'cancel_print_recovery' and 'complete_print_recovery'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the context: 'For plans requiring human confirmation, transitions from awaiting_confirmation to executing.' This implies when to use the tool, but does not explicitly mention when not to use it or provide direct alternatives. However, given sibling tool names, the usage is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It describes a retrieval operation (returns a guide) with no mention of side effects, state changes, or prerequisites. While the behavior is implied to be safe and non-destructive, the description lacks explicit disclosure about authentication requirements or potential impacts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with three well-structured sentences. The first sentence immediately conveys the primary purpose, the second lists key contents, and the third provides context. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequately covers the returned guide's scope. However, it omits any mention of prerequisites (e.g., user account) or post-action expectations, leaving minor gaps for a first-time user.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description does not need to add parameter information, but it also does not add any extra semantic context beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: 'Get the guided onboarding workflow for users without a 3D printer,' specifying the target audience and the content of the guide (model discovery, material recommendations, etc.). This distinguishes it from siblings like 'get_started' or other onboarding tools by focusing on users without a 3D printer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is 'Perfect for first-time users who want to manufacture a custom part,' providing clear use context. However, it does not explicitly state when not to use it or mention alternative tools, leaving some ambiguity about scenarios where other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that results are sorted by remaining stock and that optional filters exist, but does not address edge cases (e.g., no matching printers) or error conditions. Adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a one-sentence summary followed by a clear parameter list. Every sentence adds value, no fluff. Well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the output ordering and filtering but does not specify the exact return format (e.g., printer IDs, names). Without an output schema, this missing detail reduces completeness for an agent that needs to parse results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds complete parameter documentation, including example values ('PLA'), optional filters (color), and default behavior (min_grams default 0). Since the schema lacks descriptions, this fully compensates and adds significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds printers with a specific material loaded, using a specific verb and resource. It distinguishes from siblings like 'find_material_match' and 'list_trusted_printers' by focusing on printer availability by material.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to find printers with a material) but provides no explicit guidance on when to use this tool versus alternatives like 'discover_printers' or 'printer_status'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions results order (newest to oldest) and included fields (actions, rules, reasons), but does not specify what 'recent' means, whether the operation is read-only, or any prerequisites or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loads the main purpose, and uses a clear structure with separate arg descriptions. Every sentence is informative with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (handling return values), the description covers input semantics, ordering, and included fields. It lacks mention of error cases or session existence requirements, but is otherwise sufficient for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains both parameters: 'session_id' as target session ID, and 'limit' with default and max values. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent interception results for a session,' using a specific verb and identifying the resource. It distinguishes from siblings like 'get_interception_status' and 'list_interception_sessions.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing recent interception results for a session, but does not explicitly state when not to use it or mention alternative tools. Usage is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description does not explicitly state read-only nature or other behavioral traits like rate limits. For a simple getter, the return description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line for purpose, one line for return summary, and a clean Args section. Front-loaded with purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides a good overview. It could mention error handling or response format, but is mostly complete for a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by clearly explaining the parameter material_id with examples ('hatchbox_pla', 'esun_petg'), adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed information for a specific material by ID' with a specific verb and resource. It lists return fields, distinguishing it from sibling list tools like list_materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied but not explicit. No mention of when to use this tool versus alternatives such as get_material_properties or search_material_catalog. No exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral aspects. It states it returns data, implying a read-only operation, but does not mention safety, authentication, rate limits, or any side effects. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose statement upfront, followed by a well-structured parameter list. Every sentence adds value, and there is no redundant or vague language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with 2 parameters and no output schema, the description covers the key aspects: what it does, input parameters, and returned values. It could specify the exact output format (e.g., JSON keys) for completeness, but the provided information is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds essential meaning: it lists possible values for 'material' (PLA, PETG, etc.) and explains 'nozzle_diameter_mm' affects layer height limits with a default value. This goes beyond the schema's bare structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'material-specific slicing constraints for adaptive slicing' and lists the returned parameters (layer height limits, bridge/overhang parameters, fan speeds). This distinguishes it from siblings like 'get_material_properties' or 'get_slicer_profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose but does not provide guidance on when to use it versus other similar tools, such as 'get_material_properties' or 'get_slicer_profile'. No exclusions or alternatives are mentioned, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It explains the behavior regarding unresolved prints: they are jobs that ended while no Kiln process was watching and require user input. It warns against guessing outcomes and states that insights are advisory, not overriding safety limits. This adds significant behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear opening sentence, bullet points for the agent contract, and a note section. It is front-loaded with the core purpose and avoids unnecessary repetition. Every sentence adds value, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool returning multiple data types, the description covers success rates, failure modes, per-material stats, and unresolved prints. It explains the unresolved print concept in detail. Without an output schema, it does not specify the return format, but the listed categories provide sufficient operational context. The limit parameter is addressed. Slight gap: no mention of pagination or how 'limit' interacts with statistics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by naming both parameters. 'printer_name' is described as 'The printer to get insights for' and 'limit' as 'Maximum recent outcomes to include (default 20).' While this clarifies purpose, it adds minimal detail beyond the parameter names. The description could elaborate on how 'limit' affects the returned data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Query' and the resource 'cross-printer learning insights for a specific printer.' It details the return types: success rates, failure mode breakdown, per-material statistics, and unresolved prints. This distinguishes it from sibling tools like 'troubleshoot_print_issue' which focus on troubleshooting specific issues.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an 'Agent contract' for handling unresolved prints and notes that insights are advisory. However, it does not explicitly state when to use this tool versus alternatives like 'get_print_diagnostic' or 'monitor_print.' Usage is implied but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states it returns aggregate statistics with no side effects, implying a read-only operation. However, it does not explicitly confirm that it is safe, idempotent, or requires no special permissions. Adding a note about being non-destructive would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first defines the core purpose, the second adds relevant detail about what is returned. No unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequately explains what the tool returns (success rates, failure distribution, active session counts). It is slightly vague on the time range ('historical') but sufficient for a statistics endpoint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema covers 100%. The description doesn't need to add parameter semantics. The baseline for zero parameters is 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'historical recovery success rates and failure distribution'. It distinguishes from sibling recovery tools like 'get_recovery_plan' and 'get_recovery_session_status' by focusing on aggregate statistics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving recovery statistics but lacks explicit guidance on when to use this tool versus alternatives. For example, it doesn't clarify when to use this instead of 'get_recovery_session_status' or 'recovery_history'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It describes the insertion action and the two possible positions (start/end), but does not mention potential side effects, error handling (e.g., if the module does not exist), or return behavior. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by a usage paragraph and parameter list. Every sentence contributes value, and the format is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 input parameters, no output schema, and no annotations, the description covers inputs well but omits the return value or post-conditions. The user might need to know whether the modified code is returned or the effect is in-place. This gap reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, yet the description explains each parameter in detail: scad_code (source code), module_name (module to modify), code_to_insert (code to insert), and position (start/end with default). This fully compensates for the lack of schema descriptions, adding significant meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Insert code into an OpenSCAD module without replacing it', providing a specific verb and resource. However, it does not explicitly differentiate from sibling tools like 'modify_scad_module' or 'update_scad_parameter', which are semantically close. Still, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete usage examples ('add ventilation holes', 'add screw holes') and explains that it inserts geometry inside a module. Although it does not explicitly state when not to use this tool or name alternatives, the context is sufficiently clear for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is read-only and only returns metadata, which is a positive behavioral trait. However, it omits potential details like authentication requirements or whether the list is user-specific or global.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose and a key constraint (no plaintext).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, no annotations), the description is mostly complete. It covers what the tool does and what it returns. Minor gaps like pagination or sorting are not critical for a list-all operation, but could be mentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema description coverage is 100%. According to the scale, baseline is 4 for no parameters. The description does not need to add parameter semantics, and it correctly omits any param references.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' with the resource 'stored credentials' and adds a clear qualifier 'metadata only, no plaintext', which precisely defines the scope. This implicitly distinguishes it from sibling tools like 'retrieve_credential' that likely return full credentials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as 'retrieve_credential' or 'store_credential'. It only hints at the distinction through 'metadata only', but lacks direct instructions or examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It mentions returning summary information (printer name, command counts, rule counts) but does not discuss side effects, permissions, or behavior when no active sessions exist. It is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main purpose. No unnecessary information; every sentence contributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters and an output schema, the description is largely complete. It covers purpose and return content. It could mention that only active sessions are listed, which is already stated. Minor gap: no mention of read-only nature, but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds value by describing the return fields (printer name, command counts, rule counts), which helps the agent understand the output beyond what the output schema might provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all active G-code interception sessions', using a specific verb and resource. It distinguishes from sibling tools like get_interception_status or start_gcode_interception by focusing on listing all active sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly indicate when to use this tool versus alternatives such as get_interception_status or get_interception_history. Usage is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explains the read-only nature and output, but does not disclose any potential side effects, authentication needs, or rate limits. However, for a simple listing tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and contains no unnecessary words. It is highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is sufficiently complete. It covers what the tool does and what it returns. It could mention if the list is exhaustive or limited to certain materials, but this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so the description is not required to explain parameters. It adds value by detailing what information is returned, which compensates for the lack of schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists materials with adaptive slicing profiles and specifies the return values (material names and key slicing constraints). This distinguishes it from sibling tools like 'list_materials' which likely list all materials.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing materials with adaptive slicing profiles, but does not explicitly state when to avoid this tool or mention alternatives. Sibling tools exist for general material listing, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries full burden. It discloses that the tool returns endpoint details (URL, subscribed events, delivery statistics), which is sufficient for a read-only list operation. No side effects or safety issues are mentioned, but they are not expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no redundant words, and the main action is front-loaded. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description adequately explains what is returned. It is complete given the simplicity of the tool. No additional context is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters and 100% coverage. The description adds no parameter information because none exist. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'List all registered webhook endpoints,' using a specific verb ('List') and resource ('webhook endpoints'). It distinguishes itself from sibling tools like 'register_webhook' and 'delete_webhook' by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to view existing webhooks, but it does not provide explicit guidance on when to use it versus alternatives or any prerequisites. It lacks 'when not to use' or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return content and the parameter but does not discuss side effects, error handling, or any constraints. Since no annotations are provided, it carries the full burden, and while adequate, it lacks details like what happens if the execution_id is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences plus one bullet, front-loaded with the core purpose, and contains no redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple status check tool with one parameter, the description covers purpose, return values, and parameter guidance. It could mention that the pipeline must be running, but overall it is fairly complete and commensurate with the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter 'execution_id' by explaining its source (returned when starting a pipeline). Since schema description coverage is 0%, this is valuable and compensates for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current state of a pipeline execution, specifies the return values (execution state, completed steps, next step), and distinguishes it from siblings like pipeline_abort, pipeline_pause, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used after starting a pipeline to check status, but it does not provide explicit guidance on when to use it versus other pipeline tools, nor does it mention any prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states data stays local (privacy) and lists return types, but does not disclose prerequisites (e.g., printer existence), side effects, or error handling. It is not contradictory but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence for purpose, a privacy note, and a bulleted list of outputs, followed by parameter explanations. Every sentence adds value, and it is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 2 parameters and no output schema, the description covers the core functionality, privacy, and output types. It does not explain error cases or return format, but given the tool's simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 printer_name as the printer to analyze and lookback_days as how far back to look with a default of 30 days, adding valuable meaning beyond the schema's title and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it analyzes local print history trends for a specific printer, listing specific outputs like health score and failure rate trends. It distinguishes itself from siblings by focusing on trends over time and local data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it uses local database data only, implying it's for local analysis, but does not explicitly state when to use this tool versus alternatives like analyze_print_failure or predict_print_failure. No exclusion criteria or use cases are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral traits. It fails to disclose destructive nature, required permissions, side effects, or error conditions of a firmware rollback operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and includes a structured Args section with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (firmware rollback, multi-printer context) and no output schema, the description is reasonably complete but could detail post-rollback behavior or safety aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists parameters with brief descriptions ('Printer to rollback', 'Specific version to rollback to'), adding basic meaning but lacking format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rolls back firmware on a specific printer by name, with fleet-level and version pinning support. It distinguishes from the sibling 'rollback_firmware' tool for single-printer setups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to use this tool in multi-printer setups and directs to an alternative (rollback_firmware) for single-printer setups, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description includes useful behavioral details beyond the schema, such as the connected-component analysis mechanism, default output location, and the return value structure (dict with count and file paths). It also transparently notes the 3D stage integration and fallback behavior for hosts without MCP Apps panel support. However, it does not mention side effects like file overwriting or cleanup of the original file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat front-loaded with the main action in the first sentencevie, but then provides technical details (connected-component analysis, 3D stage) that may be less critical for an agent. The inline parameter documentation is helpful but could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the function, parameters, return value, and a dependency (3D stage support). It is generally complete for a file-splitting utility. It could mention error cases (e.g., file without multiple components) or edge cases (non-STL formats), but overall gives an agent enough to proceed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains 'file_path' as the path to the mesh file, but does not mention supported formats (e.g., .stl, .obj) or file size limits. 'output_dir' is explained with a default behavior ('input directory'). Schema coverage is 0% so these explanations are valuable, but parameter details beyond 'output directory' are thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Split') and clearly identifies the resource ('a multi-component mesh') and the outcome ('into separate STL files'). It also explains the mechanism ('identifies disconnected bodies via connected-component analysis'), which provides clear functional understanding and differentiates it from vague sibling tools like 'merge_stl' or 'arrange_parts_on_plate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives. There is no mention of alternatives like 'merge_stl' or 'extract_plate_object'. The context is implied (when you need separate files per component) but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only says 'look up', implying a read operation, but does not explicitly state it is read-only, nor mention authentication, rate limits, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose followed by a formatted Args section. Every sentence is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers purpose, parameter usage, and a sibling tool hint. It does not describe the return format or error handling, but for a basic lookup the agent can infer the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no description for the parameter, but the description provides example codes (e.g., 'US-CA', 'DE') and a hint to use 'tax_jurisdictions' to browse codes. This adds significant contextual meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Look up tax details for a specific region (rate, type, B2B exemptions)', which is a specific verb and resource. It distinguishes itself from siblings like 'tax_jurisdictions' (browse codes) and 'tax_estimate' (estimate tax).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description instructs to use 'tax_jurisdictions' to browse all codes, providing clear context for obtaining the parameter. It implies the tool is for looking up details after obtaining a code, though it doesn't explicitly state 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Get rolling uptime statistics') but does not explicitly state that it has no side effects or what permissions are required. The absence of behavioral disclosure is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the purpose, the second lists the included metrics. No extraneous words, exactly as it should be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately covers return values by listing uptime percentages, response times, and SLA status. However, it does not specify data units or refresh frequency, leaving minor gaps for a tool with no parameters and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (0 params, 100% schema coverage). The description does not need to add parameter detail, and it correctly omits such information, achieving the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving rolling uptime statistics and SLA status. It specifies the exact metrics provided (uptime percentages for 1h, 24h, 7d, 30d windows, average response times, SLA target status), making it distinct from other reporting tools like cost or printer usage reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is an 'Enterprise feature,' providing some usage context. While it does not explicitly state when to use versus alternatives, the purpose is narrow and self-explanatory, so an agent can infer when to invoke it for uptime and SLA queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool performs checks and returns pass/fail with suggestions, but it does not mention whether it is read-only, authentication needs, or response format details. It partially covers behavioral traits but lacks completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with each sentence adding value. However, it lacks a structured front-loaded summary; it is presented as a single paragraph with line breaks. Still, no redundant information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core functionality, usage context, and next steps. However, it omits details on return format (e.g., list of checks, pass/fail structure), error handling, and what happens with invalid inputs. Without an output schema, these gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining file_path (STL/OBJ), requirements (same as another tool), and material (optional with example). This adds significant value beyond the schema's bare titles, though it omits validation rules or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates a 3D model against functional design requirements, specifying it checks structural, dimensional, and manufacturability constraints. It distinguishes itself from sibling tools like analyze_design_requirements and analyze_mesh_geometry by focusing on post-generation validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Call this AFTER generating a model and BEFORE printing it' and provides guidance to use fix suggestions for regeneration. However, it does not mention when not to use it or contrast with other validation tools like validate_gcode or validate_mesh.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the action but does not discuss side effects, required permissions, or what happens on conflict (e.g., duplicate name). The message field indicates when the rule fires, but other behavioral aspects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence summary followed by a bullet-like list of arguments. Every line adds value, with no redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no schema descriptions, the description explains each parameter adequately. However, it does not indicate which parameters are required (the schema lists 4 required), nor does it mention defaults like priority=medium. The output schema is present but not referenced. A small gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must fully compensate. It does so by listing all 11 parameters with clear meanings, enumerating valid values for trigger, action, and priority, and providing examples (modify_params). This adds critical semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a custom interception rule to an active session,' specifying the verb (add), resource (interception rule), and context (active session). This distinguishes it from related tools like remove_interception_rule or list_interception_sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites. It implies usage through its purpose but lacks direct guidance on deciding when adding a rule is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description discloses it auto-generates and combines data to produce a JSON dict. It does not mention side effects, error handling, or permissions. The behavior is mostly implied but lacks deep transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, details, and an example. It is relatively concise but the code block adds length; however, it adds value for understanding the workflow.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description explains input, output purpose, and usage in a workflow. It covers the essential context but omits error handling and edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description adds meaning by explaining material_id as the target material and printer_id as an optional printer model. It provides examples and clarifies behavior when omitted, though it doesn't specify allowed values or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool auto-generates a slicer override dict for a specific material, combining material thermal data with printer-specific tuning. It distinguishes itself from siblings as the key tool for material switching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit example workflow and states it is the key tool for material switching, giving clear when-to-use guidance. However, it does not explicitly mention when not to use or contrast with alternatives like get_material_slicing_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the tool returns a decision based on inputs, but does not explicitly state whether it is read-only, modifies state, or requires specific permissions. The behavioral detail is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence states purpose, second provides usage guidance and parameter overview. No redundant information, front-loaded with key action. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the output format (e.g., boolean, string) and valid values for 'safety_level'. Without an output schema, the agent needs to infer what 'decision' means. For a check tool, this is a gap that reduces full autonomy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds meaning by grouping parameters: required 'tool_name' and 'safety_level', plus optional context (material, time, temperatures). It clarifies the purpose of each parameter group but does not specify valid values for 'safety_level' (e.g., enum).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and resource 'autonomy' (whether the agent may execute a tool without human confirmation). It distinguishes from the sibling 'get_autonomy_level' by specifying use context: 'Use this before calling confirm-level tools to decide whether to proceed or ask.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: 'Use this before calling confirm-level tools to decide whether to proceed or ask.' It does not provide exclusions or alternatives, but the context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the 'Requires Enterprise license' constraint but does not explicitly state that the tool is read-only (implied by 'Get') or describe any side effects. The description adds some useful context but misses opportunities to fully disclose behavior beyond the license requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences that first state the purpose, then add detail about aggregation and use case, and finally describe the parameter and license requirement. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no output schema, and no annotations. The description adequately explains the input but does not describe the output format or content of the cost report. Given the lack of additional structured data, the description should provide more detail about what the report contains to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter ('client') with no description. The description adds meaning by noting it can be a 'Client or cost-center identifier,' which provides an alternative interpretation. Schema description coverage is 0%, so the description adds significant value, though it could be more detailed (e.g., format or usage examples).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a cost report for all projects belonging to a client.' It uses a specific verb ('Get') and resource ('cost report'), and distinguishes itself from siblings by focusing on client-level aggregation, which is unique among the many cost-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the tool: 'useful for invoicing and chargeback.' While it does not explicitly exclude alternatives or mention when not to use it, the context is clear and helps the agent infer appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the tool is read-only, destructive, requires specific permissions, or has rate limits. The phrase 'fixed public safety/process field set' hints at non-destructive behavior, but it is not explicit. The description fails to fill the transparency gap left by missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a single paragraph for purpose and usage, plus a compact list for parameters. Every sentence adds value without redundancy. The structure is front-loaded with the main action, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two string parameters and no output schema, the description covers the core purpose and usage. However, it does not describe the return value format or any additional behavior (e.g., does it return a score, recommendation, or side-by-side comparison?). This lack of return-value information reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by providing example values for each parameter ('material_a: First material (e.g. "pla")' and similarly for material_b). This adds meaningful context beyond the schema's titles. However, it does not specify allowed values or constraints (e.g., a list of valid materials), leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Compare two materials using a fixed public safety/process field set.' It provides concrete examples (PLA vs PETG) and distinguishes itself from other comparison tools by mentioning the 'fixed' field set and directing deeper questions to kiln-pro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('when deciding between materials... or when switching materials for a reprint') and when not to ('Deeper engineering trade-offs are answered one question at a time by kiln-pro'). This provides clear guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses important behavioral side effects: on success it opens Kiln's interactive 3D stage, oversized meshes are decimated automatically for the stage, and the PNG preview is only a starting point. It does not mention overwrite behavior or failure modes, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose sentence, followed by behavior, Args, and a labeled INLINE 3D STAGE section. The stage explanation is a bit verbose, especially the parenthetical host-specific details, but each sentence contributes useful operational context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the operation, both parameters, the output file, the viewer side effect, and automatic mesh decimation. It omits overwrite semantics and error conditions, but an agent has enough context to invoke the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the Args block adds meaningful semantics: assembly_json is 'a JSON string of the current assembly state' and output_path is 'where the composed STL will be written.' It does not detail the internal structure of assembly_json, but it compensates reasonably for a two-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific statement, 'Compose all assembly parts into a single output STL file,' and elaborates with 'Merges the individual part meshes according to their positions and writes the combined model to output_path.' This clearly identifies the verb, resource, and output, and distinguishes it from sibling merge/compose tools by targeting all assembly parts into one STL.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit when-to-use or when-not-to-use guidance, nor are alternatives named. The phrase 'current assembly state' and the merging behavior imply it is meant for turning an assembled model into a combined STL, but the description does not contrast it with similar sibling tools like compose_models or merge_stl.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool slices the mesh and returns contour polygons and area, implying it is read-only. No annotations are provided, so the description carries the burden, but it lacks details on computational cost, limitations, or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a single-sentence summary, followed by a detailed explanation and parameter list. It is concise without being overly brief, though it could be slightly more terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no schema descriptions, no output schema, and no annotations, the description is fairly complete. It explains all parameters and return values, though additional examples or error handling notes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema, explaining each parameter: file_path (path to STL file), plane (axis perpendicular to cut), offset_ratio (fractional position 0.0-1.0), and offset_mm (absolute position in mm, overriding offset_ratio). Schema description coverage was 0%, so this compensation is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes a 2D cross-section of a mesh at a cutting plane, using specific verbs and resources. It distinguishes itself from sibling tools like analyze_mesh_geometry or repair_mesh by focusing on cross-sectional analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the tool is useful for inspecting internal geometry such as wall thickness and hole placement. However, it does not provide explicit guidance on when not to use it or mention alternative tools for other analyses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. It describes a read-only analysis without side effects, but lacks details on error handling, performance, or what happens when no pockets are found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with the main purpose. Follows with details on use and parameters. Could be slightly more compact but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema), the description adequately covers purpose, usage context, parameters, and return type. Lacks edge cases or error scenarios but sufficient for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaningful explanations for both parameters: file_path as STL file path, min_depth_mm as minimum depth with default 0.3mm. This adds value beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it detects pockets and cavities in a mesh, specifying it analyzes base models for recessed regions on top and bottom faces. It distinguishes from siblings by noting it should be called before compose_models or multi_material_print.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call this before compose_models or multi_material_print to get pocket dimensions for overlay geometry. Provides clear context but does not mention alternatives or 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool examines telemetry and optional history, lists detectable failures, and mentions return structure. It implies a read-only operation but does not state side effects or permissions, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is informative but slightly verbose with example keys and structured formatting. It is front-loaded with the main purpose and uses clear sections. Could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (failure report dict or success dict). All 4 parameters are described, including optional ones. Nested object schemas are illustrated with example keys, making the tool self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by describing each parameter: printer_name, telemetry with example keys, telemetry_history as optional list for trend analysis, job_info with example keys. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Analyze printer telemetry to detect and classify a print failure' and enumerates specific failure conditions (thermal runaway, layer shift, etc.), establishing a specific verb+resource+scope. It distinguishes from siblings by focusing on telemetry analysis, though not explicitly contrasting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when telemetry data is available but provides no explicit when-to-use, when-not-to-use, or alternative tools. Siblings like analyze_print_failure_smart or predict_print_failure exist but are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool is read-only by stating it 'Shows' results but does not explicitly state it has no side effects. Given no annotations are provided, the description should clarify that it does not modify data, which is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences for purpose and a bullet-like listing of arguments. It avoids unnecessary details and is well-structured for quick reading.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two parameters and no output schema, the description provides sufficient information about what the tool returns (layer count reduction, time savings, percentage). It also links to the required input source, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description effectively explains both parameters: plan_data is linked to its source function, and uniform_height_mm includes its unit and default value. This adds meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb 'Compare' and the resource 'adaptive plan time savings vs uniform layer height'. It distinguishes itself from other estimate tools by focusing on the comparison aspect, which is unique among sibling tools like estimate_mesh_print_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that plan_data should come from generate_adaptive_slicing_plan, providing a clear prerequisite. It also documents the default value for uniform_height_mm. However, it does not include when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It explains the computational method (divergence theorem, density, infill fraction, shell thickness) and states the return type (dict with volume, weight, bounding box). It does not mention error handling or prerequisites like valid STL files, but the provided details add significant transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a docstring with a purpose sentence followed by parameter explanations. It is front-loaded and to the point, though the first line is slightly redundant with the parameter descriptions. No unnecessary sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description covers the core calculation method, parameters, and return values. It lacks details on material name list or precise output structure (e.g., bounding box format), but is largely complete for usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 defines each parameter with examples (material: pla, abs, etc.), ranges (infill_percent: 0-100), and defaults (20, 1.2). This adds meaning beyond the schema, though it could further explain parameter impacts on the calculation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Estimate the printed weight of an STL file' with a specific verb and resource. It details the computational method (divergence theorem, material density, infill, shell) and clearly distinguishes from sibling tools like 'estimate_mesh_print_time' and 'estimate_print_cost_from_mesh' which estimate different quantities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or comparisons with sibling tools are given, though the purpose is clear enough to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the dual-mode behavior, experimental nature, and image requirements. However, it does not specify the return value or output format, nor does it mention potential costs with the API key or error handling for invalid images.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then logically breaks into default/opt-in, experimental note, image tips, and parameter details. While somewhat lengthy, each section contributes necessary context without irrelevant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (dual-mode, external API), the description covers usage scenarios and parameter guidance well. However, it lacks explanation of the output (what is returned to the agent), error scenarios, and lifecycle of the generated model, which are important for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the bare input schema: it defines image_url as requiring a publicly accessible URL (PNG/JPG), limits provider to 'meshy', and enumerates style options ('realistic' or 'sculpture'). With 0% schema description coverage, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it makes a 3D model from a reference image and distinguishes between a default mode (agent uses vision to write OpenSCAD) and an opt-in cloud path (using Meshy). This differentiation sets it apart from sibling tools like generate_model which likely take text prompts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the keyless default path vs the opt-in cloud path, and provides image tips for best results. However, it does not explicitly compare with sibling tools or state when not to use this tool, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry the burden. It discloses return data structure and interpretation (high variance indicates warped bed). However, it does not mention side effects, permissions, rate limits, or whether the data is cached. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single paragraph with a bullet-like list inside. It is front-loaded with the core purpose, and each sentence adds useful information. Could be slightly more structured (e.g., separate use case and limitation), but it remains concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description adequately covers what the tool returns and how to interpret the data. It includes a specific use case and a platform limitation. For a simple read tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description cannot add param semantics. However, it adds value by explaining the output fields and their meaning, which is beyond what the empty schema provides. Given zero parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies the tool returns bed mesh/probe data, lists returned values (probed_matrix, mesh_min, mesh_max, variance), and distinguishes by stating it only works on OctoPrint and Moonraker, not Bambu Lab printers. This makes the purpose clear and differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states use case: 'diagnose first-layer adhesion issues' and provides a negative case: 'Not supported on Bambu Lab printers'. However, it does not compare with alternative sibling tools like bed_level_status or calibrate_direct, so it lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it explains the shell generation algorithm, the material savings report, the default output filename pattern, and the inline 3D stage side effect including automatic decimation of oversized meshes and the fallback behavior for hosts that don't render MCP Apps panels. This is substantial behavioral disclosure, though it could go further by noting error conditions or non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, front-loaded with a purpose statement, followed by mechanism details and a parameter docstring. The INLINE 3D STAGE paragraph is long but each sentence earns its place, explaining the interactive viewer, decimation behavior, and cross-host fallback. It could be trimmed slightly, but there is little waste overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with no output schema or annotations, this description covers all the bases: purpose, generation mechanics, parameter semantics, return value shape, and notable side effects (3D stage, decimation). It could be improved by enumerating the specific keys returned in the stats dict, but overall it is quite complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the embedded docstring documents all three parameters with meaningful semantics: file_path (path to STL), wall_thickness_mm (units and default), and output_path (default naming convention). It also documents the return value. This fully compensates for the sparse schema, though a more structured presentation in the schema itself would make it flawless.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence, 'Create a hollow version of a mesh to save material,' is a specific verb+resource+benefit statement that clearly distinguishes this tool from the many other mesh operations in the sibling list (repair_mesh, merge_stl, scale_mesh_to_fit, etc.). The rest of the intro reinforces the unique value proposition of offset shells and material savings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to save material' implies when to use this tool, and the mention of reporting estimated material savings provides context. However, there is no explicit guidance on when NOT to use it or any named alternative tools (e.g., 'for simple scaling use X'). Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the schema by stating the sort order (newest to oldest) and the maximum limit (100). Since no annotations are provided, this disclosure is valuable, though it omits details like authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 lines) with a clear structure: one line for purpose, then Args section, then return behavior. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 optional parameters, no output schema), the description provides sufficient context for basic usage. It describes ordering and the scope of results, though it lacks output schema details which could aid decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the limit (default 20, max 100) and status (possible values and default behavior). It adds clear semantics not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves history of completed, failed, and cancelled print jobs, specifying the verb and resource. However, it does not differentiate from sibling tools like 'print_history' or 'failure_history', leaving potential ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to use the parameters (limit, status) and the order of results, but lacks explicit guidance on when to use this tool versus alternatives, such as when to prefer 'print_history' or 'job_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States it lists snapshots and returns metadata, mentions default limit (20). Does not disclose pagination, performance, or whether it's read-only. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is compact, with clear header, use case explanation, and bulleted args. Front-loaded purpose, no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description does not explain what metadata fields are returned. No mention of pagination or ordering. For a list tool, this is a gap, but basic usage is covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage 0%, but description adds brief descriptions for each parameter: printer_name, job_id, phase (with examples), limit (with default). Adds meaning beyond schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'List persisted snapshots from the database' with specific verb and resource. Explains types of snapshots (print monitoring, timelapses, manual captures) and use cases (review print history, correlate with outcomes). Distinguishes from sibling tools like 'print_snapshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to use: 'review print history visually or correlate snapshots with print outcomes'. Does not explicitly state when not to use or suggest alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions the plan includes preparation steps, parameter adjustments, and risk assessment, but does not disclose whether the tool modifies any state or has side effects. Some context is given, but more could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main sentence, followed by a bulleted decision guide. It is front-loaded with the core purpose. Slightly verbose due to formatting, but overall concise and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description adequately explains the tool's role, input requirements, and output structure (preparation steps, adjustments, risk assessment). It provides sufficient context for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It describes each parameter: failure_id as the ID from detect_print_failure, printer_capabilities and safety_profile as optional dicts. This adds basic meaning beyond the schema, but lacks format or content expectations for the dicts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a recovery plan for a previously detected failure, specifying the resource (failure ID from detect_print_failure) and action. It also distinguishes from plan_print_recovery, which is a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use this tool when you have a failure_id from detect_print_failure, and use plan_print_recovery when you have a printer_name and job_id. This clearly differentiates between the two tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses automatic protocol detection and the two output modes (save path or base64). However, it does not mention whether the operation is read-only, any potential side effects, or required permissions. The description covers basic functionality but lacks deeper behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loaded. The first sentence states the core purpose, followed by essential details on protocols and parameter behavior. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two optional parameters and no output schema, the description covers the main aspects: capture action, supported protocols, and parameter behavior. However, it misses details like the image format of the base64 string or any prerequisites (e.g., printer must be online). For a tool with many similar siblings, it is reasonably complete but could be slightly enhanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully. It explains both parameters clearly: 'printer_name' as target (omit for default) and 'save_path' as optional save location (otherwise base64). This adds significant meaning beyond the schema's type/nullable constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a webcam snapshot from the printer, specifying the verb 'Capture' and the resource. It lists supported protocols (Bambu A1/P1, OctoPrint/Moonraker, RTSPS for Bambu X1), distinguishing it from siblings like 'webcam_stream' and 'analyze_print_snapshot'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context by detailing the automatic handling of different protocols, but it does not explicitly state when to use this tool over alternatives like 'webcam_stream' or 'monitor_print'. No usage exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it combines analysis and planning, mentions default region behavior, but does not describe the return value format, error conditions, side effects, or performance characteristics. The transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: first sentence states the all-in-one nature, second gives usage context, then well-structured parameter list with non-default values explained. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explain what the tool returns (a plan, confirmation, etc.). It also omits error handling and prerequisites. For a tool with 7 parameters and a combined function, this leaves gaps for an agent to understand the complete input-output contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: it provides examples for material (PLA, PETG, ABS), specifies model_height_mm as total height, defaults for nozzle_diameter_mm (0.4), and enumerates mode strategies (balanced, quality_first, etc.). It also explains that regions default to a STANDARD region. This goes beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'All-in-one adaptive slicing: analyze geometry + generate plan.' It explicitly says it combines geometry analysis and plan generation in a single call, distinguishing it from sibling tools like 'analyze_model_geometry' and 'generate_adaptive_slicing_plan'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Ideal when you have basic model info and want a quick adaptive plan without multiple tool calls.' This implies appropriate usage (for quick, basic info) and suggests when not to use (when separate analysis or planning is needed). However, it does not explicitly list alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It describes the analysis process and output format (slicer_overrides) but does not explicitly state that the tool is read-only or disclose any side effects (e.g., file modifications, permissions, rate limits). It is adequate but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise summary followed by clear parameter bullet points. Every sentence contributes to understanding the tool's purpose, inputs, and output. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, but the description explains the return value (slicer_overrides) and its usage. It covers main aspects but lacks details on edge cases (e.g., no bed contact) or error conditions. Still, it is sufficiently complete for its intended use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides full semantic meaning for each parameter: model_path (STL/OBJ), material (affects warp risk, defaults to PLA), and printer_id (for bed-slinger detection, optional). It adds significant value beyond the schema's basic titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it recommends brim/raft settings based on geometry and material, specifying analysis inputs (bed contact area, warp tendency, printer type) and output (brim width, raft, slicer_overrides). It distinguishes from siblings like analyze_warping_risk and recommend_settings by being specific about its output and usage with slice_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing brim/raft settings but does not explicitly state when to use or when not to use, nor does it mention alternatives or exclusions. Among siblings, there are related tools like recommend_settings and analyze_warping_risk, but no guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return value (endpoint ID) but does not disclose side effects (resource creation), idempotency, authorization requirements, or rate limits. This leaves significant gaps for a tool that creates a persistent resource.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, bullet-like parameter list, and return statement. Every sentence adds value, and it is appropriately concise without extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with no annotations or output schema, the description covers parameters, return value, and related tools. However, it could be improved by specifying behavioral aspects such as idempotency or what happens on duplicate registration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 all four parameters: url (HTTPS URL), events (optional list with examples), secret (optional HMAC secret), description (label). This adds substantial meaning beyond the schema's type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Register', the resource 'webhook endpoint', and the purpose 'to receive Kiln event notifications'. It distinguishes from siblings by referencing list_webhooks and delete_webhook for other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's basic usage context and explicitly mentions alternatives for listing and deleting webhooks. However, it does not provide explicit 'when to use' guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that a new version is created (not destructive), that history is preserved, and that notes record the rollback origin. It also details the 3D stage behavior, including decimation of oversized meshes and the fallback for hosts without MCP Apps panels. This is rich behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, parameter details, and return value. The 3D stage paragraph is additional but relevant context. It's slightly verbose but each sentence adds value. The front-loading of the core purpose is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (rollback with history preservation, 3D stage side effect), the description covers the essential aspects: what it does, how parameters work, what it returns, and the side effect. No output schema exists, so the return description is helpful. It could mention error cases or prerequisites, but it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 `design_id` as 'The design to rollback' and `to_version_id` as 'The version number (integer) or design_id:N ref to restore.' This adds meaning beyond the bare schema types (string), clarifying the format and semantics. However, it doesn't elaborate on edge cases or validation, so a 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Rollback a design to a previous version.' It specifies the action (rollback), the resource (design), and the key behavior (creates a new version preserving history). It distinguishes itself from siblings like `save_design_version` and `list_design_versions` by explaining the rollback semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: to rollback a design to a previous version while preserving history. It doesn't explicitly state when not to use it or name alternatives, but the context is clear. The mention of creating a new version rather than overwriting implies a safe operation, which helps the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool scans all directories under a specific path, performs case-insensitive literal substring matching, and returns results newest first. No side effects or permissions are mentioned, but for a search tool this is standard. The behavior is well-specified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise, with the purpose front-loaded and details in a structured list. The 'Args' section uses a bullet-like format that aids readability. Minor improvement could remove redundant phrasing or further condense, but it is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description gives a concise return description ('list of matching version records, newest first'). It covers scanning, matching fields, case-insensitivity, and search behavior. Some might desire more detail about the record format, but for a search tool this is adequate. The complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It does so effectively by explaining that query is a literal substring (not regex) and limit is the maximum results with default 10. This adds value beyond the schema's type/default declarations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('search'), the resource ('design versions'), and the fields searched (prompt, notes, or design name). It also details the scanning location and case-insensitive substring matching, distinguishing it from sibling tools like list_design_versions (which lists all) and search_design_templates (which searches templates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use when you need to find design versions by text in prompt, notes, or name. However, no explicit guidance is given on when not to use this tool or how it compares to alternatives like list_design_versions or search_design_templates. The description relies on context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses encryption method (PBKDF2 + XOR), at-rest encryption, and that only metadata is returned (plaintext never exposed). This goes beyond basic 'store' behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action. The Args section is well-structured. Minor redundancy ('Encrypt and store' then repeating encryption) but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 params, no output schema), the description adequately explains the core behavior and parameters. It mentions the return behavior (only metadata) and encryption, making it complete for a credential storage operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description's 'Args' section adds meaning for all three parameters, including examples for credential_type and clarity for value and label. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool encrypts and stores a credential, distinguishing it from siblings like 'retrieve_credential' and 'list_credentials'. The verb 'store' paired with the resource 'credential' makes 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.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for storing sensitive secrets but does not explicitly state when to use this tool versus alternatives like 'retrieve_credential' or 'list_credentials'. No condition or exclusion is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only says 'Start a firmware update' with no details on prerequisites, side effects (e.g., printer restart, downtime), destructive potential, or required permissions. For a potentially destructive action, far more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line for purpose, one line for usage guidance, and a two-line Args block. Every sentence adds value with no repetition or fluff. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and potential impact of a firmware update tool (no output schema, 2 parameters), the description lacks completeness. It does not explain what happens after the update is started, how to monitor progress, or how to handle errors. An agent needs more context to use this tool safely and effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds clear, concise descriptions for both parameters: 'Printer to update' for printer_name and 'Specific version to update to (latest if None)' for target_version. This adds meaningful guidance beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('Start a firmware update'), the resource ('on a specific printer by name'), and distinguishes from sibling tools ('fleet-level'). It explicitly mentions version pinning, making the purpose specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('Use this in multi-printer setups') and when-not-to-use ('For single-printer setups, use update_firmware instead'), directly naming an alternative tool. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions checking required fields, validating postal codes, and returning warnings and a normalized address. However, it does not explicitly state if the tool has side effects (e.g., writes to a database) or if it is read-only, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise with two short paragraphs. The 'Args:' section is useful but slightly redundant since the schema already lists parameters. It could be shorter, but it remains clear and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what the tool returns (warnings and normalized address). It covers the main behaviors like validation of postal codes and identification of missing optional fields. The context is sufficient for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to parameters beyond the input schema, which has 0% description coverage. For example, it specifies that country should be an ISO 3166-1 alpha-2 code and that state is recommended for US addresses. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates and normalizes a shipping address for fulfillment orders. The verb 'validate and normalize' combined with the resource 'shipping address' gives a specific and actionable purpose. It distinguishes from sibling tools like 'fulfillment_order' which creates orders, making this tool's role unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by instructing to use the returned normalized address when placing fulfillment orders. It does not explicitly state when not to use or suggest alternatives, but the context is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the behavior: parsing JSON, appending the part, and returning the updated state. It mentions that the assembly is 'existing' and that the result is 'updated assembly state', implying immutability. While it could add more about error handling or permissions, it adequately discloses the core behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a docstring format: purpose, process, then parameter list. It is slightly long but each sentence adds value. The front-loaded purpose is clear. It could be more concise by grouping defaults, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, 3 required, and no output schema, the description covers all parameters and the return value (updated assembly state). It explains the process and default values. It lacks details on constraints (e.g., part_id uniqueness) or error scenarios, but for a moderately complex tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It fully describes each parameter: assembly_json (state from previous tool), part_id (unique identifier), file_path (mesh file path), position offsets, material (filament material), role (structural role). This provides essential context beyond the schema's property names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a part to an existing assembly' with a specific verb and resource. It explains the process of parsing JSON, appending, and returning updated state. It distinguishes from sibling tools like create_assembly (creates new) and add_assembly_interface (adds interface).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the assembly must already exist by specifying that assembly_json comes from create_assembly or previous tool calls. However, it does not explicitly state when to use this tool vs alternatives like add_assembly_interface or when not to use it. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure weight — and it delivers. It transparently discloses the inline 3D stage side effect, automatic decimation of oversize meshes, and host-dependent fallback behavior ('in hosts that render MCP Apps panels... attaches a browser stage link for hosts that don't'). It falls short of a 5 only because it omits error/failure behavior and what happens when the named decoration doesn't exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a punchy one-liner, then the core value prop, then params, then rich behavioral notes — a logical downward-spiral of detail. The only waste is 'This is the magic tool —' which is marketing fluff that doesn't add functional info. The param docs use reST format with helpful types but add a bit of noise. Otherwise, every other sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, side-effectful 3D stage, no output schema), the description covers all essential dimensions: purpose, params, return value ('Dict with decorated model path and settings used'), and side effects. The gap is that it doesn't discuss error conditions, performance expectations for large models, or whether the tool mutates the original file. It's thorough, but a few edge-case behaviors would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Param semantics are excellent. The description's docstring block provides meaning for all 5 params, even though schema coverage is 0%. It explains name is a 'slug', model_path accepts 'STL or OBJ' formats, material is an 'Override (empty = use proven or detect from printer)', face has values 'auto, top, bottom, etc.', and printer_id is 'for material detection'. This exactly compensates for the empty schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening line 'Apply a saved decoration to a new model — proven settings, one call' is a specific verb+resource+scope statement. It's further clarified with 'Loads a previously saved decoration and applies it to the target model using the exact settings that worked before,' clearly distinguishing this from sibling decoration tools like decorate_surface by emphasizing the 'replay a proven recipe' angle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: when you have a saved, proven decoration to replay ('proven settings, one call', 'decorations that took many iterations to perfect can be replayed'). However, it never explicitly names an alternative (e.g., 'use decorate_surface for new decorations') or provides when-NOT-to-use guidance. The usage context is clear but implicit rather than explicit, and no exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool returns an enhanced prompt with OpenSCAD-specific instructions for structured code, named variables, comments, and material-aware limits. This adds behavioral context beyond the basic purpose, though it does not cover potential side effects or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with the main purpose in the first sentence and a clear usage directive in the second paragraph. It avoids redundancy and is front-loaded, though the phrase 'enhanced prompt' appears twice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description does not specify the return type (e.g., a string). It does cover the tool's function and parameters adequately for a simple generation tool, but omitting the output format leaves room for ambiguity. The contrast with one sibling helps, but more sibling differentiation could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no parameter descriptions), so the description must compensate. It briefly explains each parameter: 'requirements: Natural language description of the desired part,' 'material: Optional material override (e.g. petg),' and 'printer_model: Optional printer model ID (e.g. bambu_a1).' This adds meaning beyond the raw schema types but is not highly detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool 'Build a prompt optimized for parametric OpenSCAD code generation,' which is a specific verb+resource combination. It directly contrasts with the sibling tool build_generation_prompt, indicating distinct functionality for generating editable OpenSCAD code versus mesh files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Use this instead of build_generation_prompt when you want the AI to generate editable OpenSCAD code rather than a mesh file.' This provides clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes a read operation ('check firmware version') but lacks details on authentication, permissions, or any side effects. Adequate for a simple query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, then usage guidelines, then parameter description. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple schema (1 parameter) and no output schema, the description covers purpose, usage context, and parameter intent. Could mention what the return value contains (e.g., version string), but not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. The description says ''printer_name: Printer to check'', which adds minimal context beyond the schema field name. Could clarify expected format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks firmware version for a specific printer by name, and distinguishes from sibling ''firmware_status'' by specifying multi-printer vs single-printer context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (multi-printer setups) and when not to (single-printer setups), naming the alternative ''firmware_status''.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: analyzes height-to-base ratio, warns about wobble/fail, suggests reorientation. It is non-destructive and returns a dict assessment. However, it does not mention side effects, auth needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (5 lines), front-loaded with the action, and each sentence adds value. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, no annotations, and no output schema, the description covers purpose, input, output type, and behavior. It could be more specific about the returned dictionary structure, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by stating the file format (STL or OBJ) and that the parameter is a file path. It also notes the return type (Dict with stability assessment). Schema description coverage is 0%, so the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking model orientation stability for printing. It specifies analysis of height-to-base ratio and warning/ suggestion. It differentiates from siblings like 'auto_orient_model' or 'analyze_printability' by focusing on orientation stability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for verifying orientation stability before printing but does not explicitly state when to use this tool versus alternatives such as 'auto_orient_model' or 'optimize_print_orientation'. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It lists computed metrics and return format, indicating a read-only operation, but does not disclose permissions, file format assumptions, or error handling. The transparency is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at roughly 80 words, front-loads the purpose, and organizes metrics and parameters in a clear, scannable manner. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains return values (dict with metrics and flag). It covers purpose, usage, parameters, and output. Missing are error conditions or file format restrictions, but for the complexity level, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by labeling file_a as 'reference (original) mesh' and file_b as 'modified mesh'. Schema coverage is 0% in structured form, so the description compensates well. However, it leaves out file format details and validation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'compare', resource 'mesh files', and expected output 'geometric differences'. It is specific enough to distinguish from sibling tools like analyze_mesh_geometry or diff_design_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Useful for verifying that a repair, rescale, or regeneration actually improved the model', giving context on when to use. It does not mention when not to use or provide alternative tools, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that it runs a local cost estimate and optionally a fulfillment quote, returning a side-by-side comparison. It does not disclose any destructive actions, authentication needs, rate limits, or other behavioral traits beyond the basic workflow.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary sentence, a brief workflow explanation, and a bullet-like Args section. It is front-loaded with the purpose. While concise, the Args section could be formatted more cleanly (e.g., actual bullet points) for better readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 7 parameters and no output schema, the description covers conditional behavior and parameter defaults. However, it does not detail the return value structure beyond 'side-by-side comparison', which is a gap since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, but the tool description provides detailed explanations for all 7 parameters, including purpose, defaults, and conditional usage (e.g., file_path explanation, fulfillment_material_id omitted skips fulfillment). This adds significant value beyond the schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares local printing cost vs. outsourced manufacturing, with specific verb 'compare' and resource 'print options'. It distinguishes itself from sibling tools like 'compare_material_properties' by focusing on cost comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to compare costs) and includes conditional behavior: if G-code is provided, only local estimate; if fulfillment_material_id omitted, skip fulfillment quote. However, it does not explicitly state when not to use it, nor mention alternatives such as 'estimate_cost' or 'fulfillment_quote'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explicitly states the operation is irreversible, which is critical behavioral information. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, parameter clarification, and irreversible warning. Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple delete operation with one parameter and no output schema, the description covers purpose, parameter source, and irreversibility. It could mention error cases but is adequate overall.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains that 'file_path' should be obtained from 'printer_files()', adding meaning beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Delete' and resource 'G-code file from the printer's storage'. It is specific and distinguishes from sibling tools like 'delete_agent_note' or 'printer_files'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the file path should come from 'printer_files()', hinting at a prerequisite. However, it does not explicitly state when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States the effect (no longer receive notifications) but lacks details on permanence, authentication, or error cases. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with no wasted words. Clear structure: purpose line, arguments section, and a consequence note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential: what it does, what parameter it needs, and the outcome. Could mention error handling, but is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning by specifying that endpoint_id comes from register_webhook, which is useful context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Delete a registered webhook endpoint.' with a specific verb and resource, and it distinguishes from sibling tools like register_webhook and list_webhooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies that endpoint_id is the ID returned by register_webhook and explains the consequence of deletion. Does not explicitly mention when not to use, but provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes scanning method, timeout parameter, and return value summary. No annotations provided, so description carries full burden. Could mention safety (read-only) or network impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: purpose first, then method details, then Args/Returns. Every sentence adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, method, parameter, and return value adequately for a simple discovery tool. Could optionally mention network requirements or errors, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (timeout) with clear explanation 'Maximum scan duration in seconds (default 5)'. Schema coverage is 0%, so description adds needed semantic value beyond schema title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Scan the local network for 3D printers' with specific methods (mDNS/Bonjour, HTTP subnet probing) and lists supported printer types. Distinct from sibling tools like register_printer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells to use register_printer for adding discovered printers. Provides clear context for when to use (network discovery) but lacks explicit when-not examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns about community models being unverified and recommends validation. It also specifies default behavior for parameters (e.g., dest_dir defaults to system temp). But it lacks details on permission requirements, disk space implications, or error handling. With no annotations, the description carries the full burden but is not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, safety notes, and a docstring-style parameter list. While the safety warnings are important, they add some verbosity. The key information is front-loaded, making it easy to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no output schema, and no annotations, the description covers the essential information: parameter details, workflow, and safety considerations. It does not discuss error conditions or edge cases, but it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides detailed parameter semantics: it explains the relationship between file_id, model_id, and download_all, gives defaults, and describes the purpose of each parameter. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Download model file(s) from a marketplace to local storage.' It specifies the verb (download), resource (model files), and source (marketplace). This distinguishes it from sibling tools like 'model_files' (which lists files) and 'upload_file' (which uploads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow after downloading: validate with validate_generated_mesh, upload with upload_file, and print with start_print. However, it does not explicitly state when to use this tool versus alternatives like 'model_files' or 'download_generated_model', nor does it mention prerequisites or 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It discloses fallback lookup and shareable format, but doesn't detail permissions or rate limits. Adequate for a read-like export operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
52 words, no redundancy, front-loaded with purpose, followed by behavior and parameter docs. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 1 simple parameter and no output schema, the description is nearly complete. Could specify JSON structure details, but overall sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds examples for printer_model (e.g., 'ender3', 'bambu_x1c'), significantly enhancing parameter understanding beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Export a safety profile as a shareable JSON object' and 'Returns the full safety limits for a printer model', clearly distinguishing from siblings like get_safety_profile or add_safety_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context by stating fallback behavior (community then bundled profiles) and suitability for sharing, but lacks explicit when-not-to-use or direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states that the tool checks a 'built-in knowledge base of FDM filament compatibility' and returns ranked alternatives with trade-off descriptions. It does not disclose side effects, destructive behavior, authentication needs, or rate limits. The description provides minimal behavioral context, which is adequate but could be more explicit about non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: a one-line summary, a paragraph explaining functionality, and a formatted Args section. Every sentence adds value without redundancy. It is front-loaded with the core purpose, making it easy for an agent to quickly understand the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description covers purpose, usage, parameters, and return type (ranked list with trade-off descriptions). It could mention error handling or that the knowledge base is not user-updatable, but overall it provides sufficient context for an agent to use the tool correctly. Minor gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description includes a detailed Args section that explains each parameter: material (original filament material with examples), reason (optional filter with enumerated values), and min_score (threshold range). This adds significant meaning beyond the bare schema, which only provides types and defaults. The description compensates well for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find substitute filament materials when your preferred material is unavailable (returns ranked list).' It specifies the verb (find), resource (substitute filament materials), and context (when unavailable). Additionally, it distinguishes itself from the sibling tool 'get_best_material_substitute' by noting it returns a ranked list versus a single best match, satisfying the distinction requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (when preferred material is unavailable) and explicitly mentions an alternative tool for a single best match. However, it does not explicitly state when not to use it or list other possible alternatives. The guidance is sufficient but lacks thorough exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly indicates the tool is read-only (returns state, not mutates) and mentions snapshots. However, it doesn't disclose any prerequisites (e.g., must be after start_monitored_print) or failure cases. Adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line for purpose, one for return, one for parameter. No wasted words. It uses a clean docstring format and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only one parameter and no output schema, the description explains the input source and vaguely describes the return (state + snapshots). It could be more detailed about the return format or possible states, but is largely complete for a simple status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no parameter description (0% coverage), but the description compensates by explaining that monitor_id is 'The monitor ID returned by start_monitored_print.' This adds crucial semantic information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Check the status of a first-layer monitor.' It uses a specific verb ('Check') and resource ('first-layer monitor status'), which differentiates it from sibling tools like bed_level_status or cfs_status. The mention of returning captured snapshots adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: the tool should be used after starting a monitored print (as the monitor_id argument comes from start_monitored_print). It implies polling for status but does not explicitly state when not to use it or provide alternatives. Still, the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains that alerts are generated from cancellations, failures, or processing delays. However, it does not specify return format, side effects, authentication needs, or rate limits, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no wasted words. Front-loaded with the main purpose, followed by brief elaboration. Perfectly sized for a simple alert-checking tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters and no output schema, the description covers the domain well: it defines alerts and their triggers. It could explicitly mention output structure (e.g., list of alerts with fields), but for a tool of this simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is 100%. Baseline is 4. The description adds value by explaining what the tool returns, which is appropriate given no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'check' and resource 'fulfillment order alerts', and specifies three alert types (stalled, failed, cancelled). It distinguishes itself from sibling tools like fulfillment_order by focusing on active alerts from a background monitor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking active alerts, but does not explicitly state when not to use it or suggest alternative tools like fulfillment_order_status for detailed order info. Context is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the absence of annotations, the description carries the full burden. It states the basic behavior (sampling parameters to create variations) but omits important details: whether the operation is synchronous or asynchronous, resource implications, permissions needed, or side effects. The return format is only briefly mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, mechanism, and parameter docs. It is front-loaded with the main purpose. However, the parameter descriptions add length and could be slightly more concise, but overall it earns its keep as it adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool generating parametric variations, the description covers the core use case, parameters, and return type. It lacks details on asynchronous behavior or persistence, but given no output schema, the mention of return values is helpful. It is sufficient for an agent to select and invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides substantial added value beyond the schema, which has 0% description coverage. It explains each parameter: template_id with an example, variation_count with allowed range (1-10) and default (3), and parameter_ranges with the expected structure (dict of param to [min, max]). This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: 'Generate multiple variations of a parametric template.' It further explains the mechanism (sampling parameter values) and use cases (exploring design space, offering choices), effectively distinguishing it from siblings like generate_from_template which likely produces a single output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions when to use the tool ('useful for exploring design space or offering choices'), providing clear context. However, it lacks explicit guidance on when not to use it or direct comparisons to alternatives, which would strengthen the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations provided, so the description must carry the burden of transparency. It describes the tool as a read-only lookup returning public fields, but it does not disclose any potential side effects, authentication requirements, or performance characteristics. For a simple lookup, this is adequate but leaves room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus a parameter documentation line. It is front-loaded with the primary purpose and efficiently uses each sentence to convey key information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema, no nested objects), the description provides adequate context: what it does, what it returns, and a pointer to a sibling tool for advanced needs. It could mention potential error conditions, but overall it is sufficiently complete for an agent to decide to invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a single required parameter 'material' without a description, but the tool description provides examples ('pla', 'petg') to clarify the expected format. This adds value beyond the schema, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs a 'compatibility lookup for a material's public design floor', uses a specific verb and resource, and distinguishes itself from siblings by mentioning that it returns the same fields as `get_material_properties` and directing deeper queries to `answer_material_question`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool (for basic compatibility lookup) and explicitly suggests `answer_material_question` for deeper engineering guidance. It does not explicitly state when not to use it, but the provided guidance is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses key behavioral traits: no authentication needed, return fields (tier, validity, expiration, source, session_state, action_required), and specific actions for a lapsed OAuth session. It lacks only explicit mention of idempotency or side effects, which are minimal for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct at 8 sentences, front-loading the main purpose. It efficiently conveys necessary details without redundancy. Slight room for improvement: the second paragraph could be more concise, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no parameters and no output schema, the description fully covers what is needed: what data is returned (tier, validity, expiration, source, session_state, action_required), authentication requirements, and how to handle specific cases. It is complete enough for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage (empty schema). According to guidelines, 0 parameters earn a baseline of 4. The description adds no parameter details because none are needed, but it enriches understanding by explaining the output structure, which indirectly aids correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves license tier, validity, and details. It uses a specific verb ('Get') and resource ('license status'), making its purpose unambiguous. It distinguishes itself from sibling tools by focusing on license information, which is unique among the many tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that no authentication is required, which is a useful usage hint. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., when to use check_my_tier or other license-related tools). The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly implies a safe read operation by stating it returns a list, but does not disclose potential prerequisites, error conditions, or confirm that the operation has no side effects beyond reading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core function, and each sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters or output schema, the description adequately explains what it returns and why. It lacks mention of edge cases like an empty list, but otherwise is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter meaning. According to guidelines, 0 params gets baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns the list of trusted printer hostnames/IPs, with a specific verb and resource. It also distinguishes from sibling tools like trust_printer and untrust_printer by explaining the purpose (preventing spoofed-printer attacks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about what trusted printers are and why they are used, implicitly guiding when this tool should be called. However, it lacks explicit exclusions or comparison to alternatives like discover_printers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that winding order is reversed, output_path defaults to overwriting the input, the inline 3D stage is opened, and oversized meshes are decimated. This adds meaningful behavioral context beyond the core operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then explains behavior in two clear paragraphs. The inline 3D stage paragraph is slightly verbose but provides necessary context about preview behavior and decimation. No wasted words, but could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and absence of annotations/output schema, the description covers the key aspects: the operation, parameter semantics, default overwrite behavior, and post-success UI behavior. It omits error conditions and output dict structure details, but overall it is substantially complete for a mesh mirroring tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides parameter-by-parameter details that exceed the schema: it explains that file_path is the STL file, axis must be 'x', 'y', or 'z' with default 'x', and output_path defaults to overwriting the input. This semantic context is critical because schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Mirror (reflect) a mesh along an axis.' It clearly states the operation and differentiates from sibling tools like rotate_model or rescale_model by focusing on reflection and normal preservation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The tool's purpose is clear and implies when to use it (when a mirrored mesh is needed), but it does not explicitly state when not to use it or mention alternatives. It lacks explicit exclusions or comparisons to sibling tools, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses that the tool is read-only (lists files, no side effects). It specifies return fields but does not detail potential errors or limitations (e.g., authentication requirements, pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three sentences covering purpose, arguments, returns, and a usage hint. No filler or repetition, and information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema or annotations, the description adequately explains what the tool does and returns. It could mention potential failure modes (e.g., invalid thing_id) but is sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning to the parameter 'thing_id' by stating it is a 'Numeric thing ID', which is redundant given the schema type 'integer' and 0% schema description coverage. It could include more context (e.g., 'The ID of the Thingiverse model').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists downloadable files for a Thingiverse model, with a specific verb ('List') and resource ('downloadable files'). It distinguishes from sibling tools like 'download_model' by describing its output as a list and referencing 'download_model' for the actual file download.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (before downloading) and explicitly references 'download_model' as the next step. However, it does not provide explicit when-not-to-use or alternative tools for similar tasks (e.g., 'model_details' for metadata).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, the description provides good behavioral context: the pipeline finishes the current step before pausing, meaning it is not instantaneous. It also indicates that the pause is temporary and requires a resume call. The description does not contradict any annotations (none provided). The only missing details are error conditions (e.g., what if the pipeline is not running) or side effects, but for a simple pause action the behavior is adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parameter line, efficiently conveying the tool's purpose, behavior, and next steps. It is front-loaded with the key action and uses minimal words. Every sentence serves a purpose (action, detail, follow-up, parameter explanation). No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema, no nested objects), the description covers the essential aspects: what it does, how it behaves, and what comes next. It references the sibling `pipeline_resume` for continuation. It does not mention prerequisites (e.g., pipeline must be running) or error states, which would be helpful but are not critical for a straightforward pause action. Overall, it is fairly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes a parameter list for `execution_id` with the text 'The pipeline execution ID.', which adds meaning beyond the schema (which has no description). Since schema coverage is 0%, the description partially compensates by naming the parameter and explaining its role. However, it does not provide details like format, how to obtain the ID, or examples. For a single required string parameter, this is acceptable but not exceptional.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Pause a running pipeline') and provides specific behavior details: it finishes the current step then pauses before the next. It also distinguishes from siblings by explicitly mentioning `pipeline_resume` to continue, and implicitly differentiates from `pipeline_abort` (which stops permanently). The combination of verb ('Pause') and resource ('pipeline') with boundary condition is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly states when to use the tool (to pause a running pipeline) and provides guidance on the next step ('Use `pipeline_resume` to continue'). It does not explicitly list when not to use it or compare to `pipeline_abort`, but the context of siblings and the behavioral description make the appropriate usage clear. A minor improvement would be to state that this is for temporary pauses only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains that it re-runs the step and, if successful, continues remaining steps. However, it omits details like error handling, state requirements, or what happens if the step fails again.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences total. The first sentence gives a clear high-level purpose, followed by an Args section for parameters. Every sentence is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required parameters and no output schema, the description covers the core behavior and parameter meanings. It lacks details on return values or error cases, but given the simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description manually documents both parameters with meaningful roles: 'execution_id' as pipeline execution ID and 'step_index' as zero-based index. This adds value beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retry a specific failed step in a pipeline'—a specific verb and resource. It distinguishes from sibling tools like pipeline_abort or pipeline_resume by focusing on retrying a single step, not the entire pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a step has failed and should be retried, and the context of continuing from that step is clear. However, it does not explicitly mention when not to use it or list alternative tools, though siblings are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It explains what is captured (content file, settings, pipeline) and that it saves to the library for reuse. However, it does not mention potential side effects like overwriting duplicates, permissions needed, or error scenarios (missing .kiln_recipe.json). This leaves some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise introductory paragraph followed by a clear parameter list. While the parameter list is lengthy (10 items), it is necessary given the complexity and lack of schema descriptions. No superfluous sentences are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema, no annotations), the description covers key aspects: purpose, what is captured, the workflow with apply_decoration, and return value (dict with details and library path). Missing some details like conflict resolution or prerequisites, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the tool description provides thorough explanations for all 10 parameters. It clarifies each parameter's role, provides example values (e.g., 'mode' options: emboss/deboss, 'content_type' options: photo/svg/qr/text/auto), and explains the default behavior for 'depth_mm' (0 = auto). This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Save a proven decoration to the library for reuse on future models.' It uses a specific verb 'Save' and resource 'decoration to the library'. It also distinguishes itself from the sibling tool 'apply_decoration' by explaining that the saved decoration can later be applied, avoiding confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use: after proving a decoration on a model, to save it for reuse. It mentions using 'apply_decoration' later, providing a clear workflow connection. However, it does not explicitly state when not to use this tool or list alternatives like 'list_decorations' or 'delete_decoration'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses automatic diff computation, version increment, sidecar persistence, inheritance of brief_id/intent_hash, and parent_version_id being unused. Lacks information on required permissions or side effects like overwriting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for description, Args, and Returns. However, includes promotional text about Kiln Pro, which adds length without essential guidance. Still organized and front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a tool with 10 parameters, no output schema, and no annotations. Explains behavior, inheritance, and file paths. Lacks error handling or prerequisites, but generally complete for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's 'Args' section thoroughly explains all 10 parameters, including recommended keys for provenance and inheritance behavior for brief_id and intent_hash. Adds significant meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Save a new version of a parametric design' with specific details about diff computation, version increment, and persistence. Distinguishes from siblings like list_design_versions or diff_design_versions through its action of saving a new version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. Usage is implied from the purpose, but no alternatives or conditions are stated. The description focuses on functionality rather than decision context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It discloses case-insensitive multi-token matching and required fields, but does not mention return format, pagination, or side effects. The information is somewhat incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose and a structured Args section. Every sentence adds value, and it is well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the search logic and parameter meaning. It could be more complete by describing the return format, but it is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for the 'query' parameter. The description compensates by explaining the parameter and providing examples, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches the material catalog by brand, type, or keyword. It specifies the matching behavior (case-insensitive multi-token, all tokens must match), which distinguishes it from other search tools like 'search_cached_models' or 'list_material_catalog'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage for searching the material catalog, but does not explicitly compare with alternatives like 'list_material_catalog' or other search tools. However, the purpose is clear enough that an agent can infer when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond a simple 'set' by explaining the semantic nuance: the record is a claim, not verified; nothing checks the spool; the value persists even after a swap; and Kiln marks it as determined_by: user_reported. This transparency is critical for the agent to correctly interpret the tool's output and avoid misreporting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with a clear one-line purpose, followed by a short explanatory paragraph about the claim semantics, then an Args list. Every sentence adds value, and there is no fluff. The formatting is clean and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no output schema, no nested objects, 5 simple parameters), the description covers the essential aspects: what it does, the behavioral nuance, and parameter meanings. It is slightly incomplete in that it does not mention what happens after the record is set (e.g., whether other tools will reflect the change immediately) or any error conditions, but these are not critical for an operation of this nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does list all five parameters with brief meanings: printer_name, material (with examples PLA, PETG, ABS), color (optional), spool_id (optional), and tool_index (default 0). This provides basic semantics, but it lacks detail on constraints, formats, or when to use optional parameters. It is adequate but not enriched beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Record which filament material is loaded in a printer.' It uses a specific verb (record) and resource (material for a printer), and distinguishes itself from read-only sibling tools like get_material or list_materials by emphasizing it writes a claim rather than reports a measurement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies the tool's intended use (recording a user-reported claim) and warns against misreporting the value as confirmed or sensed. However, it does not explicitly state when to use this tool over alternatives (e.g., get_material, check_material_match) or provide exclusions for when not to use it. The usage context is implied but not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavioral steps: structural risk analysis, optional auto-reinforcement, and inference of slicer settings. However, with no annotations, it does not mention potential side effects, latency, or any destructive actions (e.g., if it modifies files or requires locks). The description focuses on positive capabilities without noting risks or limitations, which is a moderate gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-structured with a numbered list of steps, making it easy to follow. It is somewhat verbose but necessary for conveying the multi-step pipeline. No redundancy or filler is present, so it earns a high score for clarity despite length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the lack of an output schema, the description explains the return (STL path and recommended settings) and how to chain with subsequent tools. It does not cover edge cases like failure during structural analysis or behavior when auto_reinforce is false, but these are self-explanatory from the description. Overall, it is sufficiently complete for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptive text, so the description carries full burden. It thoroughly covers all four parameters: 'template_id' (from list_design_templates), 'parameters' (with JSON example), 'material' (with example PLA), and 'auto_reinforce' (explains the boolean effect). Each parameter's purpose is clarified beyond the schema, earning full credit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: generating STL from a template, adding structural analysis and print settings. It explicitly differentiates itself from the simpler 'generate_from_template' by being higher-level and describes the complete pipeline in numbered steps, 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides guidance on when to use this tool: it is 'recommended for functional parts' and is a one-step design-to-print-ready pipeline. It also mentions that after using it, the agent can call 'reslice_with_overrides' or 'run_reslice_and_print', but it does not explicitly state when to use simpler alternatives like 'generate_from_template' (e.g., for non-functional parts). This is a minor gap in explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the output (identity, email, groups, role) and the action, but does not mention any side effects, authentication requirements, or state changes, leaving gaps in behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose stated first, followed by context (enterprise feature) and a brief parameter explanation. Every sentence adds value, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately explains the return values (identity, email, groups, role). It also notes enterprise feature and the parameter source. It could mention prerequisites like SSO being configured, but overall it is fairly complete for a simple exchange tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the schema only provides the parameter name and type. The description adds crucial meaning by explaining that 'code' is the authorization code from the IdP callback, which is essential for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Exchange an SSO authorization code for user identity and role'), specifies it's an enterprise feature, and distinguishes it from related tools like sso_login_url and sso_status by focusing on the code exchange step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use after IdP login to exchange the auth code. It does not explicitly state when not to use or name alternatives, but the context is sufficient for a specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description provides some behavioral details: it clears active alerts and is reversible. Lacks information about permissions, idempotency, or side effects on ongoing operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a param docstring. No wasted words, front-loaded with purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simplicity (1 param, no output schema, no annotations), the description covers purpose, reversal, and alert clearing. Could mention error states or behavior if called when not started, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The param docstring 'Printer to stop monitoring' adds semantic meaning beyond the schema's 'Printer Name'. With 0% schema coverage, the description compensates adequately for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it stops background health monitoring for a printer. Distinguishes from sibling start_printer_health_monitoring by describing the inverse operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to cancel the health-check loop started by start_printer_health_monitoring and mentions it can be restarted. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must handle transparency. It lists what is returned (root causes, fixes, prevention tips, storage/drying requirements) but does not mention behavior for no matches, invalid inputs, or whether the tool is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a detailed explanation of functionality, usage context, examples, and parameter definitions. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return format. It covers both parameters with examples. However, it does not address error handling or empty results, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds value by explaining each parameter: material is a Material ID with examples, symptom is keywords with examples. This compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to diagnose a 3D printing problem by material and symptom, searching a knowledge base and returning root causes, fixes, and tips. It provides specific examples and distinguishes from siblings like 'diagnose_print_failure_live' by focusing on material-symptom pairs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use this when a user reports a print failure, quality issue, or asks why my print is doing X.' This provides clear context, but it does not explicitly exclude cases like printer hardware failures or suggest alternative tools like 'get_print_diagnostic'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses action and purpose, and implies session must be active, but does not discuss side effects, validation, or failure modes. Lacks depth on what happens if session is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise and well-structured: action statement, purpose explanation, usage guidance, then parameter list. No wasted words, information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters and no annotation coverage, the description provides complete parameter details and usage context. Does not describe output schema or prerequisites beyond active session, but the presence of output schema reduces need for return value explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by listing all 14 parameters with explicit units and context (e.g., 'Current hotend temperature (C)'). Adds meaning beyond type/name, though some parameters could have more detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool pushes a telemetry snapshot to an active interception session, using specific verbs ('Push') and resource ('telemetry snapshot'). It distinguishes from siblings like intercept_gcode_command by focusing on telemetry data for rule evaluation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises periodic calls during printing with example frequency ('every few seconds'), and explains why telemetry is needed (for rules evaluating device state). Does not mention when not to use or alternatives, but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the outcome: 'After a successful upload the file will appear in printer_files() and can be started with start_print().' It does not mention potential side effects like overwriting existing files, but the expected behavior is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is excessively verbose and highly repetitive. The same sentences about extensions and recommended paths are repeated multiple times with slight rewording, making it unnecessarily long for a simple upload operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context: protocol handling, file validity, extension rules, printer selection, and post-upload effects. It lacks explicit failure handling details, but overall it is complete for the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are well described: file_path requires existence and readability, with extensions depending on printer; printer_name allows omission for default. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states 'Upload a local G-code file to the printer.', which is a direct and specific purpose. The description also mentions automatic protocol handling, reinforcing the core function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by indicating when to use this tool (e.g., after slicing, using the recommended path) and clarifies that file extensions depend on the target printer. However, it does not explicitly compare with alternative upload tools like upload_file_confirm.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. Describes validation and return of validated state, with extra details on printer_id effect. Does not explicitly state read-only nature or side effects, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, then structured Args block. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inputs are well-described, but output is vague ('validated assembly state with results populated'). Without output schema, more detail on return structure (e.g., list of warnings/errors) would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds rich meaning: explains assembly_json as JSON string of current state, printer_id with detailed effect including screw_hole block specifics. Goes far beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'validate' with resource 'assembly', detailing exact checks (clearance, joint validations) and outcome (validated assembly state). Clearly distinguishes from generic validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance for the optional printer_id parameter, including conditions for its effect and historic behavior. Lacks explicit comparison with sibling tools like check_assembly_clearances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that validation uses printer-specific safety profiles and falls back to generic defaults. However, it does not disclose whether the tool is read-only (e.g., does it alter any state?) or what happens on validation failure (e.g., throws error, returns list of issues). Without annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with the purpose stated upfront followed by usage guidance and parameter details. It avoids unnecessary verbosity while covering key points, though the Args section slightly repeats schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the core functionality, usage, and parameter semantics. However, it does not explain the return value (e.g., validation errors or pass/fail) or edge cases like empty commands. For a validation tool, this is adequate but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for parameters, but the description adds meaning by stating that 'commands' are G-code separated by newlines and 'printer_id' is an optional model ID for profile-aware validation. This provides necessary context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates G-code with printer-specific safety limits like PTFE temp caps and speed limits. It explicitly distinguishes itself from the sibling validate_gcode by being preferred when the target printer is known, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: it is preferred over validate_gcode when you know the target printer, and it falls back to conservative generic defaults if printer_id is omitted. This clearly indicates when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that analysis identifies specific geometric features and mentions parameter precedence. However, it does not describe the return format, potential side effects, permissions, or error cases. The behavioral disclosure is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with a clear purpose sentence, then lists Args with bullet points. Every sentence adds value without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 parameters, no output schema, no annotations), the description is nearly complete. It covers purpose, parameters, and usage. The only gap is not describing the return format, but without an output schema, this is acceptable. The description provides sufficient context for an AI agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate fully. It explains both parameters: model_path (path to STL/3MF file) and model_stats (pre-computed dict with example keys). It clarifies that either or both can be provided and that model_stats takes precedence. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects geometric regions affecting slicing (overhangs, bridges, thin walls, top/bottom surfaces, fine details, curved surfaces). It distinguishes itself from sibling tools like 'analyze_mesh_geometry' and 'analyze_printability' by focusing on slicing-specific geometry analysis. The verb 'Detect' and resource 'geometric regions in a 3D model' are specific and precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides adequate usage context: use when needing to identify geometric features that affect slicing, with each region getting optimized slicing parameters. However, it does not explicitly state when not to use this tool or mention alternatives among sibling tools. The guidance is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It clearly explains the polling behavior, terminal state condition, timeout, and blocking nature. It does not disclose what happens on timeout (e.g., exception or status), but overall provides good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with a structured Args section. It is relatively concise but could be slightly more compact. It front-loads the purpose and then details parameters, which is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple but the description lacks detail on the return value (final status) - e.g., format or possible values. It does not explain error handling or timeout behavior. Given no output schema, this is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 lists all 4 parameters with explanations: job_id is required, provider defaults to 'meshy', timeout defaults to 600 seconds, poll_interval defaults to 10 seconds. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to wait for a generation job to complete and return the final status. It uses specific verbs like 'Wait', 'polls', and 'block', and distinguishes from sibling tools like 'generation_status' by emphasizing synchronous blocking behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Useful for agents that want to block until a model is ready.' It implies when to use this tool (synchronous waiting) but does not explicitly state when not to use it or mention alternatives like polling via 'generation_status'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns compatibility, adhesion quality, temperature notes, and dissolution instructions. For a non-destructive check tool, this is sufficient transparency. It does not mention side effects or auth needs, but those are typically irrelevant for such a tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, with two short paragraphs and a clear Args section. The first line immediately states the purpose. A slight redundancy exists in the Args section (which mirrors the schema), but overall it is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-string-parameter tool with no output schema, the description covers purpose, parameter semantics, return values, and usage examples. It is contextually complete given the tool's simplicity and the richness of sibling tools that provide alternatives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the tool has only two parameters. The description adds meaning by labeling each ('First material', 'Second material') and providing examples ('pla', 'abs', 'tpu'). This helps the agent understand the expected values beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Check if two materials can be co-printed') and the specific resource ('dual extrusion'). It distinguishes from siblings like 'check_material_match' or 'find_material_substitute' by focusing on multi-material pairing and listing return fields (compatibility, adhesion quality, temperature notes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage examples are provided ('can I print PLA with TPU?', 'what support material works with ABS?'), which helps the agent decide when to invoke this tool. It does not explicitly list when not to use it or mention alternative tools, but the examples clearly target multi-material planning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the checks performed (connectivity, temperature, progress, error state) and mentions adhesion analysis if model_path is supplied. However, it does not explicitly state that the tool is read-only or has no side effects, which is important for a health assessment tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise introductory sentence, a bullet list of checks, and a clear 'Args:' section. It is front-loaded with the core purpose and contrast to watch_print. Every sentence adds value without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 optional parameters, no enums, no output schema, and no nested objects, the description covers the tool's behavior and parameter usage well. It explains the checks performed and how parameters affect behavior. However, it does not describe the output format or return values, which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so effectively with an 'Args:' section explaining each parameter's purpose and dependencies (e.g., model_path enables adhesion analysis, material is passed to that analysis). This adds crucial meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it performs a 'single-shot health assessment' of the current print, distinguishing it from 'watch_print' which starts a background thread. It lists specific checks (connectivity, temperature, progress, error state), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with 'watch_print', indicating when to use a quick check versus persistent monitoring. It states it is for 'quick is the print OK right now? queries' without starting background tasks. However, it does not explicitly mention when not to use it or list all alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses offline behavior, return structure (stats vs community), and access requirements (signed-in for community). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured. Purpose is front-loaded, additional detail in second paragraph. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema or annotations, the description adequately explains the return format, contents, and offline behavior. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema provides no semantic gap. Description adds meaning by explaining what the two return sections contain, which is valuable context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get overall print-registry statistics' and distinguishes between 'stats' and 'community' sub-sections. It is specific and differentiates from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions offline capability and that community counts are available for signed-in users, but does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description carries full burden. Describes rendering pipeline (individual renders stitched with labels) and return type (PNG path). Lacks details on performance, error handling, or side effects; but for a read-only render tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient structure: overview sentence, use cases, output description, then parameter list. No unnecessary words; every sentence adds value. Front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters and no output schema, description covers key aspects: purpose, use cases, arrangement logic, return type, and all parameters. Minor omissions: no mention of error handling or behavior with invalid inputs, but overall sufficient for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description fully compensates with detailed parameter explanations: paths (file types, count), labels (defaults), angle (enum list), width/height (defaults), colors (hex array). Adds meaning beyond schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Render 2-4 models side by side in a single comparison image,' with clear verb and resource. Distinguishes from siblings like render_model_preview (single render) and compare_mesh_versions (mesh diff) by specifying it's a visual diff for any 3D models.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear use cases (texture variants, design iterations, material colors, parameter sweeps) and constraints (2-4 models, layout rules). Does not explicitly state when not to use, but context implies it's for multi-model comparisons; alternatives are not named but are differentiable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does well: it states anonymity, exactly what is stored, what is never stored, and how job_id prevents duplicate federation contributions. It could add return behavior or error semantics, but the privacy and data-flow transparency are strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and privacy, then uses a structured Args block. Every sentence and argument explanation serves a functional or safety-relevant purpose, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter write tool with no annotations and no output schema, this description is quite complete: it covers purpose, privacy guarantees, dedupe, and all parameter meanings. It is only slightly incomplete in not describing the tool's response/return value or failure behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the Args section compensates fully by explaining every parameter beyond the schema. It provides outcome enum values, quality grade range and default, optionality, job_id dedupe meaning, and the geometric_signature_v2 rationale, adding substantial semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: "Contribute a print outcome to the community registry." It immediately clarifies the anonymous aggregation purpose and differentiates from the related record_print_outcome flow by explaining the dedupe semantics around job_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Guidance is mostly implied rather than explicit. The dedupe note about record_print_outcome and watched prints gives context on when job_id matters, but the description never directly states when to choose this tool over record_print_outcome or other community-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description clearly states the tool generates a report (read operation) with no side effects. It details the behavioral traits: combines risk analysis, reinforcements, load analysis, and produces a score. This fully discloses the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear outline of the plan components and a parameter list. It is slightly verbose with the docstring-style param descriptions, but each sentence adds value. It could be more concise by removing the redundant 'full design reasoning pipeline' phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately describes the return value as 'Complete improvement plan as dict' and lists the main components (risks, reinforcements, load analysis, score). It provides enough context for an agent to understand what the tool produces and how it fits into a design workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explicitly documents each parameter: 'file_path: Path to the STL file', 'min_cross_section_mm2: Minimum safe cross-section area', 'sharp_angle_threshold_deg: Angle for sharp edge detection.' This adds meaning beyond the schema's title fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates a 'complete structural improvement plan' and lists specific components (risks, reinforcements, load analysis, score). It distinguishes the tool as a 'design advisor' versus a 'geometry validator,' differentiating it from sibling tools like 'analyze_structural_risks' and 'assess_load_bearing'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool: for a comprehensive improvement plan that answers specific design questions (e.g., 'this bracket needs a gusset'). It implies it's for after basic validation. However, it does not explicitly exclude cases where simpler analysis tools suffice, nor does it list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details that it combines temperature deltas, bed adhesion, overhang geometry, etc., to produce a ranked diagnosis with fixes. This provides good insight into internal behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main sentence, a distinction paragraph, and a bullet list of parameters. It is slightly lengthy but every sentence adds value, making it effective without being overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations or output schema, but the description covers purpose, parameter semantics, and distinction from sibling. It mentions the output is a 'ranked diagnosis with actionable fixes,' but lacks details on return format. Given the complexity, more specificity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description's Args section thoroughly explains each parameter: printer_name (omit for default), model_path (enables geometry diagnosis), material (filament type), printer_id (enables intelligence lookup). This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it diagnoses print failures using live printer state and model geometry. It distinguishes itself from analyze_print_failure by specifying real-time vs historical analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly contrasts with analyze_print_failure, giving context for when to use this tool. It also describes optional parameters, but does not provide explicit 'when not to use' or alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the version ID format (design_id:N) and the behavior when no colon is present, and states the return type (unified diff string). With no annotations, it carries the burden well but lacks error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise, uses a clear structure with Args/Returns sections, and wastes no words while covering key aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers input format and output type adequately for a simple tool, but given no output schema, it could benefit from an example or note on error cases like missing versions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds clear directional semantics ('from' and 'to' versions) beyond the schema's bare titles 'Version Id A' and 'Version Id B', which is critical for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Compute a unified diff between two design versions,' specifying the verb (compute diff) and resource (design versions). This distinguishes it from siblings like list_design_versions and compare_mesh_versions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for comparing versions via diff but provides no explicit when-to-use or alternatives among the many version-related sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the computation logic (volume-based, infill, etc.) but does not disclose side effects (e.g., file read-only), permissions, or latency. Adds some behavioral context but insufficient for a full transparency profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and structure, including a computation summary, see-also, material list, and parameter definitions. While the parameter list adds length, it is necessary given missing schema descriptions. No redundant content, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description clearly states the return type (dict with weight, length, cost). It covers inputs, supported materials, and provides a comparison alternative. For a simple estimation tool, it is fully complete and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates fully. It provides clear explanations for all 5 parameters (e.g., 'Infill percentage 0-100', 'Number of perimeter shells'), adding meaning far beyond the schema titles. Essential for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates material usage and cost for printing a mesh. It specifies the computation (filament weight, length, cost) and distinguishes from the sibling tool 'estimate_print_cost_from_mesh' via the 'See also' note, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a 'See also' reference to a richer alternative, guiding when to use this tool vs. the sibling. It implies basic material-only estimation but does not explicitly state when not to use or list prerequisites. Clear context but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses return fields and license requirement but does not explicitly state read-only nature or any rate limits. Adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-sentence structure, front-loaded with purpose. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple tool with no parameters. Lists return fields and prerequisites (license), despite no output schema. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is trivial 100%. Description adds meaning by listing return fields, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets fleet historical analytics with specific metrics (success rates, utilization, job throughput) and distinguishes itself from fleet_status, which provides live printer status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs fleet_status for live data. Does not mention alternatives like fleet_utilization or fleet_job_status, but provides clear context for the primary alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the need for a Meshy API key and internet, but lacks details on side effects (e.g., cost, API limits, failure behavior). No annotations exist, so the description carries the full burden but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with short paragraphs and bullet-like formatting. Could be slightly more concise (e.g., removing 'Cloud AI texture generation' redundancy), but each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks description of the return value (e.g., path to textured model). Given no output schema, this is a notable gap. Otherwise, it covers prerequisites, parameters, and sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters have explanations beyond the schema: mesh_path (absolute path), prompt (max 600 chars with example), style (enum with default), provider (only meshy for retexturing). Schema coverage is 0%, so the description compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cloud AI texture generation' for untextured meshes. It distinguishes from siblings by explicitly naming 'apply_procedural_texture' and 'apply_geometric_texture' as offline alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool (online AI texture generation) vs alternatives (offline textures). Also specifies prerequisites (Meshy API key) and mentions post-processing with 'auto_multicolor_from_texture'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies this is a read operation and mentions the data is public. It lists the categories of returned data. Since no annotations are provided, the description bears the burden of transparency and does so adequately, though it could mention any access restrictions or side effects (none expected).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs, front-loaded with the main purpose. The second paragraph adds a helpful pointer to an alternative tool. Every sentence is meaningful and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description partially explains return values (thermal, chemical-safety, process-design floor). It is sufficient for a simple tool with one parameter, though a more structured description of the output format would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining the material_id parameter: it's a material key (e.g., 'petg', 'tpu', 'cf_pla'), case-insensitive. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'material's public safety and printing-property profile'. It specifies what is returned (thermal, chemical-safety, process-design floor) and differentiates from deeper engineering questions handled by kiln-pro.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some guidance by stating the tool returns public safety and printing properties and directs deeper questions to kiln-pro. However, it does not explicitly say when to use this tool versus sibling tools like compare_material_properties or get_material_info, nor does it state 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses important behavioral detail: success-rate metrics cover all materials by default, material scopes them, hash-based lookup may return incomplete history, and identified_by indicates whether the result is shape-precise or file-based. It is a read-only 'get' operation, but side effects and failure modes are not explicitly addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but it is carefully structured with a clear opening, a prominent best-practice warning, and an organized Args section. Every sentence adds value, though it could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the lack of an output schema and annotations, the description is comprehensive: it explains what data is returned, how identifier methods affect results, what identified_by means, and how the material filter behaves. This is sufficient for an agent to invoke the tool correctly with any of the five optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates by explaining every parameter: file_hash, material, model_path, geometric_signature, and geometric_signature_v2. It adds meaningful context such as 'Empty = all materials', 'the best input', and 'if you already have one from fingerprint_model'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get all print attempts for a model' and describes the returned history, settings, and quality grades. It distinguishes model_path-based shape identification from hash-based byte identification, but it never explicitly contrasts this with the sibling print_history tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides strong, explicit guidance on when to use model_path versus file_hash, warns that hash-only lookups may miss history, and explains the identified_by response field. However, it doesn't mention when to choose this tool over sibling alternatives like print_history.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only diagnostic operation by describing combination of data sources, but does not explicitly state it is non-destructive or discuss permissions or side effects. The context added (cross-referencing, actionable response) is helpful but incomplete for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, primary usage, list of combined data, and examples. It is informative but could be slightly more concise (e.g., the list of data sources could be shortened). Still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (combining multiple diagnostic sources) and lack of output schema, the description adequately explains what the tool returns: a single actionable response with troubleshooting, compatibility, storage, and post-processing info. However, it does not detail the response structure, which would be helpful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description compensates well by explaining each parameter: material (e.g. 'pla'), symptom (e.g. 'stringing'), printer (optional, for compatibility context). Examples illustrate valid values, adding significant meaning beyond the schema's bare type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a comprehensive print diagnostic' and emphasizes it is the primary tool for debugging print problems, combining multiple knowledge sources. It distinguishes itself from siblings like troubleshoot_print_issue by claiming a broader scope and cross-referencing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this FIRST when a user reports any print quality problem.' and explains it eliminates the need for multiple tool calls. Provides concrete examples showing typical usage patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation returning a summary, but does not elaborate on side effects or safety. Adequate 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded with 'Quick-start guide', and efficiently conveys purpose and usage. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully covers what the tool does and when to use it. Complete for its intended role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. The description adds meaning by specifying the tool's purpose and return content, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns an onboarding summary explaining Kiln, tool discovery, core workflows, and useful tools. This distinguishes it from the many operational sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to call at the start of a session if unfamiliar with capabilities. No alternative or when-not-to-use, but that is reasonable for an onboarding tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool is read-only and safe (no authentication needed) and returns health info. However, it does not disclose return format, side effects, or any caching behavior. For a simple health check, this is adequate but not highly detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a clear purpose: stating the function, providing auth and use case context, and linking to the sibling tool. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no annotations, and no output schema, the description is complete. It covers purpose, auth requirements, use cases, and distinguishes from the sibling tool. Nothing essential is missing for this simple health check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (vacuous). According to guidelines, baseline for 0 parameters is 4. The description adds no parameter information, which is appropriate as there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns system health information for monitoring, and distinguishes itself from kiln_health by specifying that it's for basic health checks while kiln_health provides detailed system information. This is a specific verb and resource with sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions no authentication required and lists use cases (container healthchecks, dashboards, verifying server responsiveness). It also provides a see-also to kiln_health for more detailed info, giving context on alternatives. However, it lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: returns catalog with specific fields, filtering logic, and universal vs. Klipper-only add-ons. No side effects or auth mentioned, but acceptable for a read-only 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured with a clear lead sentence, followed by details and usage hint. Minor redundancy between first two sentences, but not harmful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description lists what is returned (tool change times, color capacity, compatibility). Explains filtering and linking to another function. Missing details like pagination or error handling, but adequate for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage, but description provides a clear definition for printer_id including examples. The single parameter is well explained beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'List' and resource 'multi-material add-on systems for 3D printers'. Differentiates from sibling list tools (e.g., materials lists) by focusing on a specific add-on category. Includes concrete examples of add-ons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (need add-on info) and how filtering works with printer_id. Mentions downstream use in estimate_before_design. Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the action ('marks as aborted') and a key behavioral detail ('completed steps are preserved'). No annotations exist, so burden is on description. Lacks info on undo capability, permissions, or side effects, but adequate for a simple abort.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus one parameter doc. Front-loaded with purpose, no filler. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple abort tool with one parameter, the description covers the purpose, effect, and parameter meaning. No output schema exists, but return value is likely straightforward. Sibling tools are many but well-differentiated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema), so description adds meaning by explaining 'execution_id: The pipeline execution ID.' This goes beyond the schema's type-only definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Abort') and resource ('running or paused pipeline'), clearly distinguishing from sibling tools like pipeline_pause, pipeline_resume, and pipeline_status. It is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for running or paused pipelines, but does not explicitly mention when not to use (e.g., already aborted or completed pipelines) or compare to alternatives like cancel_job. Still, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions that events cover job lifecycle, printer state changes, etc., and specifies the default and maximum limit. However, it lacks details on ordering (presumably most recent first), error handling, and whether pagination is supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short paragraphs with no superfluous text. The first sentence states purpose, then 'Args:' clearly presents parameters, and a final sentence summarizes return scope. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter usage, and the types of events returned. Given the absence of an output schema, this is sufficient. Minor missing details like ordering (most recent first) and potential errors could be added but do not significantly detract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates. It explains limit as 'Maximum number of events to return (default 20, max 100)' and type as 'Filter by event type prefix' with clear examples, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get recent events from the Kiln event bus,' specifying a concrete verb and resource. It distinguishes itself from sibling tools like job_history or failure_history by focusing on the general event bus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool and provides details on the limit and type parameters, including examples for prefix matching. However, it does not explicitly contrast with sibling tools or indicate 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It discloses that consent_to_store must be True and describes the shipping_address keys, but does not explain side effects like error handling or what happens when overwrite is false and a profile exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured as a docstring with an Args section. It is front-loaded with the main purpose, and each parameter description is succinct and informative with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (5 params, nested objects, no output schema), the description covers parameter semantics and the consent requirement. However, it lacks information about the return value or success/failure indication, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description thoroughly explains each parameter: name examples, shipping_address keys with required fields, the role of overwrite and set_default, and the mandatory consent_to_store. This adds significant value beyond the schema's minimal titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save a local shipping profile' with explicit verb and resource, and emphasizes the consent requirement. It distinguishes from siblings like delete_shipping_profile and list_shipping_profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the condition 'after explicit user consent' and details the consent_to_store parameter. It does not explicitly contrast with alternatives but provides clear context for when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that Sport and Ludicrous modes increase nozzle temperature, which is a useful behavioral trait. However, it does not mention other potential side effects, permissions required, or return value, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four well-structured sentences with a clear args block. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers purpose, parameter, and a behavioral note. Missing information on return value or error handling, but still adequate for a simple setter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description provides detailed parameter semantics: lists all four valid values with their speed percentages and descriptions. This adds significant meaning beyond the schema's minimal 'Profile' title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'printer speed profile', and restricts to Bambu Lab printers for specificity. Differentiates from siblings like get_speed_profile and printer_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly limits usage to Bambu Lab printers and suggests using printer_status() to check current profile. Lacks explicit 'when not to use' but the restriction is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly states the output (IdP authorization URL or SAML redirect) and mentions the optional state parameter for CSRF protection. It does not mention side effects or authentication requirements beyond enterprise feature, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three lines) and well-structured: primary action first, context ('Enterprise feature'), output explanation, then parameter description. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers input and output sufficiently. It explains what is returned but could mention prerequisite setup or error conditions, though not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It fully explains the 'state' parameter's purpose ('optional opaque state parameter for CSRF protection'), adding meaning beyond the schema's name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the SSO login URL for redirecting users to the identity provider, and specifies it returns OIDC or SAML URLs. This distinguishes it from sibling tools like sso_exchange_code and sso_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's an 'Enterprise feature,' giving context, but does not explicitly state when to use it vs alternatives or provide exclusions. It implies usage for initiating SSO login but lacks clear guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states the tool is advisory, does not override safety limits, and cross-references current printer availability. It also notes that rankings are based on success rates from historical outcomes. However, it does not detail how suggestions are computed when no historical data exists or how conflicts are resolved, which prevents a higher score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise main line, followed by a note, then a parameters block. It front-loads the primary purpose. The Args block is somewhat redundant with the schema but provides extra commentary. Overall, it is focused and not verbose, earning a score of 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool lacks an output schema, so the description should clarify the return value. It mentions 'suggest the best printer' and 'rankings', which is ambiguous (single vs. multiple results). Given the complexity and the many sibling printer tools, more detail on the output format (e.g., list of printers with scores) would improve completeness. Nonetheless, it covers inputs and core behavior adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It does so effectively by explaining each parameter: file_hash is for matching previous prints, material_type filters by material (with example 'PLA'), and file_name is informational only. This adds significant meaning beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Suggest the best printer for a job based on historical outcomes.' It specifies a distinct verb ('suggest') and resource ('printer for a job'), differentiating it from siblings like 'discover_printers' (which lists printers) and 'find_printers_with_material' (which filters by material). The mention of ranking based on historical outcomes sets it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool: to get an advisory suggestion based on historical outcomes, optionally filtered by file hash or material type. It explicitly warns that suggestions are advisory and do not override safety limits, advising to run preflight validation. While it doesn't explicitly state when not to use it, the advisory note and context relative to siblings (e.g., 'discover_printers' for listing all printers) provide sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns jurisdiction codes, tax types, and rates for 22 regions. However, it doesn't explicitly state it's a read-only operation or any other behavioral aspects, though that is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences, each serving a distinct purpose. It front-loads the primary action and efficiently adds context about regions and downstream use.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains what is returned (jurisdiction codes, tax types, rates) and how many regions. It could be more explicit about the output structure, but it is sufficient for a simple list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is complete. The description does not need to add parameter details, and the baseline for no parameters is high. The description adds value by explaining what the output contains.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'List all 22 supported regions', using a specific verb and resource. It distinguishes itself from sibling tools like tax_jurisdiction_lookup and tax_estimate by specifying it lists all jurisdictions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent to use this tool to match the user's location and pass the resulting code to fulfillment_order or tax_estimate. While it doesn't explicitly mention when not to use, the context is clear and provides practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool adds proprietary BambuStudio start/end sequences, and mentions the return value (dict with output_path). It does not explicitly mention file creation or potential side effects, but the core behavior is transparently described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise. It front-loads the purpose and prerequisites, then lists parameters in a structured way. A few sentences could be trimmed, but it is well-organized and each parameter gets a clear line. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 params, no output schema, no annotations), the description covers prerequisites, parameter details, return value, and post-usage steps. It lacks information on error handling, validation, or file size limits, but it provides enough for an agent to use the tool correctly in most cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 provides docstring-style explanations for 10 of the 11 parameters, including defaults and examples for some. The missing param is 'resume_mode' (a boolean). Overall, it adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wrap raw PrusaSlicer G-code in a Bambu-compatible 3MF (Bambu Lab only).' It specifies the verb (wrap), resource (raw PrusaSlicer G-code), and target (Bambu-compatible 3MF), distinguishing it from all sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for PrusaSlicer G-code intended for Bambu printers) and prerequisites (file must have -use-relative-e-distances and empty start/end G-code). It also provides next steps (upload_file() and start_print()). However, it does not explicitly state when not to use or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core behavior (edge detection and beveling), the return value ('Dict with sharp edge count, triangles added, and output path'), and a significant side effect: the inline 3D stage opening on success and automatic decimation of oversized meshes. It does not mention file overwrite behavior or error conditions, but the provided context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose, followed by compact parameter documentation and a return-type note. The 3D stage paragraph adds relevant behavioral context but is somewhat lengthy; still, every sentence earns its place and there is little waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter mesh processing tool with no annotations and no output schema, the description is fairly complete: it explains inputs, output default, return value, and post-success behavior. It could be more complete with notes on file overwriting, input formats, and failure modes, but these are not critical gaps given the detail already present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It does: every parameter is documented with meaningful semantics (file_path is the STL path, distance_mm is chamfer distance, angle_threshold_deg controls which edges are chamfered, output_path defaults to <name>_chamfered.stl). This adds real meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Add chamfers (flat bevels) at sharp edges.' It clearly explains the operation (detecting sharp edges and beveling them with flat transition faces) and distinguishes itself from the sibling 'add_mesh_fillet' by explicitly contrasting chamfers with fillets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating that 'Chamfers are faster to print than fillets and reduce stress concentration,' which helps an agent choose chamfering over filleting. It does not name add_mesh_fillet explicitly or state when not to use this tool, but the comparison provides clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns technical recommendations and does not indicate destructive side effects. However, it does not explicitly confirm that the tool is read-only or mention any authentication or rate limitations. The description is adequate but lacks explicit safety assurances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with the main purpose, then differentiates from a sibling tool, provides examples, and ends with parameter explanations. It is front-loaded but somewhat lengthy. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema, no enums) and the rich sibling context, the description is remarkably complete. It covers what the tool does, when to use it, how parameters work, and provides examples. There is no missing information necessary for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds significant meaning. It explains the 'requirements' parameter as 'natural language description of what the object needs to do — functional needs, environment, loads, etc.' and 'material' as optional override. This goes beyond the schema's basic type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Analyze a functional requirement and return technical recommendations.' It specifies it is an internal-lookup tool that resolves natural-language requirements into material recommendations, design patterns, dimensional constraints, print orientation rules, and expert guidance notes. It distinguishes itself from the user-facing flow tool design_session, making its role unique among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool versus the alternative: 'For the user-facing flow... call design_session(...) first. That tool internally calls this one for technical lookups; agents calling analyze_design_requirements directly should treat it as a pre-design analysis pass, not the user-facing entry point.' It provides concrete examples of valid inputs, guiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavioral aspects: it describes the analysis scope, tier-dependent behavior, and parameter effects on warping/thermal checks. It does not mention side effects or rate limits, but for a read-only analysis tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a summary paragraph and Args section. It is somewhat verbose but front-loaded with the core purpose. Minor redundancy exists (e.g., repeating 'analysis' in both parts), but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 params, no output schema), the description explains the analysis performed and return values (score, grade, recommendations). It also covers tier differences. However, it lacks detail on the output structure (e.g., format of recommendations), which would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides critical meaning for all 9 parameters. It explains defaults, units, and semantic context (e.g., material ID for warping analysis). This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a 3D model for FDM printing readiness, specifying analyses (overhang, thin wall, bridging) and output (score, grade, recommendations). This distinguishes it from sibling tools like troubleshoot_print_issue or check_printer_material_compatibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises passing material and printer_id for better accuracy and explains free vs Pro tier behavior. However, it does not explicitly contrast with alternatives or specify when not to use this tool, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses multiple behavioral details: auto-applies fixes, specific transformation types (thickened walls, fillets, base plate, gussets), returns before/after scores and skipped list, requires OpenSCAD, and opens an interactive 3D stage with automatic decimation. It doesn't explicitly state whether the original file is modified vs. creating a new one, but the output_path parameter implies output to a new file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized, starting with a one-sentence summary followed by bullet lists of fixes and parameters, then an additional note about the 3D stage. Every sentence contributes useful information, especially given the need to compensate for the schema's lack of descriptions. Slightly verbose but justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (mesh analysis + automatic fixes), no annotations, no output schema, and minimal schema descriptions, the description covers the essential aspects: inputs, outputs, dependencies, skipped items, and interactive stage behavior. It lacks error handling details and exact return structure, but overall provides enough context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so thoroughly, documenting all five parameters with their meanings and defaults: file_path, output_path, fillet_radius_mm, wall_thicken_mm, and base_height_mm. This adds significant semantic value beyond the bare types and defaults in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb-resource combination: 'Analyze a mesh for structural risks, then auto-apply fixes.' It further distinguishes itself as 'the one-step design hardening tool' that runs the full analysis pipeline and applies every applicable fix, setting it apart from siblings that likely only analyze or recommend.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you want both analysis and automatic fixes in one step. It also notes what it does NOT do ('Reinforcements that can't be auto-applied (like reorient) are listed in skipped with guidance'), giving context for limitations. However, it does not explicitly name alternatives like analyze_structural_risks or recommend_design_reinforcements, so an agent might not know when to choose those instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool appends manufacturing constraints, printer-fit limits, and material guidance, and that prompt length is optimized per provider. It does not mention return format or side effects, but for a stateless builder, it is fairly transparent about its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized, starting with the core purpose, then usage guidelines, then parameters. Every sentence adds value; there is no redundancy or fluff. It is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters well but lacks explicit mention of return value (e.g., the built prompt string) and does not address error cases or prerequisites. For a tool that outputs a prompt, the omission of return format is a gap given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add meaning. It describes each parameter: requirements (natural language description), material (optional override with example), printer_model (optional with example), provider (optional, controls prompt length budget). These descriptions provide essential semantics beyond bare types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Build a design-aware generation prompt for original 3D creation' and positions it as 'the best pre-generation tool for original designs', clearly identifying the verb (build) and resource (generation prompt) with a specific scope (original designs), distinguishing it from siblings like build_parametric_prompt or improve_generation_prompt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends use for original designs and explains provider-specific length optimization with examples (openscad, meshy, gemini), providing clear context. It does not directly state when not to use it or name alternatives, but the focus on original design implies exclusion of other tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses read-only behavior, specific endpoints, and limitations (hardware_unverified, active_slot_control_supported). This provides solid transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loaded with the purpose and structured logically. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is fairly complete. It explains the mechanism and expected response fields, though the output structure is not fully detailed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so no parameter information is needed. According to guidelines, baseline is 4 for 0 params. The description adds no param info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool discovers Creality CFS/CFS-C status via Moonraker. It distinguishes itself from the sibling tool 'ams_status' by noting it is a counterpart but not equivalent, providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking CFS status and contrasts with ams_status, but does not explicitly state when to use it versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses safety-critical nature, possible blockage by interlocks, requirement for non-empty note, and default operator identity. Could add more on failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Multi-paragraph but well-structured with sections. Every sentence adds value. Slightly verbose but appropriate for safety tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, prerequisite, parameter details, and return description. Lacks output format details or error types, but adequate given safety-critical nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description documents all three parameters: printer_name, acknowledgement_note (required, non-empty), acknowledged_by (optional, default 'operator'). Adds constraints not in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Acknowledge and clear a printer's emergency stop latch' uses a specific verb and resource. It clearly distinguishes from sibling tools like emergency_stop (triggers stop) and emergency_status (checks status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends calling emergency_status() first to check if clearing is possible. References sibling tools. Does not explicitly state when not to use, but the context implies conditions like active interlocks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It reveals the use of a local binary, BOSL2 support, the inline 3D stage side effect, automatic mesh decimation, and the caveat that the PNG preview is not the whole experience. This goes beyond a basic 'compile' statement, though it does not mention failure modes, file cleanup, or permission implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and input modes, followed by a timeout tip and structured Args list. The inline 3D stage paragraph is somewhat long and uses ALL CAPS, but it conveys important behavioral context. Each sentence contributes useful information, though the staging explanation could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the key operational aspects: inputs, compilation process, return value, timeout guidance, and the post-success 3D stage behavior. It is sufficiently complete for an agent to invoke and interpret the result, though error handling and file lifecycle details are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully compensate for parameter meaning. It provides an explicit Args section explaining scad_code and scad_path are mutually exclusive options, and timeout defaults to 300 seconds with a scenario-specific increase to 600+. This adds significant semantic value beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource pair: 'Compile OpenSCAD code into an STL file.' It then details the two input modes (source code or .scad path), the local OpenSCAD binary, and the return value (path to generated STL), making the tool's purpose unmistakable. This clearly distinguishes it from siblings like validate_openscad_code, analyze_scad_code, and tweak_and_compile_scad.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (compiling SCAD to STL) and provides a specific time-based guideline for surface() heightmap operations ('increase timeout to 600+ seconds'). It also explains the OR relationship between scad_code and scad_path, which guides invocation. However, it does not explicitly name alternatives or state when not to use this tool in favor of a sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It implies a read-only check via 'Check' and 'Returns', but does not explicitly state it has no side effects, requires no auth, or is safe. The description adds some clarity about return fields but misses explicit safety disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose ('Check your decoration quota'). Each sentence adds value: purpose, tier policy, return fields. No wasted words; whitespace does not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with no params and no output schema; description fully explains what it returns and the tier context. Provides enough detail for an agent to know when to call and what to expect, without needing additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The description adds valuable semantics beyond the empty schema by explaining the quota system (tier limits) and return fields (used, limit, remaining, tier, month), fully compensating for the absence of parameters and making the tool's purpose and output crystal clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource: 'Check your decoration quota' and explicitly lists what it returns (used count, limit, remaining, tier, month). Distinguishes from sibling decoration tools like decoration_info or list_decorations by focusing solely on quota status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context that it's for checking quota usage, including tier policy (free vs paid). Does not explicitly name alternatives or exclusions, but the scope is obvious and self-contained. Sibling tools like decoration_info might overlap, but no cross-reference is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it is a read-only estimation tool that takes dimensions/materials/print settings and returns time, weight, cost breakdowns. It does not mention side effects (none expected) or auth/rate limits, but covers the return structure well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-organized with clear sections (introduction, methods, multi-material, returns, parameter list). It is front-loaded with the purpose and key differentiator. While concise for 16 parameters, each line adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (16 parameters, multiple input modes, multi-material handling) and missing output schema, the description explains all inputs, return value components (time, weight, cost breakdowns), and usage contexts. It lacks a concrete example but sufficiently covers completeness for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides no parameter descriptions (0% coverage), but the description documents all 16 parameters in the :param block, including defaults, required conditions (e.g., dimensions required if no template), and acceptable formats (e.g., comma-separated materials, fractions summing to 1). This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates print time, cost, and filament usage from dimensions alone, explicitly differentiating it from other estimation tools that require a model file. It emphasizes 'BEFORE generating a model' and contrasts with needing slicing or generation, making its purpose unambiguous among 200+ sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells agents to use this for cost/time/filament questions before committing to a design, and explains the two dimension specification methods (direct or template). It implicitly excludes use when a model file exists, but does not list alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It lists the calculations performed (filament usage, material weight, filament cost, electricity cost, total), which is helpful, but it does not disclose any side effects, permissions required, or error behavior. It adds some context but lacks depth for a read-only analysis tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description begins with a clear purpose statement, followed by a usage note and parameter details. It uses line breaks and is well-structured. However, the parameter descriptions could be slightly more concise; they are repeated from the schema's defaults. Overall, it earns its space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (1 required), no output schema, and no nested objects, the description explains the inputs and the general outputs (cost components). It does not detail return format or error handling, but it sufficiently covers what an agent needs to know to select and invoke the tool correctly, especially with the sibling differentiation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description must add value. It provides detailed explanations for all four parameters, including their purpose, defaults, and units (e.g., 'Cost per kWh in USD', 'Power consumption in watts'). This goes well beyond the schema's type/default information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool estimates the cost of a print job from a G-code file, and explicitly distinguishes it from slice_and_estimate for STL/OBJ files. The verb 'estimate' and resource 'cost' are specific, and sibling differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use (G-code files, already-sliced only) and when not to (STL/OBJ files, suggesting slice_and_estimate instead). This provides clear usage context and an alternative, fully meeting the criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that machine start-up and end are preserved, only per-layer toolpaths for other objects are removed. It explains case-insensitive partial matching. It doesn't cover error cases (object not found) but adequately describes key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose, then behavior details, then parameter explanations. It is concise but not overly terse. Could be slightly more compact, but the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and no output schema, the description covers purpose, usage, behavior, and parameter details. It mentions the return dict contains output path, matched object info, and line counts, compensating for missing output schema. It lacks error handling info but is mostly complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It does so fully: explains that file_path is the input file, object_name supports partial matching, output_dir defaults to same directory as input, plate_number is 1-based. This adds significant meaning beyond the property names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Extract' and resource 'single object's G-code from a multi-object Bambu .gcode.3mf'. It distinguishes from siblings like list_plate_objects (list vs extract) and print_plate_object (print vs extract), 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use list_plate_objects first to see available object names. It explains object matching (case-insensitive, partial names) and plate selection. However, it does not explicitly state when not to use this tool or mention alternatives for extracting multiple objects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It notes that the job is tracked through completion and explains the idempotency_key behavior in detail, which is valuable. However, it does not disclose side effects (e.g., resource consumption, error behaviors) beyond auto-assignment, so full transparency is not achieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a clear overview, a note on auto-assignment, and an Args list. It is moderately verbose but each part adds value; no redundancy. It could be tightened without losing meaning, but is acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It covers the core purpose, key behaviors, and parameter meanings. It lacks details on return values (though no output schema), error conditions, or post-submission workflow beyond 'tracks through completion'. This is sufficient for most use cases but not exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All five parameters are described: file_path, printer_name (auto-routes if None), material (required), priority (values listed), and idempotency_key (purpose and retry semantics). This adds meaning far beyond the schema's type-only definitions, achieving full coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Submit a print job to the fleet orchestrator' and elaborates on auto-assignment, making it distinct from simple submit tools. It clearly differentiates via 'fleet' and 'auto-assign' behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (for fleet submission, especially when no specific printer is required) but does not explicitly compare with alternatives like 'submit_job' or 'start_print'. The auto-assign note gives context, but explicit when-to-use vs. other tools is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the output ('one top-ranked alternative') but does not explicitly disclose whether the operation is read-only, requires permissions, or has any side effects. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus an args line. Every sentence adds useful information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the essential aspects: what it does, when to use it, and the parameter. It could mention the return format more explicitly, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It provides examples ('PLA', 'PETG') and clarifies the parameter's purpose, which adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the single best substitute for a filament material. It uses a specific verb ('Get') and resource ('best material substitute'), and explicitly distinguishes itself from the sibling tool 'find_material_substitute'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance ('quick shortcut') and when-not-to-use by mentioning the alternative 'find_material_substitute' for a full ranked list with trade-off details and filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses that the tool returns the material set via set_material, not a live sensor reading. It transparently indicates the source and behavior, though it does not cover potential error conditions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the purpose, and efficiently structured. Every sentence adds value: the purpose, the return value note, the alternative tool reference, and the parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with no output schema and no annotations, the description adequately covers purpose, parameter usage, and suggests an alternative. It is mostly complete, but lacks detail on the return structure or format, which could be inferred but is not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for the printer_name parameter, specifying it targets a printer and defaults if omitted. This fully covers the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets material loaded in a printer from Kiln's software tracker, distinguishing it from get_active_material for live AMS hardware reading. The verb+resource is specific, and the sibling differentiation is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool versus get_active_material for live hardware reading. It also explains the printer_name parameter usage, though it lacks explicit exclusions for cases where the tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully convey behavior. It discloses that the operation is non-destructive (examines, returns), covers all material types, and sorts results by urgency. It does not mention any destructive side effects, auth requirements, or rate limits, but the read-only nature is clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences. The first sentence provides a clear, front-loaded purpose. The second adds necessary detail about scope and sorting. Every word serves a purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 adequately covers what the tool does and the nature of its output (restock suggestions with purchase links, sorted by urgency). It could be more specific about the output format, but it is sufficient for an AI agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so no additional parameter information is needed. Per guidelines, baseline for 0 params is 4. The description adds no param info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'find', 'examines', and 'returns', and the resource 'materials running low' in inventory. It explicitly says it returns restock suggestions for materials projected to run out within 30 days, sorted by urgency. This distinguishes it from sibling tools like 'forecast_material_consumption' or 'list_materials'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use: to get restock suggestions for materials running low. It provides context by stating it examines all material types and returns suggestions for those running out in 30 days. However, it does not explicitly mention when not to use or list alternatives, slightly reducing score from 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description shoulders full responsibility for behavioral disclosure. It explains the return values (x, y, z, possibly e) and the error condition when unsupported. It does not mention side effects, implying read-only behavior, which is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence followed by detailed return info and usage contexts. It is slightly verbose but front-loads the key purpose. Could be more concise in the return description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully covers the return format (dict with x, y, z, optionally e) and the error case. It also explains units and calibration prerequisites, 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the parameter semantics dimension has a baseline of 4. The description adds value by detailing the returned coordinate keys and units, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the nozzle/tool-head XYZ position, using specific verbs and resource references. It distinguishes itself from sibling tools by being a simple positional query, unlike many other tools that perform actions or analyses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists when to use the tool (verifying homing, calibration, move planning) and notes that not all adapters support it, implying when not to use. However, it does not explicitly compare to alternative tools for positional data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the sanity gate logic, refusal behavior on failure, and the effect of setting enforce_sanity=False. It does not mention potential side effects like logging, but covers the core behavioral traits comprehensively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with paragraphs and an Args section, but is somewhat lengthy. Every sentence contributes value, and it front-loads the purpose effectively, though minor trimming could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema, the description adequately explains all parameters and behavior (sanity gate, failure mode). It references response fields like 'improved_prompt.sanity' but could elaborate on the exact output structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description adds essential meaning for all 8 parameters, including context for file_path, enforce_sanity, and iteration. The Args block explains each parameter's role, greatly exceeding the schema's minimal info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool generates an improved prompt from feedback, adding physical constraints for printability without altering creative intent. It distinguishes itself from siblings like 'build_generation_prompt' by specifying it improves an existing prompt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to improve a prompt with feedback) and how to handle the sanity gate via the enforce_sanity parameter. It lacks explicit 'when not to use' guidance but provides clear context for its application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description handles behavioral disclosure. It states it returns distinct sites from registered printers and requires a license, but doesn't mention data freshness, pagination, or side effects. Given it's a simple read-only list, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, and each sentence provides essential information: action, return details, and usage/license. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 complete enough. It covers what the tool does, what it returns, and a usage scenario. Minor missing detail: whether results are sorted or paginated, but for a simple list this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline 4 applies. The description adds value by specifying the output includes 'printer counts' and 'distinct sites', which is not present in the schema (no output schema).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all fleet sites with printer counts, using a specific verb and resource. It distinguishes itself from sibling tools like fleet_status_by_site by focusing on site listing with counts, and explicitly mentions usefulness for multi-site dashboards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context, noting the tool is for multi-site dashboards and requires an Enterprise license. However, it does not explicitly compare to alternatives or state when not to use it, though the sibling tools suggest more detailed status queries exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosure. It transparently explains the return behavior: as-shipped limits alongside each variant's limits, and an empty variants map for unverified machines. It does not explicitly state read-only or side-effect-free behavior, but the 'Show' verb and content imply it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multi-paragraph and somewhat verbose, but all content serves a purpose: defining 'curated profile', 'variant', and the return semantics. The Args section is clearly formatted. Could be tightened, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and no annotations, the description fully covers the tool's behavior, the meaning of variants, and the empty-map edge case. It is complete enough for an agent to confidently invoke the tool with a printer identifier and interpret the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, printer_model, is described with a concrete example ('ender3'), adding meaning beyond the bare schema type. While format and validation rules are not specified, the example sufficiently clarifies the expected identifier format for a simple single-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence uses a specific verb ('Show') and resource ('curated hardware variants available for a printer'), clearly distinguishing this listing operation from related tools like select_printer_variant. The detailed explanation of what constitutes a variant further cements the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when variants exist (after Kiln verifies a documented hardware change) and notes that an empty map is the honest answer when no variants exist. However, it does not explicitly contrast with alternative tools or state when NOT to use this tool, so it falls short of full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the probe is 'lightweight' and an 'empty search,' giving insight into its non-intrusive nature. It also clarifies it 'reports which ones are reachable,' indicating read-only behavior. Minor omissions include output format details, but it is sufficient for a zero-parameter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with the primary action. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description adequately covers the tool's function and use case. It explains the mechanism (empty search) and purpose (debugging downloads). It does not elaborate on output format, but this is acceptable for a simple diagnostic tool with no structured output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is effectively 100% (no parameters to describe). Per guidelines, the baseline for 0 parameters is 4, and the description adds no unnecessary parameter info, remaining correct and clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run connectivity checks against all configured marketplaces' with a specific verb and resource. It distinguishes itself from siblings by focusing on marketplace reachability via a lightweight probe, which is unique among the listed tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates usage context with 'Useful for debugging download failures,' providing clear when-to-use guidance. However, it does not explicitly mention alternatives or when not to use this tool, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It details key behaviors: automatic grid arrangement, slicer selection (PrusaSlicer with --duplicate flag, fallback to OrcaSlicer), and prerequisites. It does not cover failure modes or side effects (e.g., file creation), but covers core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise opening sentence, followed by behavioral details, then a labeled parameter list. It is slightly longer than necessary but every sentence adds value. A bulleted or more compact format could improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately covers inputs, process, and prerequisites. It lacks explicit mention of return value (e.g., job ID or success status) and error handling, but for a print action tool, the core flow is sufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description fully compensates by explaining each parameter's purpose, including format (e.g., STL, OBJ), range (copies 2-20), default (spacing 10mm), and nullable fields. This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: printing multiple copies of a model on one build plate with automatic arrangement. It distinguishes itself by detailing the slicer-specific behavior and fallback mechanism, making it distinct from siblings like 'multi_color_copies' or 'arrange_parts_on_plate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: when multiple copies are needed, with prerequisites (slicer installed, printer idle and connected). However, it does not explicitly mention when not to use this tool or list alternative tools for similar tasks, though the specificity of the tool makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does disclose it is a compound workflow running preflight checks, but does not mention side effects like filament usage, print cancellation, or error handling. It states it performs extraction, upload, and start, but lacks deeper behavioral details such as failure modes or prerequisites beyond file existence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear numbered list, parameter documentation, and examples. It is comprehensive but not verbose, with each section adding value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (compound workflow, 10 parameters), the description covers the pipeline, matching rules, and key parameters. No output schema exists, but it mentions return value. It lacks details on failure scenarios or interaction with printer availability, but is largely complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carries the burden. It explains plate_number (1-based), use_ams allowed values, bed_type allowed values, and ams_mapping example. Most parameters are documented, though some like flow_cali and bed_leveling are only mentioned inline without detailed semantics beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts a single object from a multi-object .gcode.3mf and prints it, with a compound workflow. It distinguishes itself from siblings like extract_plate_object and start_print by explaining it combines those steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use list_plate_objects first to preview available objects, and explains plate selection and partial name matching. It also mentions that printer_name aims both steps at the same machine, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It transparently describes the analysis process and output format (dict with reinforcements list), including specific coordinate locations and tool suggestions. However, it does not mention any side effects, permissions, or potential destructive actions, though it appears to be a read-only analysis.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief introductory sentence, a bulleted list of reinforcement types, and a docstring for parameters. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only two simple parameters, the description provides complete context: it explains the tool's purpose, input parameters, output format (dict with reinforcements list), and the nature of recommendations. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by explicitly describing both parameters in a docstring format ('file_path: Path to the STL file' and 'min_cross_section_mm2: Minimum safe cross-section area'), adding meaning beyond the schema's minimal type information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Recommend specific reinforcements for an STL mesh.' It lists five distinct reinforcement types with their benefits, and distinguishes itself from sibling tools like apply_design_reinforcements (which applies) and analyze_structural_risks (which only analyzes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after analyzing geometry to find structural risks, but it does not explicitly state when to use this tool versus alternatives (e.g., analyze_structural_risks vs apply_design_reinforcements). No exclusions or context for when not to use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden. It discloses the persistence side effect ('Saves the model fingerprint...'), explains the cross-user learning purpose, and highlights a significant consequence: omitting `geometric_signature_v2` permanently stores the row with the older key and prevents later separation from another design. It stops short of describing the return value or error behavior, but the core behavioral impact is covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but the tool has 15 parameters so a detailed Args block is justified. The one-sentence summary and prerequisite are front-loaded, and each parameter line adds semantic value. The `geometric_signature_v2` paragraph is somewhat lengthy but necessary because it explains a non-obvious data-integrity consequence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 15-parameter tool with no output schema and no annotations, this description is unusually complete: it defines every input, names the prerequisite tool, explains the persistence side effect, and calls out the v2-signature pitfall. The main gaps are the absence of a described return value and no detail about the expected structure inside the `settings` dict.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero property descriptions and no enums, so the description is the only source of parameter semantics. It explains units (`surface_area_mm2`, `volume_mm3`), ranges (`overhang_ratio`, `complexity_score`), valid values (`success`, `failed`, `partial`, grades `A`-`F`), defaults, and the especially important meaning of `geometric_signature_v2`. This fully compensates for the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Record a print outcome with full model DNA.' It then clarifies the distinguishing feature—saving the model fingerprint for cross-user learning—which separates it from simpler sibling tools like `record_print_outcome` or `record_recovery_check`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit prerequisite: 'Use fingerprint_model first to compute the fingerprint fields.' This tells the agent when to use the tool in a workflow. It does not state when not to use it or explicitly name alternatives, but the fingerprint-first instruction provides clear operational guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses key behavioral traits: automatic subtraction of included printers, reporting to Stripe's active_printers meter at $15 each, and auto-detection of printer count when omitted. It does not cover error cases or authentication needs, but the core behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with sections for general description, parameter details, and an example. Every sentence adds value, though the example could be slightly more concise. Overall, it is efficient and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description covers business logic, parameter behavior, and provides an example. It lacks explicit details on return values or error handling, but the effect of the tool (reporting to Stripe) is clearly explained. The description is fairly complete for its context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that explains both parameters in detail: subscription_item_id (Stripe format si_...) and active_printer_count (optional, auto-detect when empty). Since schema description coverage is 0%, the description fully compensates by adding meaningful context and usage guidance for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports metered printer usage to Stripe for Enterprise billing. It uses a specific verb (report) and resource (printer overage), and the automatic subtraction of 50 printers distinguishes it from sibling tools, none of which perform billing reporting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the Enterprise context, that the first 50 printers are included, and how the tool automatically subtracts the included quantity. It also provides an example. It does not explicitly state when not to use it, but the use case is clear and no alternative tools are named, which is acceptable given the uniqueness of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description adds that the operation is by component and requires a known rollback version, but does not explicitly state destructive nature or other side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise: front-loaded with purpose, then alternative usage, prerequisites, and parameter description in an Args section. No redundant language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single required parameter and no output schema, the description covers purpose, alternative, prerequisite, and parameter meaning. Lacks return value details, but adequate for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds value by explaining the 'component' parameter and giving an example ('klipper'), which the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rolls back firmware on the default/connected printer by component, which is specific and distinct from the sibling tool rollback_printer_firmware for fleet setups.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly names the alternative tool for fleet setups, states compatibility (Moonraker printers), and requires a known rollback version, guiding correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden — and it delivers. It reveals the 3D stage inline viewer side effect, automatic decimation of oversized meshes, the return dict structure (output_path, rotations_applied), and the output_path default naming convention. This goes well beyond minimal disclosure by flagging that the PNG preview is not the whole experience and that a browser stage link is used for hosts without MCP Apps panel support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections: purpose, use case, Args, Returns, and pairing recommendation. It's front-loaded with the purpose statement. The 3D stage paragraph is slightly verbose — 'in hosts that render MCP Apps panels (Kiln's hosted connection attaches a browser stage link for hosts that don't)' could be tightened — but every sentence contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and no output schema, the description is remarkably complete: input formats, all parameter semantics, return dict, default behaviors, and side effects are covered. The only minor gap is that it doesn't explicitly confirm the original file is left unmodified (non-destructive), which is implied by 'save the rotated file' but not stated — an important detail for a mutation-adjacent tool with zero annotation safety hints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate — and it does, documenting all 5 parameters. Each rotation axis gets units and context ('rotation_z: ... most common — rotates on the build plate'), input_path specifies valid file types (STL or 3MF), and output_path explains the default naming pattern `<input>_rotated.<ext>`. The description is the complete source of parameter truth.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Rotate a 3D model file (STL or 3MF) by specified angles before slicing.' It clearly identifies what the tool does and distinguishes it from siblings like auto_orient_model, optimize_print_orientation, and rescale_model by emphasizing manual angle specification. The concrete use case (reducing toolhead-induced wobble by rotating 45° around Z) reinforces purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Useful for improving print quality — rotating a tall narrow part 45° around the Z axis can reduce toolhead-induced wobble and ringing artifacts.' It explicitly names a companion tool to pair with ('Pair with reslice_with_overrides') and explains the scenario for using it. However, it doesn't explicitly state when NOT to use it versus alternatives like auto_orient_model, though the manual-angle specificity implicitly creates that boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It goes above and beyond by detailing the interactive 3D stage side effect, decimation of oversized meshes, and the fallback which behavior, plus the return dict. It does miss some side-effect warnings like the fact that it can overwrite the input file if no output_path is given (only mentioned in the param docstring, not in the main text) and doesn't discuss permission or error cases, but this is rich context for a complex tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by param docs and then a longer side note about the 3D stage. The 3D stage paragraph is thorough but slightly long; it could be condensed while retaining the key points. However, it is well-structured and every sentence adds value, justifying a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 6 parameters, a mutating action (potentially overwriting input), and an unusual side effect (opening a 3D stage), the description covers all the bases: parameters, return value, and side effects. It doesn't explain what happens if both printer_id and explicit dimensions are provided (i.e., precedence), but given the complexity is high, the description is impressively complete for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, and it does. Each parameter is documented in the docstring: file_path (path to mesh), max_*_mm (build volume dimensions), printer_id (optional printer model to supply build volume), and output_path (defaults to overwriting input). It also explains the return value. This is exactly what the agent needs to invoke the tool correctly, especially noting the interaction between printer_id and the explicit dimension parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear and specific action: 'Auto-scale a mesh to fit within a build volume while maintaining aspect ratio.' It uses a specific verb (auto-scale), resource (mesh), and context (fit within a build volume). It also explains when it's useful ('when a model is too large for your printer') and includes the key behavior ('uniformly shrinks it to the largest size that fits'), which differentiates it from siblings like rescale_model or auto_orient_model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('Useful when a model is too large for your printer') and clarifies that it shrinks the model, implying it's the right choice for size-constrained printing. However, it does not explicitly contrast with alternative tools (e.g., rescale_model or validate_and_prepare_mesh) or provide 'when not to use' guidance. Clear usage context is present, but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses pagination parameters (page, per_page with default and max), sort options, and the return format (list of model summaries with specific fields). It lacks mention of rate limits or authentication, but for a search tool with no annotations, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, a structured argument list, and a one-sentence return description. It is front-loaded and efficient, though slightly verbose with the Args: formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple search with 4 parameters and no output schema, the description covers the purpose, parameters, and return format adequately. It also provides related tools for deeper inspection. It is sufficiently complete for an AI agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries full burden. It explains all four parameters: query (keywords with examples), page (1-based), per_page (default 10, max 100), sort (four allowed values). This adds significant meaning beyond the bare schema, enabling correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches Thingiverse for 3D-printable models with a specific verb (Search) and resource (Thingiverse 3D-printable models). It distinguishes itself by referencing sister tools (model_details, model_files) for next steps, and context from sibling names (like search_all_models) implies a focused scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use for searching Thingiverse models, and then use model_details or model_files for further details. It does not explicitly exclude alternatives like browse_models or search_all_models, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It accurately describes a safe read operation returning country codes and names, with no hidden side effects. The description is transparent about what the tool does, though it could mention if the list is static or dynamic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and followed by specifics. No extraneous text; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is fairly complete: it states the purpose, return values, and context. It does not mention prerequisites or dynamic behavior, but for a simple list tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info (unnecessary) and meets the baseline of 4 for parameter-less tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists countries supported for fulfillment shipping, specifies returned data (ISO codes, full names) and scope (23+ countries, Kiln fulfillment). It distinguishes well from sibling tools by focusing on shipping countries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly makes the tool's use obvious but lacks explicit guidance on when to use versus alternatives. However, no similar sibling exists that could be confused, so the lack of explicit exclusions is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses geometry-level modification, vertex offsetting along averaged normals, automatic decimation for the viewer, and the inline 3D stage side effect. It does not explicitly state whether the original STL file is left untouched, though the output_path default implies a new file is written.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a one-sentence purpose, followed by concise method, usage, parameter, and return details. The inline 3D stage block is long but earns its place as important behavioral context. It is slightly verbose in the stage explanation but remains well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description robustly covers params, return values, usage timing, and side effects. It is strong for a geometry-editing tool, but minor gaps remain around input file preservation and failure/error behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully documents all three parameters: file_path, amount_mm with default and unit, and output_path with default behavior. It also summarizes the return dict contents, adding meaning well beyond the bare input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Thicken thin walls in a mesh by offsetting vertices outward.' This clearly distinguishes it from sibling mesh operations like repair_mesh, hollow_mesh_model, or add_mesh_fillet. The phrase 'geometry-level fix' further reinforces the tool's specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use after predict_print_failures() detects thin_walls or after design_scorecard() flags wall thickness issues.' This gives clear context and names upstream tools, though it does not enumerate exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool compiles code without generating geometry and returns structured error/warning information with line numbers. This adequately discloses the behavior for a validation tool, though it omits potential side effects (likely none) or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences in the main part followed by a docstring. Every sentence adds value, and the purpose is front-loaded. No redundant or missing words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with no output schema, the description adequately covers input (code) and output (dict with valid, errors, warnings). It lacks details on edge cases or performance, but the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description includes a docstring for the 'code' parameter, specifying it is OpenSCAD source code to validate. This adds meaning beyond the schema's type-only definition, though it lacks details on format or length constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates OpenSCAD code without generating geometry, with a specific verb (validate) and resource (OpenSCAD code). It distinguishes itself from the sibling tool generate_model by suggesting its use before calling that function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: 'Use this to check code before calling generate_model with OpenSCAD.' It does not provide explicit when-not-to-use or alternatives, but the context is clear enough for an AI agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It details the internal steps (design briefing, mesh validation, etc.) and indicates the output is a single report. It does not mention side effects like file modification, but given the audit nature, it is likely read-only. The description adds significant context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient: a clear overview, a usage sentence, and a structured parameter list. Every sentence adds value, and the structure is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no output schema, the description explains inputs and the nature of the output (a report answering readiness). However, it lacks details on the report format (structured vs. text) and does not specify if the tool modifies any files. Still, it covers the essential functionality well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description's 'Args' section adds meaningful descriptions for all 10 parameters, including examples (e.g., 'petg', 'bambu_a1') and units (e.g., degrees for max_overhang_angle). The input schema only provides types and defaults, so the description enriches understanding substantially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run a ruthless audit of an original design before printing.' It lists the specific aspects combined into a report and answers a precise question. No other sibling tool has an identical purpose; this is a comprehensive audit distinct from more focused analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'after generating or modeling a new part.' It also frames the question the tool answers. However, it does not mention when not to use it or provide alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that commands are sent automatically and lists options, but does not describe potential side effects, error conditions, or the tool's return value. It mentions a key precondition (printer idle) but lacks depth on what changes occur on the printer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and bullet points, starting with the core purpose. Every sentence adds value without redundancy, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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 covers purpose, usage, and parameter semantics well. However, it omits information about the tool's return value or success/failure indication, which would be useful for an agent to handle the result correctly. Overall, it is complete for basic invocation but slightly lacking in post-invocation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'options' has no schema description (0% coverage), but the description thoroughly explains the allowed values (bed_leveling, vibration, flow, all), default behavior (bed leveling only), and printer-specific support. This fully compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sends calibration commands directly to the printer adapter, distinguishing it from the sibling run_calibrate which is a full pipeline. It specifies the method (MQTT or G-code) and lists available options, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use calibrate_direct vs run_calibrate, states the printer must be idle, and details printer-specific support for options. This provides clear context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the reading and warning behavior and emphasizes local data processing. Without annotations, this carries the transparency burden and does so well, though it omits what happens if no warning (likely just success).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using bullet points for clarity, and each sentence adds value. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameter semantics, and key behavioral aspects. However, it does not specify the output format or return value, which would be helpful given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides examples of valid materials and explains the behavior when material is null, which the schema does not. This fully compensates for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states its purpose: checking chamber temperature safety for a given material, with specific examples of warnings. It is distinct from sibling tools like 'check_material_environment' by focusing on temperature limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to provide a material vs without, and notes that checks are local. However, it does not explicitly state when to prefer this tool over alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the return structure (dict with backends, availability, priority, install_help, remedy) and how to use the results (prefer remedy). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured. Each sentence adds value: purpose, return details, conditional fields, usage guidance. No fluff, and front-loaded with main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description adequately explains return values and their interpretation. Given no parameters and clear workflow integration, the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. With 0 parameters, baseline is 4. Description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose with a specific verb ('Check') and resource ('STEP import backends available on this system'). It distinguishes itself from sibling tools like import_step_file by indicating this is a prerequisite check.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call before import_step_file to verify readiness. Provides guidance on interpreting the remedy field, especially the actionable_by_caller flag. No explicit alternatives mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the destructive nature (permanent deletion of expired entries) and the return value (count of removed entries). It does not require further behavioral details for this simple operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each adding value. Front-loaded with the core action, followed by details and return type. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully explains the action, permanence, and return value. It is complete for an agent to understand and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no param info, which is acceptable. Baseline 4 applies per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool removes expired agent memory entries, using specific verbs like 'Remove' and 'permanently deleted'. It distinguishes from sibling tools like delete_agent_note by targeting all expired entries rather than a specific note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (clean up expired memory) but does not explicitly state when not to use or mention alternative tools for specific deletions. Context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses what the tool reports (SQLite/PostgreSQL, connection status, key metrics) and requires an Enterprise license. No annotations provided, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a license note, front-loaded with purpose and actionable context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fully adequate for a zero-parameter, read-only tool. Covers purpose, reported info, use cases, and licensing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100% (empty). The description adds no parameter info, but baseline for zero-param tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Check') and resource ('database backend status and configuration'), clearly distinguishing it from sibling tools like health_check or kiln_health by focusing on database details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'Useful for verifying a PostgreSQL migration or diagnosing connectivity issues.' Does not explicitly state when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Explains the analysis process and what recommendations it provides. It is a read-only analysis, and the description makes that clear without needing further annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Short, front-loaded with purpose, followed by a clear list of outputs and parameter descriptions. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description fully covers what the tool does, what inputs it expects, and what it returns. It also guides the agent on when to call it. Appropriate for a triage tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% in formal sense, but the description includes inline parameter docs explaining each field (prompt, printer_model, material). This adds meaning beyond the bare schema titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it is a triage tool to ask which generation method to use, and lists specific outputs (approach, template, materials, constraints, complexity). Differentiates itself by saying 'call FIRST', which positions it ahead of generation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Tells agent to call this tool first, implying it should be used before generation tools. Does not explicitly state when not to use or list alternatives, but the context is clear enough for sequencing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool returns wallet addresses and is for donations only. No side effects are mentioned, but for a read-only info tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences, front-loading the key action. Every sentence adds value: first states purpose, second explains context, third clarifies optionality. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple purpose, the description is complete. It fully explains what the tool does, what it returns, and the context for its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds meaning by explaining the context and what the returned data represents (wallet addresses for various tokens), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: getting crypto wallet addresses for donations to the Kiln project. It uses specific verb 'get' and resource 'crypto wallet addresses', and it distinguishes from sibling tools (like printing or design tools) by its donation focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool: for optional donations. It explicitly states that no payment is required and that the software is fully functional without donating, guiding the agent on appropriate usage. However, it does not mention alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains return value (low/high range based on typical pricing) and calculation method. Lacks details on auth, rate limits, or caching, but sufficient for a simple estimation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, parameter list, and return info. Clear but slightly verbose; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description is complete: explains parameters, constraints, return type, and differentiation from sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains all parameters: technology options, volume vs. dimensions, quantity default, and the mutual exclusivity constraint. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get an instant price estimate' with specific verb and resource, and distinguishes from sibling tool 'fulfillment_quote'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (before full quote) and when not (for exact pricing, use fulfillment_quote). Also provides required parameter constraint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that weight requires a material density from a filament profile, that bundled profiles lack filament names, and that a missing key means the slicer could not answer rather than zero. This is valuable behavioral context beyond the schema. It doesn't mention side effects or permissions, but for a read-only estimation tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bolded key terms, and a See also pointer. It's a bit long but every sentence adds value—no fluff. The param list is compact and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema, no annotations), the description covers the key behaviors: slicing vs parsing, material density caveat, and return value semantics. It doesn't describe the exact return structure, but the description says 'Dict with time, filament, and layer estimates' which is sufficient for an agent. It could mention error cases, but overall it's complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 each parameter: file_path accepts STL/3MF/OBJ or .gcode, profile is optional slicer profile path, printer_id is for bundled profiles with an example, slicer_path is explicit binary path, and material is used only as density source. This adds meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates print time and filament usage by slicing a model and parsing G-code. It distinguishes itself from siblings like estimate_material_cost and slice_and_estimate by explicitly naming them and noting the difference in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool vs alternatives: it mentions passing .gcode files directly for already-sliced files, and points to estimate_material_cost for weight/cost from a mesh and slice_and_estimate for fuller analysis with printability scoring. This is clear when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states it parses headers 'without re-slicing', which implies a read-only, non-destructive operation. It also lists the metadata points extracted (time, layer count, etc.). With no annotations, this provides sufficient behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using bullet points for formats and a note for a sibling tool. Every sentence adds value without repetition. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and no output schema, the description covers all essential aspects: supported file types, the nature of the operation (no re-slicing), extracted metadata fields, and a cross-reference to a related tool. It is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The `file_path` parameter is described in the docstring as 'Path to the print file.' This adds meaning beyond the schema, which only has a type and title. For a single parameter, the description is adequate but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts metadata from 3D printing files and lists specific formats (.gcode, .3mf, .stl, .ufp). It distinguishes from the sibling tool `list_plate_objects()` via the note, which helps an agent differentiate use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a note that for multi-object .gcode.3mf files, also consider using `list_plate_objects()`, which provides alternative tool guidance. However, it doesn't explicitly state when not to use this tool or list other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the transparency burden and does a strong job: it explains the ZIP/XML parsing, merging behavior, output as binary STL, and the side effect of opening an interactive 3D stage with automatic mesh decimation. It could still note overwrite behavior and permissions, but it reveals significant behavioral detail beyond the bare operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a lead sentence, a clarifying note, parameter blocks, returns, and a side-effect paragraph. It is somewhat long but each section contributes useful context. The 'PNG preview is the floor' phrasing is a bit cryptic, but overall the organization helps scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with no output schema and no annotations, the description is remarkably complete: it covers input formats, multi-object merging, output type, return contents, scenarios for alternative tools, and a notable UI side effect. It lacks error-condition details but is otherwise sufficient for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by documenting both parameters: file_path with accepted file extensions and output_path with auto-generation semantics. This is meaningful guidance beyond the bare schema, though the auto-generated path naming is not elaborated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Extract the embedded 3D model from a .3mf or .gcode.3mf file to STL." It clearly defines the tool's scope (standard 3MF and Bambu .gcode.3mf) and distinguishes it from the sibling extract_plate_object, explicitly noting that the sibling should be used for extracting single objects' G-code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage guidance is explicit: the note says to use extract_plate_object for single-object G-code extraction and list_plate_objects to discover available objects. It also states that multi-object files are merged into a single STL, which sets clear expectations for when this tool is appropriate versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral details: expired entries are automatically filtered out, and each entry includes a version field. It does not explicitly state if the operation is read-only or if there are side effects, but as a retrieval tool, the behavior is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences for purpose and context, followed by a list of parameters. Every sentence provides value, and the key usage instruction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's purpose (retrieve agent memory), the description adequately covers what it does and how to filter. However, without an output schema, it could provide more detail on the structure of returned memory entries. The mention of a 'version' field is helpful but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for missing parameter details. It explains both parameters clearly: printer_name for printer-specific memory, and scope with an example ('global', 'fleet'). This adds significant meaning beyond the schema's type-only definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Retrieve all stored agent memory for context.' It specifies the resource (agent memory) and provides context on when to use it (at the start of a session) and what it contains (printers, materials, past outcomes). This distinguishes it from sibling tools like clean_agent_memory or save_agent_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides the agent to call this 'at the start of a session' to recall learned information, which is a clear usage scenario. However, it does not mention alternative tools or cases when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It explains the return value (autonomy level and constraints) and implies no side effects (read-only). This is adequate disclosure for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a usage suggestion. Every word earns its place, no fluff. It is front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and a simple return, the description fully explains what the tool does and when to use it. There is no output schema, but the description sufficiently covers the return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters and schema coverage is 100%, so the description does not need to add parameter details. Per calibration, 0 params baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return the current autonomy tier and constraints.' It specifies the exact outputs (autonomy level and Level 1 constraints). The sibling set includes 'set_autonomy_level' and 'check_autonomy', so this tool is unambiguously the getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this early in a session to understand how much freedom you have,' providing clear when-to-use guidance. It does not explicitly mention when not to use it or alternatives, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool returns status data (versions, uptime, etc.) and implies a read-only operation. It does not mention side effects, authorization, or potential performance impact, but for a health check, the behavioral traits are sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose ('Get a health check...') followed by a concise list of returned data and a usage note. Every sentence is informative and without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple health check tool with no output schema, the description adequately covers what the tool does, what it returns, and when to use it. It is complete within the context of its simplicity and the absence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage (trivially). Per guidelines, 0 parameters results in a baseline score of 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a health check for the Kiln system'. It lists specific return values (versions, uptime, module availability, scheduler status, webhook status, overall system health), distinguishing it from sibling tools like 'health_check' or 'check_printer_health' by targeting the Kiln system specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use this to verify the system is running correctly.' However, it does not explicitly exclude alternative tools or provide when-not-to-use guidance, which would elevate the score to 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that details returned include name, description, styles, and API key requirement. This gives good insight into the tool's behavior, though it could mention if the tool is read-only or has any 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded: first sentence states purpose, second sentence adds detail. No wasted words, highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 0 parameters and no output schema, the description fully explains what the tool does, what it returns, and when to use it. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, so schema coverage is 100%. Description does not need to add parameter information; baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List available text-to-3D generation providers.' It specifies the resource (generation providers) and action (list), differentiating it from other list tools among siblings. The mention of using it before generate_model provides additional context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to use this before calling generate_model, providing a clear context. However, it does not mention when not to use it or alternative tools, though the simplicity of the tool makes exclusions less necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the tool lists categories (read-only behavior) and returns names and slugs. No side effects or permissions mentioned, but the operation is inherently safe and simple.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core purpose. Every word serves a purpose, no fluff. The structure efficiently conveys purpose, output, and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is fully complete. It covers what the tool does, what it returns, and how to use the output with a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description adds value by explaining the purpose of the output (slugs for browse_models), which goes beyond the schema. Baseline 3 is exceeded.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'Thingiverse content categories'. It distinguishes from siblings like browse_models by explaining that the returned slugs are used as input for that tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool: to get category slugs for use with browse_models. It does not exclude other uses, but the context is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool manages team seats and role assignments, and enumerates possible actions and roles. No contradictory behaviors are stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—two sentences and a clean bullet-style args section. Every sentence adds value, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention the return value (e.g., success message or updated member list), but the tool's purpose is clear enough for most use cases. No annotations exist to provide additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully compensates by listing allowed values for 'action' and 'role', and explaining that 'email' is ignored for the 'list' action. This is more informative than schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Add, remove, or update a team member') and specifies the resource ('team member'). It distinguishes itself from siblings by being a dedicated team management tool, with no similar sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('Enterprise feature') and seat limits for Business and Enterprise tiers, helping the agent decide when to use it. It doesn't explicitly name alternatives, but sibling tools are unrelated, so this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: the operation is simple concatenation (no positioning logic), and it opens an interactive 3D stage on success, with automatic decimation of oversized meshes for display. This goes beyond the basic operation and manages expectations about the inline viewer and preview behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: it opens with a clear one-line summary, immediately provides usage guidance, then lists the parameters in a compact docstring format, and ends with an explanatory note about the 3D stage. It is mostly front-loaded with the most critical info (what it does and when to use an alternative). The note about the 3D stage is a bit verbose but adds useful context about a side effect that could surprise the user.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description mentions that the tool returns a dict with merge statistics, which covers the return value. It also explains the side effect (opening the 3D stage) and notes that oversized meshes are decimated. The description covers the tool's core purpose, parameters, alternatives, and side effects. It could mention error handling or file format limitations, but for a relatively simple concatenation tool, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 2 parameters with 0% description coverage, meaning the schema only provides type information (array of strings, string) without descriptions. The description adds a sentence listing `file_paths` and `output_path` and explains their roles ('List of STL file paths to merge', 'Destination path for the merged file'). This is basic but adequate; it doesn't add details like accepted formats, file size limits, or path resolution rules. The description does not fully compensate for the schema's lack of detail, so a baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Combine multiple STL files into a single mesh file (simple concatenation)'. It uses a specific verb (Combine), resource (STL files), and clarifies the scope (simple concatenation). It also distinguishes itself from the sibling tool `merge_stl`, which handles positioning with x/y/z offsets. This is a precise, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly guides usage: 'For positioning parts with x/y/z offsets, use ``merge_stl`` instead.' This directly points to an alternative tool and clarifies when not to use this one. It also adds context that this is useful for 'composing multi-part designs into one printable file', giving a clear use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the batched merge strategy, tool change commands, and output contents. It discloses the precondition and limitation about XY overlap. It doesn't mention destructiveness or authentication needs, but for a file merge tool, the behavior is well explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold preconditions, a clear example, and sections. The description is front-loaded with purpose and strategy. Every sentence adds value without redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior, parameters, preconditions, output, and relationship to sibling tool wrap_gcode_as_3mf. Lacks error handling or edge cases, but for a file merge tool with no output schema and no annotations, it is remarkably thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. The Args section thoroughly explains both parameters: parts (JSON array with required fields gcode_path, tool_index, name, including an example) and output_path (default behavior). It adds meaning far beyond the schema's property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges separately-sliced gcode files into one multi-tool gcode, with a specific batched strategy for multi-color prints. It distinguishes itself from sibling tools like wrap_gcode_as_3mf by describing this as the key intermediate step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the use case (between slicing and 3MF wrapping) and preconditions (XY-disjoint parts). It warns about overlapping XY regions causing collisions, providing clear when-not-to-use guidance. However, it does not list alternative tools or scenarios where this tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It states that the tool returns comprehensive metadata including description, instructions, license, tags, and file count. It does not disclose if it's read-only or any side effects, but for a data retrieval tool this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two short paragraphs. The first line gives the summary, and the second adds parameter details and output content. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, parameter source, and output content. It does not mention return format or error handling, but it is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter thing_id is described as 'Numeric thing ID (from search_models results)', which adds essential context beyond the schema type and requirement. It tells the agent where to obtain the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get full details for a Thingiverse model' with a specific verb and resource. It distinguishes from sibling tools like search_models by specifying that it uses a numeric thing_id from search results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage pattern: use thing_id from search_models results. It does not explicitly contrast with other model-related siblings like model_files or get_cached_model, but the guidance is sufficient for the primary use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and exceeds it. It discloses the optimization loop, the z_min=0 placement, the default overwrite behavior, the side effect of opening an interactive 3D stage, automatic decimation of oversized meshes, and explicitly notes that the PNG preview is secondary. This is far more than a basic safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose, a brief algorithm outline, a docstring-style parameter section, and a separate note about the inline 3D stage. Each part adds unique value, though the final line about the PNG preview is slightly cryptic and could be tightened. Overall it is appropriately sized without wasteful repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema and minimal annotations, the description provides a complete picture: it explains the returned dict contents (rotation angles, overhang stats, new dimensions), the side effects (3D stage, decimation), and the default file overwrite behavior. For a mesh-operation tool with two simple parameters, this level of detail is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and there are only two parameters, so the description must compensate. It does so fully: file_path is described as 'Path to the STL file,' and output_path includes the crucial default behavior ('Defaults to overwriting the input'). It also documents the return value, adding semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific active verb and outcome: 'Auto-rotate a mesh to minimize overhangs and maximize bed contact.' It then explains the algorithm ('Tests multiple candidate orientations and picks the one with the best printability score') and the final disposition ('Re-orients the mesh and places it flat on the build plate (z_min = 0)'), clearly differentiating it from generic rotation or orientation-checking siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for automatically optimizing a mesh's orientation before printing, but it never explicitly states when to use this tool versus alternatives like auto_orient_model or rotate_model. No prerequisites, exclusions, or alternative recommendations are given, leaving the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains that the tool is a convenience wrapper that synthesizes a FailureReport from supplied args using the latest checkpoint and runs the same planner as 'plan_failure_recovery'. This provides good insight into the tool's behavior, though it does not explicitly state whether the tool has side effects or is read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, a technical detail paragraph, usage guidelines in bullet points, and an arg list. It is concise with no fluff, though the reference to a Python class (':class:`FailureReport`') may be slightly esoteric for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description provides good context about when to use and how the tool works internally, it lacks information about the return value. Since there is no output schema, the description should describe what the planned recovery strategy looks like. Additionally, there is a discrepancy between the described default for failure_type ('communication_loss') and the schema default (null), which is a minor completeness issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the tool description provides detailed parameter descriptions for all three parameters: printer_name, job_id, and failure_type. It lists possible failure types and the default value, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it plans a recovery strategy from a printer + job + failure type, with a specific verb 'plan' and resource 'recovery strategy'. It distinguishes itself from the sibling 'plan_failure_recovery' by explicitly noting the different input criteria (printer_name+job_id vs. failure_id).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool versus the alternative 'plan_failure_recovery'. It includes a bulleted list with clear scenarios: 'Have a printer_name + job_id from a failed print? → plan_print_recovery' and 'Have a failure_id from detect_print_failure? → plan_failure_recovery'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses handling of FTPS and REST API, return format with nullable fields, and availability of metadata. Misses rate limits or authentication but adequate for a read-only listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is structured with purpose, technical handling, return fields bullet list, and usage guidance. Slightly long but every sentence adds value, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, description thoroughly describes return fields, protocol handling, and usage linking to sibling tools. Lacks error handling or performance details but sufficient for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; schema coverage is 100%. Baseline for 0 params is 4. Description adds value by explaining tool purpose, return format, and usage, compensating beyond empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all G-code files available on the printer' with specific verb and resource. It distinguishes itself from 'analyze_print_file' (detailed metadata) and 'start_print' (initiating printing), and explains handling of different protocols.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to discover which files are ready to print' and directs to pass file name/path to 'start_print' for printing, and to use 'analyze_print_file()' for detailed metadata. This provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: free registration, successful registration even with concurrency limits, printer targeting by name, and tier-based concurrency enforcement. It fails to specify side effects (e.g., connection attempts, failure modes in registration) or return format, which would be valuable given the lack of annotations. The mention of verify_connection providing a 'proof summary' hints at response structure but doesn't fully cover all behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely informative. It front-loads purpose, then explains tier logic in a clear two-paragraph structure, then details args in a bullet-like list. That said, the tier discussion is somewhat verbose — the first two paragraphs could be tightened while preserving key points. The parameter list is efficient with examples and context. Overall, the length is justified by the tool's complexity, but a few sentences could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters with 0% schema coverage, no output schema, and complex tier logic, the description is fairly complete — it covers all parameter semantics, tier implications, and post-registration capabilities. However, it lacks details on failure scenarios (e.g., connection timeout, invalid credentials) and does not explicitly state the return value structure, though verify_connection hints at a summary. For a registration tool, it might also mention whether duplicate names are rejected or how the fleet state is updated. Still, it's stronger than many tool descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for all 10 parameters. It does an excellent job: explains host meaning for USB (port path), api_key requirements per type (required for OctoPrint/Bambu, optional for some, unused for USB), serial needs for Bambu, verify_ssl behavior including TLS pin mode mapping, baudrate defaults and caveats (Marlin boards at 250000), and persist semantics. The only minor gap is printer_model's deeper purpose ('safety/profile key') which is a bit vague, but overall it adds substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers a printer into a fleet, with a specific verb ('register') and target resource ('printer in the fleet'). It also includes scope details like naming and targeting by printer_name, distinguishing it from sibling tools like set_printer_light, discover_printers, and printer_status. The first line 'Register a new printer in the fleet' is direct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly addresses when to use this tool versus alternatives, including tier-based rules (Free/Pro run 1 printer at a time, Business starts at 3, Enterprise uncapped) and notes that registration always succeeds even when concurrency limits exist. It also clarifies that targeting by name is available at every tier, while fleet_status is Business+ — providing explicit context for when this tool applies and what alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully covers behavioral aspects: it describes that brand profiles return exact specs, generic return defaults, and that providing printer_id triggers compatibility checks and warnings. It does not mention side effects (none expected), and there is no contradiction with annotations. The behavior is well-explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but not terse, with a clear first-line summary followed by structured parameter explanations. It uses reStructuredText style for parameters, making it easy to parse. Every sentence adds value, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 parameters, no output schema, and no annotations, the description does a good job covering purpose, parameters, usage, and return behavior (exact vs default specs, warnings). It mentions specific return fields for brand profiles (density, temps, etc.) and compatibility warnings. It could be slightly improved by noting the return type or structure, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining both parameters in detail: 'material_or_brand' is described with examples ('PLA', 'bambu_petg_cf'), and 'printer_id' is explained as optional for compatibility. This adds significant meaning beyond the schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it resolves a material name or brand ID to a unified filament profile, with specific verbs and resource. It distinguishes between generic and brand profiles, and the purpose is unambiguous. Sibling tools like 'get_brand_filament_profile' or 'find_material_match' have different scopes, so this tool's distinct role is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool (BEFORE slicing or printing) and suggests passing the result to 'estimate_before_design'. It also explains the two input types (generic vs brand) and the optional printer_id for compatibility checks. However, it does not explicitly list when not to use it or alternative tools, though the context provides reasonable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the workflow (validate, slice, upload, report stats), explicitly states the print is not started automatically, and explains the skip_validation parameter. However, it doesn't describe failure behavior or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a paragraph explaining key behavior, and a list of parameters with clear explanations. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no output schema, no annotations), the description provides enough information to use it correctly. It covers purpose, behavior, and parameters. Missing details about the 'report stats' output, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description includes an Args section that explains all five parameters (model_path, printer_name, printer_id, profile_path, skip_validation) with their purposes and defaults, compensating fully for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Prepare a benchmark print: validate → slice → upload → report stats.' It uses specific verbs and resources, and distinguishes from siblings like 'run_calibrate' or 'run_quick_print' by focusing on benchmark prints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'The print is NOT started automatically — benchmarks should be manually observed.' It implies manual observation is required but doesn't explicitly contrast with alternative tools or state 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses validation, blocking of unsafe commands, sequential sending, and dry_run behavior. Missing explicit return value for actual send, but otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: front-loaded purpose, then Args with examples. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential behavioral aspects and usage context. No output schema, so description should explain return values; it only specifies dry_run return. Minor gap but overall complete for agent selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains commands format with examples, describes dry_run effect. Schema coverage is 0%, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sends raw G-code commands directly to the printer, with a specific verb and resource. It distinguishes from sibling tool 'validate_gcode' by explicitly mentioning it as an alternative for preview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance: use 'validate_gcode' for preview, mentions dry_run for testing, and states printer must be connected unless dry_run. Could be more explicit about when not to use, but adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that it modifies a config file and requires human confirmation. The three-level explanation adds behavioral context. However, it could note side effects or permanence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is informative: purpose, level definitions, behavioral impact. No redundant or missing elements. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set tool with one parameter, it covers main aspects. Lacks return value or error info, but the behavioral note (requires confirmation) is valuable. Could reference 'get_autonomy_level' for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for 0% schema coverage by fully explaining the 'level' parameter's allowed values (0,1,2) and their meanings. This adds essential semantics beyond the schema's integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Set the autonomy tier' and enumerates the three levels with clear definitions. This distinguishes it from its sibling 'get_autonomy_level' and related tools like 'check_autonomy'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the impact (updates config, requires human confirmation) and level behaviors. It does not explicitly mention when not to use it, but the context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses the tool's effect (turning lights on/off/flashing) and the printer brand constraint. No hidden behaviors or side effects are omitted; the tool is simple and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise yet complete: one sentence for purpose, an Args section with clear formatting and defaults, and a usage sentence. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks an explicit return value, but for a light control tool, the outcome is obvious (success/failure). Given no output schema, it is minimally adequate but could mention response content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides all parameter meaning: 'node' lists two valid values with defaults, 'mode' lists three values with defaults. This fully compensates for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool controls 'the printer's LED lights' and restricts to 'Bambu Lab printers only'. It clearly distinguishes from sibling tools like 'set_temperature' or 'set_leveling_policy' by targeting a specific hardware component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Three concrete use cases are provided: improving camera visibility, signaling print completion via flashing, and turning lights off for overnight prints. While no explicit 'when not to use' is given, the context is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behaviors: slicing with PrusaSlicer or OrcaSlicer, parsing G-code, printability analysis, adhesion recommendations, and that it does not upload or start a print. However, it does not detail output format or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear initial paragraph and bullet arguments. It is slightly verbose but every sentence adds value. Front-loaded with key differentiators.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and no output schema, the description covers core functionality but lacks detail on output format, error scenarios, or edge cases. It mentions return types but not structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds extensive meaning: it explains supported file formats for input_path, printer_id with examples, profile precedence, and material with default and examples. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is the primary estimation tool for slicing 3D models and returning time, filament, cost, and printability analysis. It differentiates itself from 'estimate_cost' and 'estimate_material_cost' by specifying input types and use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (before committing to a print job) and when not to (for G-code files use 'estimate_cost', for quick volume estimates use 'estimate_material_cost'). It provides context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully describes the tool's internal logic: searching print history and local directories, auto-detecting AMS slot, generating slicer overrides, and saved-goal carry-forward. It explains best-effort behavior for brief_id derivation, providing good transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensively structured with a summary, numbered steps, an example, and parameter details. While slightly verbose, it is front-loaded with the core purpose and well-organized, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema), the description covers the full workflow, parameter semantics, and edge cases like saved-goal carry-forward. It provides sufficient context for an AI agent to understand when and how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes a detailed Args section explaining each parameter's purpose, default behavior, and optional use cases (e.g., 'brief_id' derivation from sidecar, 'auto_ams' for non-Bambu printers). This adds substantial meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as a 'Smart one-shot material-switch reprint' and lists its four-step process: find model, check AMS, build overrides, reslice+print. It distinguishes itself as the highest-level reprinting tool, differentiating from simpler sibling tools like 'reprint_with_material' or 'run_reslice_and_print'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a realistic example and states it handles everything given file name and material. However, it does not explicitly caution when to use a simpler tool or when not to use this one, leaving some ambiguity about trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and excels: it discloses automatic loading of safety rules, reduced protection when coverage_warnings is non-empty, and the importance of specifying the printer model key. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, followed by details and a useful AGENT CONTRACT. It is slightly long but every sentence adds value, maintaining efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema (not shown), the description is complete: it covers purpose, behavior, return values, and common caveats (coverage_warnings). It addresses key usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter (printer_name) has 0% schema coverage, but the description adds value with examples (e.g., 'ender3', 'voron-350') and explains its purpose. This significantly aids parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it starts a real-time G-code interception session for a printer, specifying the resource (printer) and action (start session). It distinguishes from sibling tools like stop_gcode_interception and add_interception_rule.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides clear context: it mentions using add_interception_rule for custom rules after starting, and includes an AGENT CONTRACT that guides when to relay warnings. However, it does not explicitly state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses resilience (steps skipped if module unavailable) and return format (pass/fail report, printability score). It does not mention permissions or side effects, but the tool is read-only validation, so no destructive actions are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized with bullet points and parameter descriptions, making it easy to scan. It is slightly lengthy but front-loaded with the main purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (8-step pipeline) and presence of an output schema, the description covers all necessary aspects: steps performed, optionality, resilience, return values, and scope of checks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains each parameter in detail despite 0% schema coverage: input_path as file path, printer_id for bed-fit (optional, skipped if empty), material for material-specific checks (optional). This adds significant value over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Comprehensive validation pipeline for any 3D model before printing' and lists specific checks (format, mesh, watertight, etc.), clearly distinguishing it from siblings like 'validate_and_prepare_mesh' or 'validate_assembly'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use ('before printing') and explains optional parameters (printer_id, material) for additional checks, but does not explicitly state when NOT to use this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains it reads the file header (non-destructive) and lists the metadata extracted. However, it does not explicitly state that the operation is read-only or mention potential 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a note, and front-loaded. Every sentence adds value without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is quite complete for a simple tool: purpose, usage context, input format, and return structure. It could mention error cases or prerequisites, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, but the description adds meaning by specifying the filename is as shown by 'printer_files()'. This helps the agent locate the correct file.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a G-code file and extracts metadata. It specifies the verb 'analyze' and resource 'G-code file', and distinguishes from siblings like 'printer_files' and 'list_plate_objects'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use: 'when filenames are meaningless' and recommends an alternative tool ('list_plate_objects') for multi-object files. This provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does a good job: it discloses the OpenSCAD dependency, output file behavior (defaults to temp), return values, and the inline 3D stage side effect with decimation behavior. It could add more about failure modes or file overwrite semantics, but it provides substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, then uses headings and bullet points to organize operation types, use cases, params, return, and the 3D stage note. Every sentence adds value and the structure makes it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mesh operation tool, the description covers the operation types, external dependency (OpenSCAD), parameter semantics, return format, and the unique inline stage behavior. No output schema exists, but the return dict is described. This is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite the schema having zero parameter descriptions, the docstring fully explains each parameter: operation's allowed values, file_paths requiring a minimum of 2, and output_path defaulting to temp. It also explains the semantic effect of each operation choice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Perform a CSG boolean operation on two or more STL meshes', which clearly identifies the specific verb and resource. It enumerates the three operation types (union, difference, intersection) and provides concrete use cases, distinguishing it from sibling tools like merge_stl.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit use cases (e.g., subtract cylinder from block, combine parts) that clarify when to use this tool. However, it does not mention alternative tools or when not to use it, so it stops short of a full exclusion discussion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully carries the behavioral disclosure burden. It details exactly what the tool does: 'Walks the live tier-resolution chain on the user's machine' and lists the sources checked (env var, license file, OAuth session, cached entitlement, free-tier fallback). It also discloses that it is free-tier safe and does not require a license, which is critical behavioral information. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a clear one-sentence purpose, followed by a bulleted list of example user queries, then a detailed explanation of the resolution chain and output fields, and finally common interpretation cases. While it is lengthy, every section adds value for an agent needing to interpret results. It is front-loaded with the most critical information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description fully describes the return value structure (dict with effective_tier, resolution_chain, matched_source, agent_summary, tier_rank, pricing_url) and explains common interpretations. The tool has zero parameters and a straightforward purpose, and the description leaves no gaps in understanding what the tool returns and how to use the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema coverage is 100%. The description reiterates 'No arguments.' Without parameters, there is little to add. The baseline score of 3 is appropriate because the description confirms the absence of parameters, which is consistent with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Check the user's current Kiln subscription tier and explain WHY they're on it.' It explicitly enumerates the tiers (Free/Pro/Business/Enterprise) and distinguishes itself from sibling tools like 'license_status' or 'upgrade_kiln' by focusing on explaining the reason behind the tier. The many example queries further reinforce the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'Use this whenever the user asks any tier / plan / subscription / paywall / access question' with a comprehensive list of example queries. It also states 'No arguments. Free-tier safe — does NOT require a license to call. Available to every user.' and includes common interpretation scenarios. This clearly tells the agent when to use the tool and that it has no prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: the conditional inclusion of a 'reroute_recommendation' in the response, the impact of 'completion_pct_at_failure' on rerouter logic, and the fact that the recommendation is advisory only. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence, a condition block, and a parameter list. It is front-loaded with the main action. Minor detail like 'patent KILN-003 claim 5' is slightly tangential but does not detract significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 params, no output schema, no annotations), the description covers behavior, parameter semantics, and the conditional response. It also tells the agent what to do next. It could mention the default response on success, but the provided information is sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description carries full burden. It provides detailed explanations for all 5 parameters, including structure for 'alternative_printers' and behavioral context for 'completion_pct_at_failure' (threshold effect). This adds significant value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Mark a recovery session as completed,' which is a specific verb+resource. It clearly distinguishes this tool from sibling recovery tools like 'plan_print_recovery' and 'start_print_recovery' by focusing on completion and the optional reroute recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use the tool (to complete a recovery session) and provides guidance on when the reroute recommendation appears (on failure with alternative printers and kiln-pro installed). It also instructs the agent to call other tools for actual reroute. However, it does not explicitly exclude usage in other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that active e-stop blocks print commands, explains parameter behavior, and outlines return fields (active, reason, source, timestamp, interlocks). It does not cover authorization needs or rate limits, but for a read-only status tool, it is fairly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with purpose, then parameter details and return info. No fluff. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with 2 parameters and no output schema, the description covers purpose, parameters, return fields, and related tools. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explicitly documents both parameters with behavior and defaults. For printer_name: 'Query a specific printer, or omit for all printers.' For include_unlatched: includes default and meaning. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the emergency stop latch status for one printer or the entire fleet, using a specific verb ('get') and resource ('emergency stop latch status'). It distinguishes from siblings like emergency_stop and clear_emergency_stop by focusing on status retrieval only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use (to check e-stop status) and provides context (e-stop blocks print commands). It references sibling tools via 'See also', but does not explicitly state when not to use this tool or alternative scenarios. The guidance is clear but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that all motion ceases instantly and that a power cycle or firmware restart is typically required afterward. Could mention other side effects but sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: clear header, action description, distinction from similar tool, usage warning, and parameter list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description covers purpose, usage, parameters, and critical warnings for a safety-critical tool. It is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains all four parameters with defaults and semantics (printer_name for specific or all, reason code, source label, optional note). Lacks enum values but provides adequate context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool triggers an emergency stop on one or all printers, specifying M112, heater shutdown, and stepper disablement. It distinguishes itself from cancel_print by noting the lack of graceful cooldown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use only in genuine safety emergencies (thermal runaway, collision, spaghetti failure) and contrasts with cancel_print for graceful cooldown, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool uses mesh geometry, calculates material/support/adhesion/electricity costs, and returns a breakdown with recommendations. It does not mention destructive behavior, which is appropriate for a read-only estimation. However, it lacks details on potential side effects or dependencies, but is sufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: an initial summary sentence, followed by a paragraph on what the tool calculates, then a bulleted list of all arguments with defaults and units. It is front-loaded with the main purpose and uses whitespace effectively for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 11 parameters, no output schema, and no annotations, the description provides comprehensive context: what the tool does, how it works, what costs are included, supported materials, and detailed parameter explanations. It mentions the output includes a cost breakdown and recommendations, which is sufficient for an estimation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description's Args section provides detailed explanations for each parameter, including defaults and units (e.g., 'Material type (default "pla")', 'Interior fill percentage 0-100'). This fully compensates for the lack of schema descriptions, enabling correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates total print cost from a 3D model file, specifying the verb 'estimate' and the resource 'print cost from a 3D model file'. It distinguishes from siblings like 'estimate_material_cost' or 'estimate_print_time' by focusing on mesh geometry without slicing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the tool calculates costs directly from mesh geometry without needing G-code or slicing, and provides a breakdown and recommendations. It implies its use case for early cost estimation, but does not explicitly contrast with alternative tools for cost estimation, such as slicing-based methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It describes data sources (printer status, print outcomes database) and phases. While it implies read-only, it does not explicitly state non-destructiveness, but the verb and context are clear enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a summary sentence, then details, parameter list, and references. A bit lengthy but every sentence contributes; front-loads the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers methodology, parameter usage, and relative accuracy. Lacks description of the return value format, but for an estimation tool, the output is typically intuitive. No output schema exists, so some expectation of return details is reasonable but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description adds full meaning: explains printer_name, and for each optional parameter, clarifies 'Omit to read from printer status' and context (e.g., 'Seconds elapsed since print start'). This compensates for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Estimate print progress with phase-aware time prediction', specifying the verb and resource. It distinguishes from sibling tools like estimate_print_time by highlighting phase-awareness and historical data usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Typically more accurate than raw firmware estimates' and instructions to supply parameters or omit for live readings. The 'See also' section directs to related tools (printer_status, get_print_outcomes), aiding decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly states this is a read operation ('Get'), describes the return format, mentions the 'unassigned' grouping, and explicitly notes the requirement of an Enterprise license. No hidden behavior is left unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the main purpose in the first sentence and adds necessary detail in subsequent sentences. Perfectly concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return values (printer statuses grouped by site with status types). It covers edge cases (unassigned printers) and requirements (Enterprise license). The tool is simple and the description is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so coverage is 100%. The description adds valuable meaning beyond the schema by explaining the output grouping, status categories, and handling of unassigned printers. Baseline for zero parameters is 4, and the description exceeds it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies exactly what the tool does: 'Get fleet status grouped by physical site/location.' It clearly distinguishes from generic fleet_status by emphasizing grouping by site. It also details the return structure (idle, busy, offline) and handling of unassigned printers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when site-based grouping is needed but does not explicitly contrast with other tools like fleet_status or list_fleet_sites. No when-not-to-use or alternatives are mentioned, providing only implicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses that the tool provides a lightweight, non-destructive overview of current fleet capacity. It does not mention any side effects or special requirements, which is acceptable for a read-only metric tool. However, it could be more explicit about data freshness or caching behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence defines the tool's core function, second sentence provides context and alternative tools. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no parameters and no output schema, the description is mostly complete. It explains the metrics and differentiates from related tools. It could mention the output format or limitations, but it's sufficient for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description does not need to add parameter details, but it could indicate that no parameters are required. Still, the baseline holds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves fleet utilization metrics (busy/idle/offline counts and utilization percentage). It also explicitly distinguishes itself from the sibling tools fleet_status and fleet_analytics, making its unique purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool ('lightweight overview of fleet capacity') and when to use alternatives: 'For full printer details, use fleet_status. For historical analytics, use fleet_analytics.' This provides clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it describes the search matching (word-boundary, case-insensitive), technology filter behavior, limit default, and authentication requirements for direct mode. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and a bulleted Args section. While detailed, it could be slightly more concise, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return format (materials with technology, color, finish, pricing) and mentions catalog size. It covers filtering and defaults adequately. No output schema exists, so this is sufficient; minor omission of pagination details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds detailed semantics for all three parameters: search includes examples and matching behavior, technology lists common values and matching scope, and limit specifies default. This compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists available materials from external manufacturing services, specifies the returned fields, and distinguishes itself from sibling tools like fulfillment_quote by referencing the use of the material id for quoting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (to list materials), advises using filters to narrow results, and mentions authentication modes. However, it lacks explicit guidance on when not to use this tool or direct comparisons to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It details key behaviors: charging the orchestration fee before placing the order, automatic refund if placement fails, payment hold vs direct payment, tax calculation with jurisdiction, and tax exemption for businesses with tax ID. This goes well beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured well with a clear introductory sentence followed by detailed parameter descriptions. However, it is somewhat verbose, especially in the args section. The front-loading of the purpose and behavioral note is good, but the length could be trimmed slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 12 parameters and no output schema, the description covers all necessary aspects: parameter dependencies, payment flow, tax behavior, and next steps (using fulfillment_order_status). It lacks an explicit description of the immediate return value, but the reference to tracking status compensates for that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning, and it does so extensively. Every parameter is described with its source (e.g., quote_id from fulfillment_quote, shipping_option_id from quote's shipping_options), constraints (e.g., preview_token validated against file bytes), and conditional requirements (e.g., quoted_price required when no payment_hold_id and payment rail configured). This is far more informative than the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Place a manufacturing order based on a previous quote.' It uses a specific verb ('Place') and resource ('manufacturing order'), and implicitly distinguishes from sibling tools like fulfillment_quote and fulfillment_order_status by referencing them in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: after obtaining a quote from fulfillment_quote, and before using fulfillment_order_status to track progress. It also outlines alternative payment flows. However, it does not explicitly state when not to use it or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavior burden. It discloses the tool is read-only ('retrieve'), lists return fields (source_scad, prompt, parameters, notes, parent_version), and notes error behavior if version doesn't exist. Missing details like no side effects or performance impact, but those are implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then usage guidance, parameter details, and return info. It avoids redundancy, though the return section could be slightly shorter. Overall, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with one parameter and no output schema, the description covers: purpose, when to use, parameter format, return content, and error behavior. It is fully adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 version_id format with examples (e.g., 'my-coaster:3') and disambiguates between a plain integer and prefixed reference, adding significant value beyond the schema's simple string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Retrieve a single design version by its ID,' using a specific verb and resource. It distinguishes from siblings like list_design_versions, save_design_version, and rollback_design_version by focusing on a single version retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this to inspect the full source code, parameters, and notes for a specific version when you already know the version reference.' This tells the agent when to use it and implies when not (e.g., not for listing or modifying). It also explains the version_id format.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden and does so thoroughly: it states that nothing is cancelled or paused, the print continues unchanged, only Kiln's responsibility changes, and the no-argument form mutates nothing. It also discloses the subtle one-time return behavior and the fleet-tier limitation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than strictly necessary and the opening metaphor partially overlaps with the following explanation, but each paragraph adds a distinct behavioral nuance. It is front-loaded with a plain-language summary and ends with a clear Args section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter, no annotations, and no output schema, the description is complete: it covers purpose, single-printer scope, side effects, no-argument behavior, and the one-time return edge case. An agent has enough information to invoke the tool correctly and understand what will happen.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only shows an optional nullable string, so the description's 'Printer to hand back. Omit to report only' adds real meaning by tying the parameter to the operation and clarifying that omission is a reporting mode rather than an error. It does not specify name format or identifiers, but for one optional parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific action: handing back the printer Kiln is currently managing so Kiln's attention is freed. It also distinguishes itself from fleet-tier operation and sibling tools by explaining that it works with one printer at a time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use the tool (below fleet tier, when you want Kiln to stop driving the current print) and when not to (for back-and-forth between two running printers, which is fleet-tier behavior). It also notes that calling with no arguments is a no-op reporting mode, but it does not explicitly name alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains token is single-use, expires, scoped to file hash and optional printer_id, and that changing file invalidates token. Emphasizes this is a safety gate. Does not mention permissions or side effects, but covers critical behavioral aspects well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: starts with a concise purpose sentence, then workflow, then behavioral details, then parameter descriptions. No wasted words. Front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters, no output schema, and no annotations, the description covers return values (Dict with token and expires_at), workflow, binding, expiration, safety gate. Complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description fully documents all three parameters: file_path (path, types, hashing), printer_id (optional, scoping behavior), and ttl_seconds (default 600). Adds meaning beyond the schema's type and required field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool issues a preview-confirmation token for a file to be printed, specifying the verb 'issue' and the resource 'preview-confirmation token'. It distinguishes from sibling tools like issue_shipping_confirmation_token by context and the explicit workflow described.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow: call after rendering preview, user approves, call this tool, then pass token to start_print or fulfillment_order. States that start_print refuses without valid token and mentions the env var skip. Lacks direct comparison to similar sibling tokens but still offers strong guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description thoroughly discloses the tool's non-destructive behavior (it only returns a URL), the expected response fields, and the authentication flow. There is 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and bullet points for response fields. It is slightly lengthy but remains informative and front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an output schema, the description fully explains the tool's behavior, response fields, and the required follow-up polling step. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero input parameters, so the schema coverage is 100%. The description adds value by explaining the response fields and their usage, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's purpose: to start a Kiln sign-in via OAuth and return a URL for the user to open. It distinguishes itself from sibling tools like `kiln_signin_poll` by specifying that this is the initial sign-in call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear workflow: call this, then poll with `kiln_signin_poll`. It also states that this is the first call for an unauthenticated user. However, it doesn't explicitly exclude already signed-in users or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It clearly states the tool returns a bundled database and not physical status, implying it is a safe, read-only operation. It could be more explicit about side effects but is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with line breaks, no fluff. Every sentence serves a purpose—defining the tool and providing alternative guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no output schema, the description adequately describes what is returned (profiles with density, cost, temps). It does not describe return format or pagination, but these are less critical for such a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters and the schema is empty. The baseline for zero parameters is 4. The description adds value by specifying what data fields are returned (density, cost, temps), which is useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'list' and clearly identifies the resource as 'built-in filament material profiles (density, cost, temps).' It also explicitly distinguishes from sibling tools that deal with loaded materials, ensuring no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when not to use this tool (for physically loaded material) and directs to alternative tools ('get_material' and 'get_active_material'). This is perfect usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it parses embedded metadata, works without mesh geometry, and returns specific fields. No annotations are present, so description bears full burden; it adequately explains behavior without omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections, concise language, and effective use of backticks. Every sentence adds value and the description is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly details the return value structure (objects list with label_id, plate metadata, plates_available). Contextual integration with sibling tools is shown, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters are fully explained with context: file_path describes acceptable file types, plate_number explains 1-based indexing and default value. Schema coverage is 0% but description compensates completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists named objects on the build plate from a .gcode.3mf file. Distinguishes from siblings like extract_plate_object and skip_print_objects by explaining how the output (label_id) feeds into those workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific use cases: discovering parts before calling extract_plate_object or getting label_id for skip_print_objects. Also explains plate_number parameter and multiple plate support. Could be improved by explicitly stating when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden and discloses key behaviors: it generates rules from the printer's safety profile and adds them to the session. The AGENT CONTRACT about coverage warnings adds important user-facing behavior. It could be clearer about whether existing rules are replaced or merged, but overall it provides substantial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, usage guidance, parameter list, and agent contract. Every sentence adds value without redundancy. It is concise yet sufficiently detailed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (so return values are handled), the description covers all necessary aspects: what the tool does, when to use it, what parameters are needed, and a critical user-facing contract. No obvious gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description's Args section provides clear, concise explanations for both required parameters (session_id and printer_name), fully compensating for the schema gap and adding meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads safety-profile rules for a printer into an active session, specifying the exact resource and action. It distinguishes itself from sibling tools like add_interception_rule and remove_interception_rule by focusing on loading a predefined set from a safety profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to reset or refresh safety rules,' providing a clear primary use case. While it does not list alternatives or when not to use, the context of sibling tools implies this is for bulk loading rather than individual rule manipulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that locking rejects community profile updates and that only admins can unlock. This is fairly transparent for a lock operation, though it doesn't mention side effects on existing agents or reversibility beyond admin unlock.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear first sentence stating purpose, followed by relevant details about enterprise feature and admin unlock. The Args section is structured and adds value without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 required parameter, no output schema), the description is complete. It explains the purpose, usage context, and parameter semantics. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the input schema. It provides an example ('e.g. 'ender3'') and clarifies that the parameter is a 'Profile identifier'. Since schema description coverage is 0%, the description compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Lock a safety profile' and the resource 'safety profile', with a concise explanation of the effect ('agents cannot modify its limits'). This distinguishes it from sibling tools like unlock_safety_profile or list_safety_profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's an 'Enterprise feature' and that 'Only an admin can unlock', providing context for when this tool is applicable. It also says 'When locked, community profile updates for this printer model are rejected', which implies when not to use. However, it doesn't explicitly list alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the merging behavior, optional translation, return value shape, and a notable side effect: opening an interactive 3D stage and decimating oversized meshes for display. It stops short of describing error cases or file overwrite behavior, but the disclosed details are substantial and useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a summary line, usage guidance, parameter documentation, return type, and side-effect note. A little redundancy exists ("Combines triangle data" and "Optionally translates each part" restate earlier points), but overall every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description appropriately includes the return dictionary fields. It also covers the inline 3D stage side effect and distinguishes the tool from its closest sibling. It could be more complete by specifying coordinate units or behavior when positions are omitted, but it is sufficiently complete 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides parameter names, types, and a default, with 0% schema coverage. The description compensates fully by explaining `file_paths` as a JSON array of STL paths, `output_path` as the write target, and `positions` as an optional JSON array of {"x","y","z"} offsets per file. This adds meaningful semantic detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states the tool's function: "Merge multiple STL files into a single mesh (supports positional offsets)." It uses a specific verb and resource, and explicitly differentiates itself from the sibling tool `merge_mesh_files` by noting the positioning capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives direct usage guidance: "Use this when you need to position parts relative to each other" and "For simple concatenation without positioning, `merge_mesh_files` also works." This explicitly names an alternative and clarifies when each tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool adds generation-specific checks on top of standard renders and details rendering differences based on file type (colored 3MF vs STL/colorless 3MF). It does not mention read-only nature or return format, but is fairly transparent for a rendering tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, differentiation, required workflow, and parameter detail. It uses formatting (bold, bullet points) effectively. Each sentence adds value, and it is concise for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no output schema, and no annotations, the description covers the essential context: purpose, workflow, and parameter semantics. It does not specify return format or number of angles, but it is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 file_path parameter as 'Path to an STL or 3MF file to render' and adds context about how different file types affect rendering, which goes beyond the schema's type constraint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a specialized post-generation verification renderer, contrasting with the general-purpose visualize_model tool. It explicitly says 'Render a 3D model to multi-angle PNG previews for visual inspection' and adds generation-specific checks, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: 'REQUIRED before printing any generated model. You MUST call this tool after generating a model and BEFORE printing.' It also outlines a required workflow with steps and lists specific checks to perform, leaving no ambiguity about when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so admirably. It discloses the exact return structure (printer, job, capabilities), how `lite` alters the payload, that both levels include 'every warning,' and rationalizes the design to prevent client confusion. This goes beyond generic statements and gives an agent a solid mental model of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a 'Returns' section, and 'Args' explanations. It is longer than strictly necessary, especially the final paragraph explaining the history of `print_status_lite`, but that narrative directly supports understanding the `detail` parameter and avoids future confusion. Every sentence adds value, even if the historical note could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, this description is quite complete for a status tool. It covers what to expect in the response, how to interpret `detail`, and even mentions warnings. It could be slightly more exhaustive (e.g., elaborating on the 'warnings' field or edge cases), but for a first-call tool it provides all necessary context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully documents both parameters. It explains `printer_name` (omit for default) and `detail` (accepted values, defaults, and behavioral impact). It even clarifies the difference between 'full' and 'lite' with concrete examples of what is included/omitted, which is far more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Get printer state, temperatures, job progress, and capabilities') that clearly states what the tool does. It differentiates itself from siblings by mentioning it should be used as the 'first call' and explicitly contrasts itself with the retired `print_status_lite`, making its scope and positioning unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use this as the first call to understand what the printer is doing,' providing clear when-to-use guidance. It also explains the `detail` parameter for 'frequent polling during a print' versus full inspection. However, it does not mention alternatives beyond the retired `print_status_lite`, so it lacks an explicit when-not-to-use or discussion of other sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It explains the entire workflow: looks up settings, merges overrides, reslices, runs a safety check, uploads, and starts the print. It also discloses the local slicer requirement and side effects (starts a print).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-liner, process summary, usage guidance, example, requirement note, and argument list. It is longer than strictly necessary but each section adds value. The example helps understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering the tool's complexity (7 parameters, no output schema), the description provides sufficient information for an agent to invoke it correctly. It covers the workflow, parameter semantics, and prerequisites. Minor missing details: error handling if slicer is not installed or material not found.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the context signals indicate 0% schema coverage, the description itself documents all 7 parameters with clear explanations and even provides JSON examples for extra_overrides and ams_mapping. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the core action: 'Reprint a model with a different material — auto-adjusts temperatures, speeds, and retraction for the new material.' It distinguishes itself from siblings by specifying it's a one-shot convenience tool for material changes, unlike general reslicing or printing tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (e.g., reprint in a different material like PLA→PETG) and provides an example. It also mentions a requirement (PrusaSlicer or OrcaSlicer installed locally). However, it does not explicitly state when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses that the STL is modified in-place, that success also opens an interactive 3D stage, that oversized meshes are decimated for that stage, and that the PNG preview is not the full experience. This prevents surprising 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, with bolded sections and separation between uniform and per-axis scaling. It is somewhat long, but every section is meaningful given the parameter complexity and the unexpected 3D-stage side effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, parameter semantics, in-place mutation, and success side effects. It does not explicitly describe the return value or error conditions, but the side effects are the primary behavioral information the agent needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides complete semantics for all seven parameters: target_height_mm means Z-axis height, scale_factor is a uniform multiplier, max_dimension_mm caps the largest axis, and omitted per-axis values default to 1.0. It also encodes the critical cross-parameter rule that uniform and per-axis scaling cannot be combined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the action: 'Rescale an STL model to meet dimensional targets.' It then specifies the exact scaling modes and target meanings, making the tool's role unmistakable and distinct from siblings like rotate_model or scale_mesh_to_fit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear trigger: 'Useful when a generated model is the wrong size for the printer's build volume or doesn't match the desired dimensions.' It also explicitly explains the two scaling modes and forbids combining them, but it doesn't name alternative tools or specify when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the tool accepts a base printer profile and JSON overrides, lists common override keys, provides an example, and notes the output directory for G-code. No annotation contradictions; description adds useful behavioral context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is long but well-organized with a clear opening, bullet list, example, usage note, and parameter section. Every sentence contributes value, though slight verbosity prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: input formats, printer selection, overrides format, output directory, slicer path, prerequisites, and usage context. Sufficient for a complex tool with output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates. The tool description explains the overrides format and common keys, and the Args section describes each parameter with file types and defaults, adding significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'reslice' and resource '3D model with custom slicer parameter overrides'. Clearly distinguishes from siblings like 'slice_model' and 'run_reslice_and_print' by emphasizing custom overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: print failures due to adhesion, wobble, or quality issues. Recommends pairing with 'rotate_model' and lists prerequisite of installed slicer software, with verification via 'find_slicer'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses behavior: reads embedded metadata, determines source, returns specific fields. It clearly indicates a read-only operation without destructive effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: starts with purpose, then method, then return values. Each sentence is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is complete. It explains what it does, how to use it, and what it returns, leaving no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description must compensate. It provides ':param file_path: Path to the .3mf or .gcode.3mf file.' This adds meaning beyond the schema's type definition, specifying acceptable file formats.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb+resource: 'Identify where a .3mf or .gcode.3mf file was downloaded from.' It clearly states the tool's purpose and distinguishes it from siblings like extract_model_from_3mf by focusing on source identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description includes explicit use case: 'Use this when you need to trace a file back to its source — for example, to find the original STL files on MakerWorld when the .gcode.3mf only contains pre-sliced G-code without mesh geometry.' It provides context but does not explicitly state 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return content (active safety profile, temperature limits, etc.) and implies a read-only operation. It could explicitly state no side effects or permissions, but the listed fields are sufficient for understanding behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then elaboration. No wasted words. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete. It covers what the tool returns and when to use it, which is sufficient for an agent to select and invoke this tool correctly among many safety-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description adds significant value by listing the specific data returned, which helps the agent understand the tool's output without relying on an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Get[s] a comprehensive snapshot of all active safety measures' and lists specific items included, distinguishing it from sibling tools like 'safety_audit' or 'get_safety_profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case: 'Use this to answer "is my printer safe right now?" in a single call.' While it doesn't explicitly exclude other uses or mention alternatives, the context among sibling tools implies this is for quick overview, not detailed audit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It explains persistence across sessions, TTL auto-expiry, and scope/printer_name interaction. Adequate disclosure for a storage tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Docstring format with Args section is well-structured. First sentence conveys purpose. No wasted words; each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 5 params, no output schema, and no annotations, description provides complete coverage: purpose, parameter details, behavioral traits. Agent can confidently use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description explains all five parameters: key, value, scope, printer_name, ttl_seconds. Adds meaning about scope override and TTL behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool saves persistent notes/settings. Provides specific use cases like printer quirks, calibration findings, distinguishing it from similar tools like delete_agent_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use it ('remember printer quirks...'), but does not specify when not to use it or alternatives. However, examples imply usage context, and siblings like delete_agent_note exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral traits: parallel search across sources, interleaved results, and the limitation that MakerWorld returns a search URL due to no direct API access. It also describes result fields (source, is_free, has_printable_files, has_sliceable_files). However, it does not mention rate limits, authorization, or pagination behavior beyond the page/per_page parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, bullet points, and examples. Every sentence adds value, and it is appropriately sized for the tool's complexity. No unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description effectively covers inputs, behavioral details (parallel search, source differences), output fields, and next steps via related tools. It is sufficiently complete for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for all 5 parameters, including examples for query ('raspberry pi case', 'benchy') and explanations for sort order and sources. This adds significant meaning beyond the bare schema (which has 0% coverage). The parameter descriptions are thorough and actionable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches across multiple 3D model marketplaces simultaneously, listing specific sources (Thingiverse, MyMiniFactory, Cults3D, MakerWorld) and mentioning interleaved results. It distinguishes from sibling tools like 'browse_models' and 'search_models' by specifying cross-marketplace search and referencing subsequent tools (model_details, model_files, download_model) for further actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to search across connected marketplaces) and provides usage context: MakerWorld returns a URL rather than models, and the optional 'sources' parameter allows restriction. It also directs users to related tools (model_details, model_files, download_model) for follow-up. While not explicitly stating when not to use it, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers a clear step-by-step workflow (starts print, waits, captures snapshots, returns them, optionally auto-pauses). It also mentions the auto_pause behavior driven by failure reports. It could go further by describing what happens after monitoring ends or stopping behavior, but for a print start tool, this is thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than average, but every part earns its place: a one-line summary, a short rationale, a numbered workflow, and a compact parameter list. It is front-loaded with the purpose. The only criticism is minor redundancy (e.g., 'first layer' repeated multiple times) and the aspirational 'optionally auto-pauses if you report a failure' could be more precise about how the reporting happens.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with an output schema and complex workflow, the description covers the start-to-finish behavior, all key parameters, and the safety context. It omits any mention of the preview_token parameter and doesn't describe error conditions or what happens if the printer is not available. However, given the sibling ecosystem and the tool's purpose, it is largely self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides meaningful, human-readable semantics for 6 of 7 parameters, including required status for file_name, the default-printer behavior for printer_name, and the units (seconds) and defaults for the first_layer_* parameters. Only preview_token is left undocumented, but its purpose is somewhat inferable from the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Start a print and automatically monitor the first layer.' It immediately differentiates itself from the sibling tool start_print by stating it is the recommended way to start prints autonomously, and references the specific Level 1/2 autonomy requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool: 'Use this instead of start_print when operating autonomously (Level 1/2) to satisfy the first-layer monitoring safety requirement.' This directly contrasts with an alternative and gives a concrete condition for selection. The tool's position as the recommended autonomous path is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions that it parses the STEP ASCII header, is fast, and requires no external backend. With no annotations provided, it adequately discloses the tool's behavior for a simple metadata extraction tool, though it omits error handling details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three clear parts: main action, details, and usage recommendation. Every sentence adds value, 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers what the tool does, what metadata it returns, and why to use it. It is complete and leaves no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to the single parameter 'file_path' by specifying it expects '.step' or '.stp' files, which is not in the schema. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Extract metadata from a STEP file' and lists specific metadata like product names, body count, and file schema. It distinguishes from sibling 'import_step_file' as it does not convert the file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool to inspect a file before deciding to import it, providing clear usage context. It does not explicitly name an alternative but implies the alternative is to use 'import_step_file' for conversion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the transparency burden. It explains behavior for different printer types (Moonraker triggers Klipper update manager, OctoPrint uses Software Update plugin), describes the optional component parameter, and notes that all components with updates are upgraded if omitted. It lacks explicit detail on whether the update is asynchronous or blocks, but overall provides solid behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using only a few sentences. It starts with a clear statement of purpose, then provides usage alternatives, parameter clarification, and a prerequisite. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one optional param, no output schema) and missing annotations, the description covers all essentials: purpose, usage guidelines, parameter semantics, and behavioral notes. It does not describe return values, but for a command tool this is acceptable. It is complete enough for an agent to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter with no description (0% coverage). The description adds meaning: 'Optional component name to update (e.g. 'klipper', 'moonraker'). If omitted, all components with available updates will be upgraded.' This explains both the value and the default behavior, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Start a firmware update on the default/connected printer (adapter-level, by component).' It distinguishes itself from the sibling 'update_printer_firmware' by specifying it is for the default/connected printer rather than fleet-specific updates with printer name or version pinning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'For fleet setups where you need to update a specific printer by name or pin a target version, use update_printer_firmware instead.' It also states the prerequisite 'The printer must not be actively printing' and recommends checking firmware_status first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses blocking behavior, timeout, event types, and return payload variations (events_received, timed_out, watcher_already_finished). It also explains default event types and their significance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, followed by parameter descriptions, then behavioral details. It is thorough but could be slightly more concise; however, every sentence adds value, and the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description thoroughly explains return values and special cases (events_received, timed_out, watcher_already_finished). With 4 parameters, all are explained in detail. The description is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description extensively documents each parameter: 'watch_id' is linked to 'watch_print', 'block_until_event' is explained with default and effect, 'timeout' includes MCP client timeout suggestion, and 'event_types' lists defaults and gives example usage. It adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Check the current status of a background print watcher.' It also specifies the outputs (progress, collected snapshots, finished status) and distinguishes it from sibling tools like 'watch_print' which starts the watcher, and 'stop_watch_print' which stops it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use blocking vs polling: 'Loop a single blocking call instead of polling every N seconds — roughly 50× fewer tool invocations on a multi-hour print.' It explains default behavior and the effect of 'block_until_event', but does not explicitly state when not to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the write operation to '~/.kiln/license' and the return of tier info, which are key behaviors. With no annotations provided, this adequately covers transparency, though it could mention if any authentication is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose in the first sentence, and every sentence adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is adequate. It covers the action, side effects, and return value. Minor room for improvement: mentioning any prerequisites or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'key' is described with format examples ('kiln_pro_...' or 'kiln_biz_...'), adding significant meaning beyond the schema's simple string type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Activate a Kiln Pro or Business license key,' specifying the verb and resource. It distinguishes itself from the sibling tool 'license_status' by mentioning it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to 'Use license_status to check the current tier first,' providing clear context for when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden — and delivers exceptionally. It discloses the non-obvious STEP/STP conversion behavior, warns that the count reflects 'KILN'S TESSELLATION' not the user's file, and codifies an 'AGENT CONTRACT' requiring attribution via the subject field. The explicit note that this 'is not a finding about the user's file' is precisely the kind of behavioral nuance that prevents agent misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with a crisp purpose sentence, and each subsequent paragraph addresses a distinct concern (classification semantics, usage timing, CAD caveat, params, returns). The prose is somewhat verbose — the subject/message attribution warning is restated twice — but the repetition serves a genuine safety purpose for agent behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, read-only tool with no annotations and no output schema, the description covers every gap: input file types, return dict contents ('edge count breakdown, watertight status, subject, message, and (CAD only) converted_from'), and an important behavioral edge case (CAD conversion). Nothing needed for correct invocation or interpretation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema's bare 'File Path' title conveys almost nothing, so the description must compensate — and does. It documents accepted formats ('.stl, .obj, .glb') and the additional STEP/STP CAD path, transforming an opaque string param into a fully specified input contract. For a single-parameter tool, this is complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence 'Count and classify non-manifold edges in a mesh' pairs a specific verb with a clear resource, and the three-way classification (boundary/T-junction/manifold edges) precisely specifies scope. It distinguishes itself from diagnostic siblings like repair_mesh by explicitly labeling itself 'the diagnostic version of the manifold check,' making its role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage timing: 'use it to understand exactly how many edges are problematic before deciding whether to repair.' It clearly positions itself within a workflow (diagnose before repair), but stops short of naming alternatives or stating explicit when-not-to-use conditions, relying on the reader to infer which sibling does the repairing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes arrangement strategy, group handling, defaults, and return format. Does not mention side effects or authentication, but those are not needed for this calculation tool. Slight lack of detail on error cases but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear sections (overview, usage, example, args, returns). Slightly verbose with docstring-style formatting, but every part is informative. Could be shortened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and sibling tools, the description covers input format, output format (dict with success, parts, group_count, message), and usage context. Complete enough for correct agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates fully with a detailed Args section explaining each parameter, including nested fields of part_specs, defaults, and purpose of printer_id. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool calculates non-overlapping XY positions for parts on a print plate. The verb 'calculate' and resource 'positions' are specific. Although it doesn't explicitly distinguish from sibling 'arrange_parts_on_plate', the name and description imply automatic arrangement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: before compose_multicolor_3mf with multiple separate objects. Also provides alternative: for maximum density, use kiln-pro. Explains group index behavior for multi-color units.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It thoroughly explains the behavior for each method, including edge cutting, capping, closed solids for z_height, surface painting for others, and slicer compatibility. It also discloses side effects like the inline 3D stage, automatic decimation, and dependency-free geometry. This goes beyond typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but each section adds value: method explanations, technical outcomes, slicer guidance, and the stage note. It is well-structured with bullet-like formatting, though slightly verbose. Every sentence earns its place, and it is front-loaded with core functionality before diving into details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple assignment methods, variable output formats, and an interactive stage side effect), the description is remarkably complete. It covers prerequisites (input_path), return values (zone STL paths, colors, face counts, AMS mapping, weights, 3MF), and post-behavior (opens 3D stage). Since there is no output schema, the description bears full responsibility, and it fulfills it thoroughly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully explains each parameter. It defines input_path as a binary STL path, num_colors with default 4, method with allowed values and defaults, and color_palette with default hex list. It also describes the return dict structure, adding meaning beyond the schema's sparse property definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Split a 3D model into color zones by geometric region.' It specifies a precise verb (split), a resource (3D model), and the method (by region), and distinguishes itself from sibling tools like auto_color_by_height by covering multiple assignment methods (z_height, normal, random).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed context on when to use the tool, explaining the different methods and their outcomes (closed solids vs. watertight object). It does not explicitly name alternatives or exclusion cases, but it clearly implies when it is appropriate, and the distinction from auto_color_by_height is evident from the title and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully bears the burden of behavioral disclosure. It details the polling behavior, terminal states, timeout, and return structure (outcome, final state, elapsed time, completion history, optional design_goal block). It also notes best-effort for brief_id. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a purpose statement, behavior paragraph, and parameter docstring. It is relatively concise given the amount of information, though slightly longer than minimal. Every sentence adds value, but could be tightened slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a polling tool with optional parameters and no output schema, the description covers the return value format thoroughly. It addresses the main use case, optional features, and edge cases like timeout. It is complete for an agent to understand and use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 each parameter's purpose and effect: job_id (track specific job vs. monitor printer), timeout (max wait), poll_interval (status check frequency), and brief_id (adds design_goal if resolves). This adds significant meaning beyond the schema's type and default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Wait for the current print to finish and return the final status.' It uses specific verbs ('await', 'polls') and resource ('print completion'), and distinguishes from sibling tools by focusing on blocking wait versus fire-and-forget, which differentiates it from monitoring or cancellation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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 (fire-and-forget, avoid manual polling) and explains the optional job_id and brief_id parameters. However, it does not explicitly state when NOT to use it or compare with alternatives like monitor_print, so it lacks explicit exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the operation is 'Queue bookkeeping only' and never sends anything to the printer, and explains the refusal behavior with code='PRINT_IN_PROGRESS' and the rationale behind it. This is highly transparent about side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with a one-sentence summary, then explains behavior, alternatives, and constraints. Every sentence adds value—no fluff. It is front-loaded with the most important information and is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and lack of output schema, the description covers all necessary context: what it does, when to use it, error conditions, and behavioral effects. It is complete for an agent to correctly select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (job_id) with no description, and schema_description_coverage is 0%. The description provides 'job_id: The job ID to cancel.' This is minimal but does add meaning beyond the parameter name. Since it's a simple identifier with no additional semantics, a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Remove one job from the print queue while it is still WAITING.' It uses a specific verb (remove) and resource (print queue), and distinguishes itself from cancel_print (which stops a started job). This is a clear, specific purpose that differentiates from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: only for jobs in the QUEUED state. It also provides an explicit alternative: 'To STOP a job the machine has already started, use cancel_print'. This gives clear when-to-use and when-not-to-use guidance, along with the error code for invalid states.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description details required trimesh package, supported formats, and structured report contents. Lacks any mention of side effects (likely read-only) but generally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet lists and clear sections. Front-loaded with key purpose and sibling distinction. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite minimal schema and no annotations, the description covers purpose, usage, output format, dependencies, and file support. Complete for this single-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter file_path is described with format list (STL, OBJ, PLY, etc.), adding value beyond the string type in schema. Full coverage of parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'deep mesh defect analysis' with specific defects listed. Explicitly distinguishes from sibling tool 'analyze_mesh_geometry' by noting its focus on printability vs defects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Use this when you suspect mesh defects or when repair_mesh didn't fix the issue.' Also advises to use before slicing and lists complementary tools with their roles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses auth token requirements and side effect of triggering software e-stop. No annotation provided, but description covers key behavioral aspects. Lacks specifics on idempotency or error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then context, differentiation, auth, parameter details, and see-also. No superfluous text; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all four parameters and authentication. Missing return value or error handling details, but for a simple e-stop trigger, this is largely sufficient given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter's purpose, default values, and conditional requirements (e.g., token).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states its purpose as 'Trip emergency stop from an external hardware bridge' and explicitly differentiates from emergency_stop() which is for agent/software-initiated stops.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (physical input devices) and when not (use emergency_stop for software stops). Provides alternative tool names and details authentication requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool returns a list of firmware components with versions and update availability, and that some printers will return an 'UNSUPPORTED' error. However, it does not mention behavior for cases like no default printer or disconnection, which would add further transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with two short paragraphs that front-load the main purpose. Every sentence adds value—defining the scope, providing an alternative, describing the output, and noting unsupported backends. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description is self-contained. It adequately explains what the tool does, what it returns, and important exceptions (unsupported backends). The sibling comparison further contextualizes its use. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. With a baseline of 4 for no parameters, the description adds value by clarifying that the tool operates on the default/connected printer without needing any input, which is implicit from the schema but explicitly stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking firmware updates on the default/connected printer. It uses specific verbs ('Check') and identifies the resource ('firmware updates on the default/connected printer'). It also distinguishes itself from the sibling tool 'check_firmware_status' by noting the difference in scope (default vs. specific printer by name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (for the default/connected printer) and when to use an alternative ('For fleet setups... use check_firmware_status instead'). It also provides context on unsupported backends (Bambu and Prusa Link), helping the agent decide when the tool might be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure, and it does so exceptionally. It states the tool never fails due to network/plan issues, always returns the local layer, and reports community unavailability gracefully. It also discloses account and plan dependencies, which is exactly the kind of behavior an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a front-loaded summary, bullet points, and an Args section. Most sentences earn their place, though the 'always available, no account needed' point is reiterated in the failure-behavior paragraph. Minor redundancy, but overall clear and navigable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema or annotations, the description is remarkably complete. It covers success conditions, plan gating, network-independent behavior, local vs. community scope, and parameter semantics. An agent can confidently determine when and how to invoke it, and what to expect in return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description is the sole source of parameter meaning. It explains that geometric_signature comes from fingerprint_model and that geometric_signature_v2 disambiguates designs sharing the older signature. This adds substantial value beyond the bare schema and directly informs correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Get aggregated print data for a model geometry.' It then clearly breaks down the two return layers (insight and community) and what each contains, making it easy to differentiate from siblings like get_model_print_history or community_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when the tool is appropriate: to retrieve local print insight and, if available, community-wide data. It explains the Kiln Pro requirement for community data and clarifies that the v2 parameter narrows results to the exact design. It does not name sibling alternatives explicitly, but the usage context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes returned fields (detected, sensor_enabled) and implies read-only behavior. No annotations provided, so description covers main behavioral aspects, though doesn't discuss potential side effects or prerequisites in detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with clear front-loading: scope, return fields, usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple tool with no output schema, description adequately explains return values and usage context. Sibling tools are referenced appropriately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema; description adds no parameter info, but baseline for 0-param tool is 4, and schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets filament runout sensor status specifically for OctoPrint and Moonraker, distinguishes from sibling ams_status for Bambu printers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (verify filament before starting print on non-Bambu printers) and when not (use ams_status for Bambu Lab printers).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses output types (hotend/bed temps, fan speed, tips) but does not mention side effects, permissions, or safety. Acceptable for a simple getter, but could be more explicit about read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two clear paragraphs: first paragraph states purpose and usage, second lists arguments. No wasted words, front-loaded with essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no output schema, no annotations), the description adequately covers what the tool does, when to use it, what it returns, and argument examples. Complete for an agent to select and invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. The Args section provides example values for material (PLA, PETG, etc.) and context from the main description (printer-specific, chosen material). Adds meaning beyond bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves printer-specific slicer settings for an already-chosen material, using a specific verb and resource. It distinctly differentiates from sibling tools like recommend_material by instructing use after material selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use AFTER selecting a material' and directs to recommend_material or recommend_design_material for choosing materials, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool is a read operation returning specific fields, which is sufficient for a simple getter. However, it could mention any implications of caching or freshness of data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the purpose stated in the first sentence, followed by a bulleted list of return fields. Every sentence adds value, and there is no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 is complete: it explains what the tool does, the scope (Bambu Lab printers), and the full return structure. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100% (trivially). The description adds value by detailing the return values beyond the schema, which consists of an empty object. Baseline for 0 parameters is 4, and the description exceeds that by providing field descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current speed profile, specifies it's for Bambu Lab printers, and lists the exact return fields (level, name, speed_magnitude). This distinguishes it from sibling tools like 'set_speed_profile'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use this tool to check the current speed before adjusting it with 'set_speed_profile()', providing clear when-to-use guidance and a direct reference to an alternative tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the single-use token behavior and dependencies between parameters (e.g., save_profile_decision required when shipping_address is provided). However, it does not explicitly state whether the tool has destructive or irreversible effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured as a docstring with a clear purpose statement and parameter list. It front-loads the key usage instruction and uses concise, direct language. Every sentence adds value, and the length is justified by the number of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 9 parameters, no output schema, and no annotations, the description is quite thorough. It covers parameter interactions and the workflow context (post-confirmation). However, it lacks details about the return value (e.g., token string) and potential error conditions, which could affect agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds detailed semantics for nearly all 9 parameters. It explains conditions like 'Required when shipping_address is provided' for save_profile_decision, and provides context for each parameter (e.g., default TTL, saved profile usage). This greatly aids an AI agent in correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Issue a single-use token after the user confirms shipping details,' providing a specific verb and resource. It distinguishes from sibling tools like issue_preview_token by focusing on shipping confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to call: 'Call this only after showing the normalized contact/shipping address and selected shipping option to the user... and receiving approval.' It also explains the consequence of not calling it: 'fulfillment_order refuses to place an order without this token.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses several important behaviors: the loop stops when validation passes or max_iterations is reached, it returns the best result, it writes a sidecar file when brief_id is supplied and a mesh is produced, it skips silently if kiln-pro is absent, and it opens an interactive 3D stage with automatic decimation for large meshes. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose but well-structured: a concise process summary, then a parameter block, then a behavioral note about the 3D stage. Every sentence provides useful context, though the inline restructuredText parameter documentation could be slightly more compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the algorithm, all parameters and defaults, the return value ('Dict with best result and iteration history'), side effects (sidecar file, 3D stage), and edge cases (best-effort skip, decimation). Given no output schema, this is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes a full :param list for all six parameters, with defaults, types, and conditional semantics (especially brief_id's side-effect behavior). This adds substantial meaning beyond the schema's bare property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear process definition ('Automated design iteration: generate -> validate -> improve -> regenerate') and explains the closed-loop behavior, distinguishing it from single-shot generation or validation tools. The title and description together make 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states when to use the tool ('Runs a closed loop...') and specifies the stopping conditions. It also gives conditional guidance for brief_id and best-effort behavior. However, it does not explicitly mention alternatives like generate_model or validate_openscad_code, only implying this tool is for iterative design refinement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does so well by revealing that the library is keyed by name, always adapts to proven settings, and has no version history. It also states the return shape (dict with decoration count and list), which gives useful behavior beyond a simple 'list' label.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than a simple tool needs, but nearly every section earns its place: the intro sentence, filter documentation, return info, and the critical distinction from presets. It is thoughtfully structured with clear paragraphs and front-loaded intent. A minor redundancy exists between 'List all' and 'Browse...', but it does not detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has only three optional filter parameters, no output schema, and no annotations, so the description is the only practical guidance. It covers the purpose, parameter semantics, return value, and a key domain distinction (library vs preset) that materially affects tool selection. This is fully 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% because the input schema only has bare string properties with default empty values. The description fills this entirely by documenting all three filter parameters, including valid content_type values ('photo', 'svg', 'qr', 'text', 'procedural_texture', 'ai_texture') and category meanings. This is more helpful than typical schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'List all saved decorations in the library,' naming the exact resource and action. It explicitly contrasts this with decoration presets and points to list_decoration_presets/apply_decoration_preset, making it easy to distinguish from similar catalog-style tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states this is for browsing the decoration library, with filters, and adds a when-not-to-use directive: 'if what you want isn't here, look there' (to presets). It also explains the conceptual difference between library and preset, so an agent can select the right tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it's a list operation from a 'bundled safety database,' implying read-only. No contradictions. Lacks details on auth or rate limits, but for a simple list that's acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three sentences with no wasted words. Information is front-loaded and structured logically.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and a straightforward operation, the description fully explains the purpose and suggests related tools. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so the description cannot add parameter meaning. Schema coverage is 100%. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available printer safety profiles, returning profile IDs and display names. It distinguishes itself from siblings by naming 'get_safety_profile' and 'validate_gcode_safe' as subsequent tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool and provides alternatives: 'Use with get_safety_profile to inspect limits' or 'validate_gcode_safe to validate commands.' This gives clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the tool lists all bundled profiles and returns specific fields, including license tier requirements. It does not mention any edge cases, pagination, or rate limits, but for a list operation, the description is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, each earning its place: first states purpose, second lists return fields, third gives usage guidance. It is front-loaded with the main purpose and uses no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless list tool, the description completely covers what the tool does and what it returns. It explains the output fields (IDs, display names, recommended slicer, license tier) and how to use the results with other tools. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (empty schema). According to guidelines, baseline is 4. The description adds no parameter information because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists bundled slicer profiles for supported printers, specifies the returned fields (IDs, display names, recommended slicer, license tier), and distinguishes from siblings by mentioning get_slicer_profile for full settings and slice_model for auto-profile selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use the tool (to list all bundled slicer profiles) and provides guidance on subsequent actions: use with get_slicer_profile for full settings or slice_model with printer_id for auto-profile selection. This clearly differentiates from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the operation is a read (Show/Returns), mentions configuration via environment variables, and adds a safety note about unverified community-uploaded models. This provides good context beyond a simple listing, though no details on rate limits or permissions are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at four sentences, with front-loaded purpose, clear structure, and no superfluous content. The safety note is separated and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully covers its purpose, configuration, alternatives, and safety considerations. It is complete and actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is trivially complete (schema coverage 100%). The description does not need to add parameter details. The baseline for 0 parameters is 4, and the description adds no unnecessary information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with a clear verb-resource pair: 'Show which 3D model marketplaces are connected and available.' It differentiates from sibling tools marketplace_status and marketplace_diagnostics by referencing them in the 'See also' section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explicitly states when to use this tool (to list connected marketplaces and their capabilities) and gives alternatives for more specific diagnostics: marketplace_status for per-credential diagnostics and marketplace_diagnostics for live connectivity probes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses the side effect of opening an interactive 3D stage, automatic mesh decimation, and the full return payload structure (best_params, best_score, best_grade, etc.). This goes well beyond basic operation and helps the agent anticipate consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, beginning with a one-sentence summary, then a mechanism explanation, a usage hint, and param docs. It could be slightly tighter, but every section earns its place given the tool's complexity and the need to document side effects and return values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (5 params, no output schema, no annotations), yet the description covers the workflow, parameter details, return values, and even the inline 3D stage side effect. An agent has everything needed to invoke the tool correctly and understand the result without additional documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides :param lines for all five parameters, explaining template_id, samples_per_param, max_variants, constraints, and output_dir with a JSON constraints example. This fully compensates for the missing schema descriptions and adds meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find the structurally strongest version of a parametric template.' It then explains the mechanism (sweeping parameters, generating combinations, running structural analysis) and clearly distinguishes itself from siblings like analyze_structural_risks or iterate_design by focusing on automatic parameter optimization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use this when you want to automatically find optimal dimensions for a functional part,' with a concrete example. It does not explicitly mention alternatives or exclusions, but the use case is clear enough to guide selection among the many sibling design tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It goes far beyond basic behavior: it details firmware-specific heater behavior with measured data, explains the keep-alive daemon thread, its idempotence, and when it stops. This is exceptional transparency beyond what annotations could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence carries substantive information about behavior, firmware differences, measured data, and thread management. It is structured with clear sections (general behavior, firmware notes, keep-alive, args). While verbose, the density of unique details justifies the length; it is not padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (firmware variability, temperature management, background threads) and absence of annotations and output schema, this description covers all essential aspects: what happens, why it happens, how to control it, and how to resume. It is fully self-sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain both parameters. It thoroughly explains keep_temps: default, behavior, idempotence, and what happens when False. It explains printer_name: which printer, default, and that each printer gets its own thread. The description adds substantial meaning beyond the schema's bare type/default info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pause the currently running print job' and elaborates on the action (lifting nozzle, parking head). It distinguishes itself from siblings like cancel_print and resume_print by describing the pause action and its implications, 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.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the behavior and how to resume (use resume_print), but does not explicitly state when to use pause versus cancel or emergency_stop. It provides context about the keep-alive behavior and firmware differences, which implicitly guides usage, but lacks explicit exclusions or alternatives beyond resume.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently discloses the entire workflow: validation, scaling logic, simplification/hollow recommendations, re-validation, and combined before/after comparison. It also discloses side effects, such as opening an interactive 3D stage and automatic decimation for oversized meshes. It explicitly warns that the PNG preview is not the whole experience, covering user expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured, with a numbered pipeline and inline bolded steps. The opening sentence is a clear summary, and subsequent details are organized. While it is extensive, every section adds necessary behavioral or procedural context, and the effective use of lists keeps it scannable. It is slightly verbose but not overly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multi-step pipeline, unit conversion, interaction with 3D stage, return data), the description is complete. It covers all major aspects: input types, supported formats, each pipeline step, parameter semantics, return value structure, and the interactive stage behavior. There is no output schema, so the description appropriately provides the return contract.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully explains all four parameters. It provides detailed semantics for input_path, target_height_mm (with instruction that it is honored at any starting size), printer_id for bed-fit checking, and material with default 'PLA'. It also covers the return value structure. This compensates fully for the schema's bare definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Prepare any AI-generated model for printing — fixes the unit mix-up.' It specifies the target resource (AI-generated models) and the key action (unit correction), and distinguishes itself from general validation tools by mentioning the pipeline and the specific unit fix. Siblings like validate_and_prepare are broader, while this focuses on AI generator exports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use it: for models from AI generators (Meshy, Tripo, etc.) that often have meter/millimeter confusion. It also clarifies the scaling logic: only applies a unit correction when exactly one real conversion fits, never guessing. It implicitly contrasts with general validation by naming specific generators and the unit-fix purpose, though it does not explicitly name alternatives like validate_and_prepare_mesh. The context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains that the tool analyzes functional requirements and returns recommendations with reasoning, warnings, and alternatives. It doesn't mention side effects, but given the tool is read-only, the description adequately covers behavior. Lacks details on error handling or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a short purpose sentence, a brief paragraph on what it does, a clear 'Which material tool to use' section, and parameter explanations. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a recommendation tool with 4 parameters and no output schema, the description explains parameters and sibling tools thoroughly. It mentions return elements (reasoning, warnings, alternatives) but could elaborate on the return structure. Still, it provides sufficient context for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the tool description fully compensates by explaining each parameter's meaning and usage (e.g., `requirements` with example, `printer_has_enclosure` with material needs). This adds critical value beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb (Recommend) and resource (material for engineering/functional parts). It differentiates from siblings via a dedicated section, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly outlines when to use this tool versus `recommend_material` and `suggest_material_for_order`, providing clear usage context and alternatives. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With NO annotations provided, the description carries the full burden and exceeds it: discloses safety validation rejecting dangerous temps, the 0.75 confidence threshold for auto-classification storage, the material_type backfill hierarchy, idempotent re-call semantics, the evidence-vs-verdict distinction for print_error vs failure_mode, and that '0 and unset both store NULL'. Exceptionally rich behavioral disclosure that no annotation set could replace.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure: bolded section headers (Safety, Decoration feedback, Auto-classification) and a clean typed Args block that front-loads the core purpose. It is long, but justified by 17 parameters at 0% schema coverage. Only minor deduction for the print_error paragraph's rambling conversational tone ('against the day there are enough of them to ask') that could be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 17-parameter tool with no output schema, no enums, and no annotations, the description is remarkably self-sufficient. Every parameter is documented, return behavior is disclosed (auto_classification echoed in response), storage side-effects are explained (decoration counters), and edge cases are anticipated (material stays unset rather than guessing, lower-confidence guesses not persisted). Nothing meaningful is left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% — the schema merely gives titles like 'Job Id' and 'Outcome'. The description dramatically compensates by documenting every one of the 17 parameters, including exact enum values for outcome, quality_grade, and determined_by, the material backfill precedence chain, the auto_resolve behavior for printer_name/file_name, and the nuanced print_error semantics. This is precisely what parameter documentation should do when the schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource statement ('Record the outcome of a print for cross-printer learning') and immediately clarifies its place in the ecosystem ('agent-curated quality data — separate from the auto-populated print history'). Clearly distinguishes from sibling tools like monitor_print and the various analyze_* tools by describing the learning database purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Strongly establishes when to use the tool: manual outcome recording, opt-in auto-classification, and the auto_recorded terminal-state hook path where 'the most recent call wins'. However, it never explicitly names alternative tools (e.g., analyze_print_failure, monitor_print) or gives 'use X instead' guidance, so the when-not-to 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses deprecation, the single-angle limitation, and the wrapper nature. It could mention return format or error behavior, but overall transparent about its capabilities and shortcomings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the most critical information (deprecated, recommended alternative) followed by a brief Args section. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers the tool's purpose, parameters, limitations, and provides clear guidance to avoid it. It does not specify the output format, but given the deprecated status and preference for visualize_model, this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates with an Args section explaining each parameter: file_type examples for file_path, default values for width/height, and a hex color example for color.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool renders a model preview, is deprecated, and distinguishes itself from the preferred alternative 'visualize_model' by noting it renders only 1 angle with fewer features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly advises against using this tool, recommending 'visualize_model' instead, and provides specific reasons (multi-angle, auto-framing, colored 3MF, quality scores) for preferring the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations provided, the description correctly carries the full behavioral disclosure burden and does so extraordinarily well: it reveals the 0.1 µm weld radius and why ('scanned and AI-generated meshes routinely carry float rounding jitter'), the destructive default of overwriting the input, the rollback-and-report safety mechanism ('a closure that collapses the enclosed volume is rolled back with the reason in unrepaired'), the refusal semantics, and the visible side effect of opening the inline 3D stage. No annotation contradiction exists since no annotations are present; this is a masterclass in honest documentation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently front-loaded with a one-line summary followed by a short why-explanation for the welding step, then the algorithmic passes, safety, return contract, and finally the structured param block. Dense but nearly every sentence earns its place; only minor verbosity remains in the parenthetical 'or a millionth of the part diagonal' aside and the 'refuses rather than ruins' framing, though the latter also conveys useful non-guarantee semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with both file-mutating side effects (default overwrite) and a GUI side effect (3D stage), zero annotations, and no output schema, the description covers everything an agent must know: the exact return-contract keys (is_watertight, enclosed_volume_mm3, unrepaired), the failure domain (pinch edges it refuses to certify), performance characteristics, and error semantics. No meaningful information gap remains for an agent to fill by guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
At 0% schema description coverage, the description must document everything — and it does: file_path's STL type, the overwrite-by-default behavior of output_path, close_holes' performance cost, and weld_tolerance's unit, auto-scaling ('a millionth of the part diagonal'), and the "0" disables-welding sentinel. The docstring param block is the only place an agent could learn these semantics since the input schema only contains bare property names; the description more than compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence states a specific verb+resource+defect set ('Repair mesh defects: rounding-noise seams, degenerates, holes'), localizing the tool in seconds. It then distinguishes the standard repair path from diagnostics found in siblings — this is the fixer, while tools like diagnose_mesh / analyze_mesh_geometry are inspection-only, and the explicit defect-class enumeration leaves no ambiguity about the resource being acted on.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear contextual guidance is given for pass selection ('use it when the mesh is not watertight') and for what the tool will not do ('pinched edges... must be fixed where the geometry was made'), which constitutes useful when-not guidance. No sibling tool is named explicitly (contrast with a 'use search_calls_extensive for user/workspace filtering' pattern), and with repair_mesh_advanced in the same namespace a one-line pointer would have cinched a 5; nevertheless the deep-vs-default decision rule is explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It details the one-shot pipeline (validate mesh → resolve profile → slice → safety check → upload → start print), mentions validation and safety checks, and explains the overrides format. However, it does not disclose failure handling, cancellation behavior, or performance characteristics, leaving minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: a concise intro, usage pivot, pipeline summary, overrides details, prerequisites, and then parameter explanations. Every section adds value, though some details (like all common override keys) could be condensed. Overall, it's efficient for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description provides near-complete context. It covers the tool's purpose, when to use vs alternatives, the full pipeline, parameter semantics, prerequisites, and safety checks. The only missing element is explicit return value, but that is acceptable since no output schema exists and the tool initiates a print.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description compensates fully by explaining all 10 parameters in detail. It provides the overrides JSON format with examples, lists common override keys organized by category, and describes each argument's purpose, including nuances like AMS auto-detection and validation bypass. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Reslice with custom slicer overrides + print (use for retries with adjusted settings)', which clearly states the tool's action and primary use case. It also distinguishes itself from the sibling tool 'run_quick_print' by specifying when to use each, providing strong purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Use this when you need to tweak slicer parameters... For standard prints without overrides, use run_quick_print instead.' It also lists prerequisites (PrusaSlicer/OrcaSlicer installed, printer idle and connected) and outlines the pipeline steps, offering comprehensive usage guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it excels: it discloses that the declaration is local-only, never uploaded or pooled, ignored on multi-tenant deployments, and that Kiln cannot remotely verify the hardware. It also explains that selecting a variant asserts firmware/part prerequisites have been satisfied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but front-loaded with the core purpose and each paragraph adds substantive caveats or behavioral details. Some phrasing could be tightened, but every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool with no annotations or output schema: it covers when to use it, prerequisites, side effects, persistence, multi-tenant behavior, parameter meaning, and how to reset. The return behavior is sufficiently implied by 'Kiln supplies the limit.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains both parameters: printer_model is a printer identifier with an example, and variant_id comes from list_printer_variants with '' meaning return to the as-shipped profile. This adds real semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Declare which curated hardware variant your machine actually is.' It further explains that Kiln supplies an enforced ceiling from curated data and explicitly distinguishes itself from a tool that accepts a temperature value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives strong usage context: an operator with a modified printer uses this to get an accurate ceiling without typing one, and should check the variant's 'requires' first. It points to list_printer_variants for valid variant IDs and warns that selection is a statement that preconditions are met, though it does not explicitly name alternative tools besides that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does an excellent job. It discloses the off-by-zero behavior, the leave-unchanged on null, the historical default-printer pitfall, and the safety-ceiling rule based on the named printer's declared model. This goes far beyond a typical setter and gives the agent crucial behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, Args section, and common temperature ranges. Every sentence provides useful information, and the length is justified by the complexity of the tool's safety and multi-printer behavior. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, parameters, edge cases, and even includes practical temperature guides. However, it does not mention the return value or failure/error behavior, and since there is no output schema, the agent might not know what to expect as a result. Still, for a setter tool, this is a minor gap given the strong behavioral coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates fully. Each parameter is explained in detail: tool_temp and bed_temp semantics (0 turns off, null leaves unchanged), and printer_name's role in targeting and safety calculations. The 'at least one' constraint is also explicitly stated, adding meaning that the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Set the target temperature for the hotend (tool) and/or heated bed.' This unambiguously distinguishes it from sibling tools like set_fan or set_speed_profile, and clearly states both the hotend and bed as targets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to set hotend/bed temperatures) and provides critical usage context: the requirement that at least one temperature be provided, the 0-to-turn-off behavior, and the multi-printer behavior with the default printer and safety-ceiling gotcha. It does not explicitly name alternative tools for exclusions, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral disclosure: it states the algorithm (vertex-clustering decimation), the output nature (lower-resolution same shape), return values, output file default, and the interactive 3D stage behavior including automatic decimation of oversized meshes. This is richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then provides structured param docs and a separate behavioral note. It is longer than minimal but every sentence adds value; the inline 3D stage paragraph could be tightened but is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a 3-parameter tool, the description covers all essential context: purpose, algorithm, parameter semantics, return contract, output path behavior, and the unusual interactive stage side effect. It is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description documents all three parameters with meaningful detail: file_path is the STL path, target_ratio is a 0.01–1.0 fraction, and output_path defaults to `<name>_simplified.stl`. It also describes the return dict, fully compensating for the sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Reduce mesh triangle count for faster preview or smaller files,' clearly distinguishing this from the many mesh-related sibling tools. It also identifies the decimation technique and the resulting lower-resolution version of the same shape.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: use when you need faster previews or smaller files. It does not explicitly name alternatives or exclusion conditions, but among the large sibling set, the stated goal sufficiently implies when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior. It details the combined actions, the automatic brim/raft behavior, the validation gate and skip_validation, and the print_start outcome values ('started', 'accepted', 'failed') with their meanings and when success is false. This is comprehensive and transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with clear sections (overview, alternatives, adhesion, validation, parameters, print_start branching). While detailed, it avoids redundancy and each part serves a purpose. It is appropriately sized for a tool combining three actions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides extensive context, including behavior, parameter semantics, and return outcomes via print_start and success. It lacks explanations for auto_center and preview_token, and there is no output schema, but the description compensates well for most aspects. It feels nearly complete but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains most parameters: input_path, printer_name, profile, printer_id, material, metadata (including recognized keys), and skip_validation. However, it omits explanations for auto_center and preview_token, leaving these parameters undefined in the text. Coverage is strong but not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Slice a 3D model (STL/3MF) + upload + print in one step' and explicitly mentions it combines slice_model, upload_file, and start_print. It also differentiates from siblings by recommending run_quick_print for comprehensive pipelines and run_reslice_and_print for custom overrides.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use alternatives: 'For a more comprehensive pipeline... use run_quick_print. For custom slicer overrides, use run_reslice_and_print.' It also explains conditions for adhesion analysis and validation bypass, giving clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that checks run periodically, alerts are generated on anomalies, and that the number of concurrent watches depends on the plan. Additional context about manual checks not being limited adds transparency. It does not elaborate on alert delivery or error handling, but the coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the primary purpose, followed by supporting details. It includes plan limitations and parameter documentation, with a 'See also' section for related tools. While a bit long, every sentence contributes value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (continuous background process with plan limits), the description is complete. It explains what it does, when to use it, its limitations, parameters, and related tools. No output schema is needed for a start-monitoring action, and the description covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly documents both parameters: 'printer_name: Printer to monitor' and 'interval_seconds: Seconds between health checks (default 30).' This adds meaning beyond the bare schema and fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Start continuous background health monitoring for a printer.' It details what the monitoring covers (connectivity, temperature stability, print job health, error detection) and distinguishes it from manual checks and sibling tools like check_printer_health and stop_printer_health_monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: explains plan limits (one watch on Free and Pro), clarifies that manual checks (printer_status, monitor_print, printer_snapshot) are never limited, and recommends alternatives. It also points out how to stop monitoring via the sibling tool, making the decision context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral disclosure. It covers queue depth limits, scheduling behavior, priority ordering with FIFO tie-breaking, idempotency semantics including replay responses and rejection on key misuse, and the requirement that the file must already exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well structured: use-case summary first, then tier constraints, per-argument semantics, scheduling order, and related tools. Every sentence adds useful information without unnecessary filler, and the idempotency explanation is detailed but necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description compensates well by explaining job queue behavior, ordering, retry semantics, and follow-up tooling. However, it never describes what a normal successful submission returns (e.g., whether a job ID is issued), so an agent may lack some clarity about the direct response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description gives detailed meaning to each of the four parameters: file_name prerequisite, printer_name selection behavior, priority ordering semantics, and the crucial idempotency_key retry/replay contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a direct verb-object statement: "Submit a print job to the queue." It specifies the resource (print job queue), the action (submit), and clearly separates this submission tool from follow-up tools like job_status and queue_summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete context about tier limits, single vs multi-printer scheduling, retry behavior, and points the agent to job_status for progress and queue_summary for overview. It does not explicitly exclude alternative submission tools like fleet_submit_job or route_print_job, but it describes the queued-job context well enough for most selection decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behaviors: it validates against material limits, compiles a new STL, and opens an interactive 3D stage with mesh decimation. It clarifies that the PNG preview is not the full experience, which is critical side-effect information not inferable from the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: opening action, workflow summary, concise argument list, then a note about the inline 3D stage. Each sentence adds value, and the key use case is front-loaded. No filler or redundant statements, making it appropriately sized for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, parameters, and side effects (3D stage). It also mentions material validation, which is important. However, it does not explicitly state the return value or output format (e.g., whether it returns an STL file or a link), which could be inferred from the stage mention but is not explicit. Given no output schema, a bit more on the return would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage (no descriptions), but the description includes an Args section explaining each parameter: scad_code (OpenSCAD source), parameter_name (variable name with example), new_value (numeric), material (optional with example). This fully compensates for the schema's lack of detail, exceeding the baseline by providing concrete examples and purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update a parameter in OpenSCAD code and recompile to STL' with a specific verb and resource. It also emphasizes the combined workflow of changing a dimension, validating material limits, and compiling, which distinguishes it from sibling tools like update_scad_parameter or compile_scad that perform only one of these steps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context with 'Perfect for "make it 5mm wider" requests,' indicating when to use it. However, it does not explicitly mention when NOT to use it vs. alternatives (e.g., 'if you only need to update without compiling, use update_scad_parameter'), so there is some implicit guidance but no exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes return format (JSON with valid, commands, errors, warnings, blocked_commands) and states it performs generic safety checks. No annotations provided, but description adequately covers behavior for a validation tool. Could mention if it has side effects (likely none), but that's implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two clear paragraphs: first explains purpose and sibling differentiation, second details parameters and return values. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 fully explains what the tool does, what input it expects, what output it produces, and how it relates to other tools (send_gcode, validate_gcode_safe). Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% description coverage, but description explains the single parameter 'commands' as G-code commands separated by newlines, adding meaning beyond the schema type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it validates G-code syntax and basic safety, and distinguishes from sister tool validate_gcode_safe for printer-specific validation. The verb 'validate' and resource 'G-code' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says use for generic validation, and for printer-specific safety use validate_gcode_safe. Also advises to preview what send_gcode would accept/reject, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return structure (compatibility status, upgrades, notes), implying a read-only operation without side effects. However, it does not explicitly state it is side-effect-free or mention any authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (three lines plus parameter details), well-structured with a header, return info, see-also, and parameter section. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, no annotations, and no output schema, the description covers all essential aspects: purpose, usage context, parameters, return values, and an alternative tool. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It provides clear, example-rich descriptions for both parameters, including an explanation for why material_id is required. This adds significant meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks printer support for a specific material, with a verb ('check') and resource ('printer material support'). It distinguishes itself from the sibling 'check_printer_material_compatibility' by noting the difference in context and suggestions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'See also' section explicitly points to an alternative tool for design-intelligence context, telling the agent when to use this tool vs the sibling. The parameter note about not enumerating the full matrix also guides usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses key behavioral facts: no boolean operations, output format is STL, returns a dict with stats, opens an inline 3D stage, and auto-decimates oversized meshes. It even clarifies the PNG preview is not the whole experience.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, see-also, parameter docs, and a dedicated inline-stage section. It is somewhat long, but each part adds value; however, the INLINE 3D STAGE paragraph could be condensed without losing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and moderate complexity, the description covers all critical aspects: operation semantics, parameter meanings, return type, side effects (3D stage), and differences from close alternatives. It is sufficiently complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by defining file_paths as 'List of .stl/.obj/.glb file paths' and output_path as 'Path for combined output STL.' This adds format and purpose beyond bare schema names, though it could specify details like extension handling or path behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Merge multiple mesh files into a single combined model.' It further clarifies the operation ('Concatenates all triangle geometry... into one output STL') and explicitly distinguishes from sibling tools via 'See also: merge_mesh_files... or merge_stl...'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context ('Useful for multi-part assemblies or adding components to a design') and names alternatives with differentiators ('merge_mesh_files for the same operation with a different parameter style, or merge_stl for positional offset support').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the safety default change with a specific incident reference, explains the centering behavior and its implications for FDM printers, and describes the output behavior including the inline 3D stage and decimation. It also notes the return values (result path, SCAD code, triangle count, bed_centered flag). This is rich behavioral context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (CAD-aware generation path, safety default, operation format, primitive shapes, requirements, params). It front-loads the core purpose and then provides necessary detail. Some redundancy exists (e.g., repeating the safety incident), but it's justified for emphasis. It earns its length given the complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested operations structure, no output schema), the description is remarkably complete. It covers the operation tree format, all primitive shapes, the safety-critical centering behavior, the OpenSCAD dependency, and the return value structure. It even mentions the inline 3D stage behavior. There's no output schema, so the description's explanation of returns is essential and provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does: it explains the 'operations' parameter in detail with the operation format and all primitive shapes and params. It also explains 'center_on_bed', 'bed_x_mm', 'bed_y_mm', and 'printer_id' semantics. However, it doesn't explicitly describe 'output_path' beyond 'defaults to temp file', which is minor. The description adds significant meaning beyond the schema's bare property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Build a functional part by composing geometric primitives with booleans.' It specifies the verb (build/compose), the resource (functional part from geometric primitives), and the method (boolean operations). It distinguishes itself from sibling tools like 'compose_assembly_parts' and 'compose_models' by focusing on primitives and booleans, and from 'boolean_mesh_op' by being CAD-aware and deterministic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'instead of asking text-to-mesh AI to guess at geometry, describe parts as a tree of primitives combined with boolean operations.' It also explains the safety default and when to set center_on_bed=False ('only if your downstream flow expects origin-centered geometry'). It mentions the requirement of OpenSCAD installed, which is a prerequisite. It doesn't explicitly name alternative tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full burden. It discloses that the tool executes a previously requested action and explains the token mechanism. No contradictions or hidden behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear purpose statement, conditional context, and a parameter docstring. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool with no output schema, the description fully covers purpose, usage, and parameter meaning. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter description (0% coverage). The description compensates by explaining 'token' as 'The confirmation token returned by the original tool call,' adding essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute a previously requested action that requires confirmation,' which is a specific verb+resource. It distinguishes itself from siblings by explaining the unique confirmation mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use this tool: 'When KILN_CONFIRM_MODE is enabled, destructive tools return a confirmation token... Pass that token here.' It provides clear context and behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it downloads and uploads only, does not start printing, warns about physical damage, and specifies behavior for different parameter combinations (single file vs all printable files). It also notes that Cults3D does not support direct downloads.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement, a warning block, parameter descriptions, and a final instruction. Every sentence serves a purpose, and the most critical information (download and upload, no auto-print) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description provides complete coverage of functionality, parameter semantics, usage guidance, and behavioral caveats. It leaves no significant gaps for an AI agent to misinterpret.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains all four parameters: file_id (with marketplace-specific examples), model_id, source (with default and unsupported marketplace), and printer_name (with default behavior). This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool downloads model file(s) from any marketplace and uploads to a printer, distinguishing between single file and all printable files. It also explicitly notes that it does not start printing, which differentiates it from similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use file_id vs model_id, explains the default source, and warns about community models. It also instructs the user to call start_print separately. However, it does not explicitly mention when not to use this tool or list alternative tools for printing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It discloses the return content (list of printer snapshots with name, backend type, connection status, operational state, temperatures), error handling (failed printers are reported offline rather than raising), and a side effect (auto-registers current adapter as 'default' if no printers exist).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, but it is somewhat lengthy due to extensive alternative guidance. Each sentence adds value, yet the text could be tightened without losing clarity, so it earns a 4 rather than a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is complete: it explains what the tool returns, error behavior, the auto-registration side effect, and how it differs from related tools. It also implies tier gating by noting alternatives are not tier-gated, providing sufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter details. The description adds no parameter semantics; however, with 0 params the baseline is 4, and the description does clarify the tool's scope (all fleet printers).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool's purpose: 'Get live status of all fleet printers (state, temps, connection — current snapshot).' It includes a specific verb and resource, and explicitly distinguishes from sibling tools by noting the multi-machine view is a fleet feature and naming single-printer alternatives like printer_status, printer_snapshot, and monitor_print.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: for one printer, use printer_status/detail='lite' or printer_snapshot or monitor_print; for historical analytics use fleet_analytics; for grouping by physical location use fleet_status_by_site. This clearly tells the agent when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: upload process, return values (pricing, lead time, shipping), fee breakdown, and the payment hold/capture mechanism. This is comprehensive and goes beyond minimal expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and concise: it opens with a clear purpose statement, follows with parameter documentation, then describes behavior and return values, and ends with a usage directive. Every sentence serves a purpose, and the information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is contextually complete for a quote-gathering tool: it explains the entire flow from input to output, including the payment hold mechanism, fee breakdown, and next step (use fulfillment_order). It does not explicitly mention error handling, but the depth of behavioral context compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description bears the full load. It provides clear parameter descriptions including source for material_id ('from fulfillment_materials'), unit for quantity, and format for shipping_country (ISO code). This adds significant semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get quote') and resource ('for a 3D model from Craftcloud'). It differentiates from sibling tools like fulfillment_order and fulfillment_materials by explaining the workflow: use this to get a quote, then use fulfillment_order to place the order.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is the first step in the fulfillment workflow, and it directs the user to use the returned quote_id with fulfillment_order. However, it does not explicitly exclude use cases like cached quotes, which a sibling tool addresses. Thus, guidance is good but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the external AI provider call, auditing for printability, corrective retries, the NO_PROVIDER failure mode, provider-specific behavior (auto, openscad rejection), and the inline 3D stage behavior including mesh decimation and the caveat that the PNG preview is not the full experience.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (core purpose, usage guidance, provider notes, no-provider fallback, Args, and 3D stage behavior). There is some redundancy around the fallback path being mentioned more than once, but the repetition reinforces a critical decision rule and is acceptable given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter semantics, edge cases, provider behavior, and post-success UX exceptionally well. The main gap is that it does not explicitly describe the tool's exact return value or output format beyond mentioning generated files and a preview, which could matter for an agent deciding how to use the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the Args section compensates by explaining every parameter: requirements, provider with its allowed values, material with an example, printer_model, timeout, max_attempts, build volumes, nozzle diameter, layer height, and max_overhang_angle. This adds real semantic meaning beyond the raw schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening sentence clearly states a specific verb and object: "Generate a printable design via an external AI provider." It further distinguishes itself from alternative tools like compile_scad and identifies itself as the cloud provider-backed generation path, so there is no ambiguity about what the tool does or how it differs from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use and when-not-to-use guidance: "This is NOT the default," use compile_scad for most custom objects, and "Reach for this tool when the shape is organic or photo-derived... AND a provider is configured." It also names design_session as the correct entry point for the saved-goal flow and instructs agents to fall back to OpenSCAD rather than asking users for an API key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses fallback behavior when printer_id is not found, explains the owner_supplied and limits_provenance fields, and gives an important usage instruction about quoting limits with appropriate authority.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded. Every sentence earns its place, including the provenance guidance, and the Args section is cleanly formatted without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, but the description lists the returned fields, fallback behavior, and provenance semantics. This is sufficient for an agent to invoke the tool and interpret results correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully compensates by defining printer_id as a 'Printer model identifier' and providing concrete examples like 'ender3', 'bambu_x1c', and 'prusa_mk4'. This adds meaning well beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get the full safety profile for a specific printer model.' It clearly distinguishes itself from sibling tools like list_safety_profiles by targeting a single model and returning the full profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need the full safety profile for a specific printer model. It does not explicitly name alternatives or exclusions, but the 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so burden is on description. It thoroughly explains that the tool only reports and does not intervene, that Kiln does not automatically pipe G-code through, and that sessions may have coverage_warnings affecting result interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with bullet points and clear sections. Every sentence adds value, though some redundancy could be trimmed. Front-loads the core purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that output schema exists, descriptions of return values are unnecessary. The description covers session limitations, coverage warnings, and the five possible actions, making it complete for a tool that checks one G-code line.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with only parameter names and types. The description adds meaning by defining session_id as 'Active interception session ID' and command as 'Raw G-code command string' with examples, providing necessary context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks a single line of G-code for danger before sending to a printer. It distinguishes itself from sibling tools like validate_gcode and validate_gcode_safe by focusing on interception and safety rules specific to a session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use ('call on each line before sending') and what to do with each result (allow, block, modify, pause, alert). Also mentions alternative tools like start_gcode_interception for session setup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that it is one-shot, returns a fixed-format text, includes snapshot behavior, and notes best-effort behavior for brief_id (silent skip on failure). It does not explicitly state read-only nature, but 'status report' strongly implies no 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, usage guidance, and parameter documentation. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and an output schema, the description covers purpose, usage, return format (progress, temps, speed, errors, cost estimate, camera snapshot, health commentary), parameter behaviors, and distinguishes two sibling tools. The presence of an output schema means return structure is covered elsewhere.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters (printer_name, include_snapshot, brief_id) are explained with meaningful context beyond the schema's bare titles. The :param lines clarify defaults and behavior (e.g., 'Omit for default', 'Best-effort: a missing kiln-pro install... silently skips the line'). Schema coverage is 0%, so description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'one-shot print status report' returning human-readable text with specific fields. It distinguishes itself from two sibling tools: monitor_print_vision (structured data + AI vision) and watch_print (persistent monitoring).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use for quick status checks' and provides when-not-to-use guidance with alternatives: 'For structured data + AI vision inspection, use monitor_print_vision. For persistent background monitoring, use watch_print.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden — and it delivers. It discloses environment requirements (slicer binary, idle printer, loaded AMS), side effects (none to hardware; produces a 3MF), the Bambu Studio behavior of re-deriving print settings, and the requirement to relay the 'slicer_note' to the user. This goes beyond typical transparency and is highly actionable 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but meticulously structured: intro, realistic use case, bolded mode headers, prerequisites, cross-slicer caveat, then a cleanly formatted :param: block. Every sentence earns its place; even the Bambu Studio note and slicer_note handoff serve the agent's decision-making. Excellent use of formatting for scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool (8 parameters, 2 modes, no output schema, and 300+ sibling tools to disambiguate from), the description is remarkably complete: it covers mode selection logic, environment requirements, result shape (3MF, slicer_note, AMS mapping), and even user-handoff instructions. The only minor gap is no explicit return-value details, but the :returns: line plus the mention of 'slicer_note' provides reasonable coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the docstring shoulders full responsibility and succeeds: all 8 parameters are documented with type info, semantics, defaults, and concrete examples (e.g., ams_slots [0,1,2,3] and color hex strings). It fully compensates for the schema's lack of description, providing more than the input schema alone ever could.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pairing ('Print multiple copies of the same model, each in a different AMS color') and immediately grounds it with a concrete 'print 4 lids in 4 different colors' use case. It clearly distinguishes this tool from the large sibling set (e.g., multi_copy_print, multi_material_print) by scoping to AMS-slot-per-copy workflow and references specific prerequisite slicers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear, contextual usage guidance via two modes ('Auto-detect mode' vs 'Manual mode') and when to pick each, plus environment prerequisites (PrusaSlicer/OrcaSlicer installed, idle printer with AMS loaded). However, it never explicitly names alternative sibling tools for disambiguation or states when NOT to use this tool — 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It thoroughly explains the automatic steps (material lookup, arrangement, slicer overrides, AMS slot checking, slicing/printing) and clearly notes the requirement for PrusaSlicer or OrcaSlicer locally. It even discloses the Bambu Studio compatibility nuance and the slicer_note field, which is exceptional transparency for a complex operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every section earns its place: the intro, example, object field specification, automated steps, prerequisites, and args list are all directly useful. The use of code blocks and bullets enhances readability without being redundant. It is well-structured for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-step tool with no output schema, the description is remarkably complete. It covers prerequisites, parameter details, the exact JSON structure, the automated pipeline, output fields (multi_material_3mf, slicer_note), and even how to handle the artifacts (relay slicer_note to the user). The content fully equips an agent to invoke the tool correctly and understand the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description fully compensates with a dedicated Args section and an in-depth explanation of the objects_json structure, including required and optional fields with examples. It goes beyond the schema's bare type definitions by explaining the meaning and usage of every parameter, including the group behavior for coincident placement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear statement of purpose: 'Print multiple objects in different materials/colors on one build plate.' It then elaborates with a concrete example ('object A in red PLA, object B in black PETG'), making the tool's function unmistakable. This distinguishes it from siblings like multi_copy_print or multi_color_copies by focusing on per-object material assignment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a use case ('This is how you print...') and walks through the process step by step. It doesn't explicitly list alternatives or exclusions, but the context is clear enough for an agent to select this tool when multi-material per-object printing is needed. The detailed example and prerequisites add practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the exact checks performed, the effect of printer_name (state/temps/material follow the named machine), the accept_paused behavior, and the return structure (ready boolean and per-check breakdowns). This goes beyond a high-level summary and provides actionable behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence, a bulleted checklist, and a detailed Args section. Every sentence provides needed detail; there is no fluff. The front-loaded summary gives immediate understanding of the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 optional parameters, no output schema) and the safety-critical nature of the checks, the description is complete. It covers what is checked, how each parameter modifies behavior, the intended usage context (before start_print), and the return value (ready boolean and breakdowns). An agent can decide when and how to invoke this tool with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description exhaustively documents all five parameters: file_path, expected_material, remote_file, accept_paused, and printer_name, including defaults, optionality, and behavioral effects. It adds meaning far beyond the schema's bare type/default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Run pre-print safety checks to verify the printer is ready' and enumerates specific checks (connectivity, idle state, error flags, temperatures, optional material/file checks). This clearly distinguishes it from sibling tools like printer_status or start_print by naming the exact purpose and the expected follow-up call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: 'Call this before start_print() to catch problems early.' Also explains optional parameters and their applicability (e.g., accept_paused used by start_print with resume). However, it does not explicitly exclude alternatives among the many readiness-related sibling tools, so it lacks the when-not or explicit alternative guidance for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the transparency burden. It discloses side effects (output_path defaults to overwriting input), explains the algorithm (identifies connected components and removes small ones), and states the return type (Dict with removal statistics).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a brief purpose statement, a rationale sentence, and a clear parameter list. There is no redundant or vague wording, and the formatting is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity: it explains what the tool does, why it's needed, how to control behavior via parameters, and the return type. Even without an output schema, the stated return of removal statistics is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful explanations for each parameter beyond the schema: file_path as the STL path, output_path with overwrite default, keep_largest defaulting to true, and min_triangle_pct conditionally applied. All four schema parameters are covered in prose, enriching the schema's bare types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: removing small disconnected components (floating geometry) from a mesh. The verb 'remove' is specific, and the explanation about support pillars and fragments distinguishes it from other mesh operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: cleaning up downloads and marketplace models with floating geometry. It implies when to use it, though it does not explicitly compare to alternative mesh-processing tools. The parameter descriptions further clarify usage conditions (e.g., keep_largest vs. min_triangle_pct).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels: it reveals that resume returns the nozzle and continues extruding, that the printer state is verified afterward, that silently ignored commands are reported as failures, and that force bypasses the internal state check. These are non-obvious behavioral details 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-sentence summary, a short prerequisite/behavior paragraph, then per-parameter details. Every sentence contributes meaningful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter, no-output-schema tool, the description covers prerequisites, action consequences, edge cases, verification behavior, and parameter semantics. It gives an agent everything needed to decide whether and how to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no descriptions, yet the Args section thoroughly explains both parameters. force gets context for when and why to use it, and printer_name clearly states the omission default and the requirement to match the name used for pausing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb-and-resource action, 'Resume a paused print job,' and adds behavioral specificity: 'return the nozzle to its previous position and continue extruding.' This clearly distinguishes it from siblings like pause_print, cancel_print, start_print, and firmware_resume_print.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states the prerequisite that the printer must be in a paused state and explains when to use the force parameter. It does not explicitly name alternative tools or say 'use X instead,' but the context is clear enough to guide correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden of behavioral disclosure. It details steps: reads live state, analyzes geometry, auto-detects material, merges overrides, re-validates mesh, repairs if needed, re-slices, uploads, and starts print. It even explains the rationale for validation and states custom overrides win on conflict, demonstrating thorough transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose but well-structured with numbered steps and a clear Args section. While it is longer than necessary, every section adds value, and the key purpose is front-loaded. Some prose could be trimmed without loss, but overall it's organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool that initiates a print, the description covers the entire workflow, parameter semantics, bypass options, and even the rationale for mesh validation. It lacks output details but no output schema exists, and the tool's side effects (starting a print) are clear. The preview_token omission is minor but doesn't detract from overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains most parameters meaningfully: model_path, printer_name, material (with auto-detection), printer_id, custom_overrides (with JSON example), skip_diagnosis, and skip_validation (with default). However, it omits 'preview_token' entirely, leaving that parameter undocumented. Since schema coverage is 0%, this omission is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Diagnose the last print failure and re-slice + print with fixes.' It uses specific verbs and resource, and distinguishes from siblings by explicitly mentioning the manual chain of diagnose_print_failure_live → slice_and_print, clarifying it as the preferred retry path.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'When a print fails, call this tool instead of manually chaining diagnose_print_failure_live → slice_and_print.' It also explains when to skip diagnosis or validation via parameters, giving context for alternatives and bypass conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description fully discloses behavior: pipeline steps, always-on preflight checks, and AMS selection response for Bambu printers. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with numbered steps and parameter list, front-loaded with purpose. Some redundancy (step list repeats pipeline) but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with 8 parameters and no output schema, description is thorough: covers all inputs, pipeline behavior, and response details (ams_selection). No missing essential context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage); description provides detailed explanations for all 8 parameters, including context (e.g., material hint for AMS routing). Minor lack of format validation for ams_mapping.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it's the full print pipeline (validate + slice + safety-check + upload + print) and explicitly distinguishes from siblings like slice_and_print and run_reslice_and_print.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends it as the preferred one-shot tool, explains when to use alternatives (custom slicer overrides → run_reslice_and_print), and highlights added features (validation, auto-detected profiles).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses supported/unsupported printers, default values, node-specific behavior, and thermal management override. However, could mention idempotency or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose, supported printers, parameter details, usage guidance. No wasted sentences; each part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only 2 parameters and no output schema, description covers all necessary aspects: purpose, parameters, usage, constraints, and edge cases (thermal override, model-specific limitations).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% coverage, but description fully explains node values ('part','aux','chamber'), their applicability, and percent range 0-100 with defaults. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set the speed of a printer fan' and lists supported printer types. Among sibling tools like set_temperature or set_printer_light, this is uniquely for fan control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use: for cooling bridges/overhangs (part fan) or on Bambu for auxiliary/chamber fans. Also states when not to use: Prusa Link, Elegoo resin printers, open-frame Bambu for chamber fan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries behavioral disclosure. It explains the top/bottom geometry selection, clean clipping of crossing triangles, non-boolean behavior, auto-generated output path, returned dictionary content, inline 3D stage behavior, oversized-mesh decimation, and preview limitations. This is rich, specific behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses short labeled sections and every sentence adds distinct value: what the tool does, how clipping works, use case, parameter definitions, return contract, and the 3D stage behavior. It is thorough without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete: it documents all four parameters, return value shape, non-manifold support, clipping behavior, and the side-effect of opening the interactive 3D stage. Since no output schema exists, including the return dictionary and stage behavior is essential and well-handled.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description fully compensates by documenting every parameter: top_path, bottom_path, z_plane (with mm unit), and output_path (with auto-generation semantics). This adds meaning far beyond the schema's bare titles like 'Top Path' and 'Z Plane'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise action and resource: 'Splice two meshes at a z-plane', then clarifies top from one STL and bottom from another. It distinguishes from sibling tools like boolean_mesh_op and merge_stl by explicitly stating 'No boolean ops' and 'works on non-manifold meshes', making the tool's unique role clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete named use case: combine a body with the correct top (logo from v5.3) with one having the correct bottom (larger pocket from v5.4). It also implies when NOT to use boolean alternatives with 'No boolean ops -- works on non-manifold meshes', but it doesn't name alternative tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden. It discloses that the tool returns ranked recommendations with technology, reasoning, price tier, and provider. However, it does not mention any edge cases (e.g., no matching material) or permission requirements. Still, the behavior is sufficiently clear for a suggestion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear heading, usage instructions, a bulleted parameter list, and a return description. It is concise with no wasted words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, 1 required, and no output schema. The description covers all parameters, explains the return value (ranked recommendations with technology, reasoning, price tier, provider), and distinguishes from sibling tools. It is complete for the intended usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds detailed semantics for all parameters: use_case with enumerated options, budget with three values, and boolean flags. This goes well beyond the schema's minimal titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool suggests a material when ordering a print from a fulfillment provider. It uses specific verbs and resources and distinguishes itself from sibling tools like 'recommend_design_material' and 'recommend_material' by specifying the ordering context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this when routing a print job to a fulfillment provider' and provides a table clarifying which material tool to use for different scenarios, offering clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is highly transparent, detailing supported file types, the 6 camera angles, colored 3MF handling with per-face colors, adaptive background for dark models, and the inclusion of quality_score and dark_material flag in each view. It also explains that the color parameter is ignored for colored 3MF files.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with a summary, but it is relatively long. However, every sentence adds value, and markdown formatting improves readability. A slightly more compact version could be possible, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers essential aspects: purpose, parameters, return information (quality_score, dark_material flag), and usage guidance. It lacks some details like performance characteristics or concurrency, but is complete enough for a preview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema has 0% description coverage, the description fully compensates by explaining each parameter: file_path (allowed formats), angles (valid values and default), width/height (defaults and units), and color (default, purpose, and behavior with colored 3MF).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Primary 3D preview tool — renders high-quality PNGs from multiple camera angles via OpenSCAD.' It also distinguishes itself from siblings by listing alternative tools and their specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a dedicated 'When to use this vs other preview tools' section that explicitly compares visualize_model, preview_generated_model, and render_model_preview, providing clear guidance on when to use each tool. It also advises using it before printing to verify the model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and excels by detailing the background thread behavior, polling and snapshot intervals, termination conditions, and telemetry mismatch detection. All behavioral traits are clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, bullet-pointed termination conditions, and a detailed Args list. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, background monitoring, multiple termination scenarios, telemetry mismatch), the description covers all necessary aspects. It mentions the return value (watch_id) and companion tools, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides rich explanations for all 8 parameters, including defaults, effects, and examples (e.g., cancel_at_percent). This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Start background monitoring of an in-progress print,' providing a specific verb and resource. It clearly distinguishes the tool from siblings like watch_print_status and stop_watch_print by mentioning them as complementary and detailing the monitoring lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (monitoring a print in progress) and lists termination conditions including a use case for cancel_at_percent (test prints, calibration). However, it lacks explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses post-processing behavior: opens an interactive 3D stage, auto-decimates oversized meshes, and notes the PNG preview is not the full experience. Since no annotations are provided, this transparency is fully covered by the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed and well-structured with sections for purpose, compatibility, workflow, parameters, and returns. While slightly long, the example and clarity justify the length; no redundancy detected.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the tool's purpose, parameters, output format, return values, and behavioral side effects. It is comprehensive for a tool of this complexity, including notes on viewer behavior and mesh handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no descriptions, but the description thoroughly explains 'parts' (required/optional keys) and 'output_path' (default behavior). Includes a concrete example that maps parameter names to values, adding meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool composes a multi-color .3mf from multiple STL files, with a specific verb and resource. It distinguishes itself by emphasizing it produces a single print-ready file for FDM printers, differentiating from other file-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use: 'This is the correct way to send a multi-color design to any FDM printer.' Also includes compatibility details and a workflow example, making the use case unambiguous relative to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly details the exact recovery protocol: homes X/Y only, re-heats bed then hotend, sets Z position, primes nozzle, restores fan/flow settings. It also notes the outcome: 'printer will be positioned and ready after this call.'
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs and bullet points, front-loading the purpose. While every sentence adds value, it is slightly verbose; however, it remains clear and effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 11 parameters, no output schema, and no annotations, the description is very complete. It covers behavior, parameter details, prerequisites (OctoPrint+Marlin only), and post-call status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description includes an 'Args' section that explains each parameter's purpose and context (e.g., 'z_height_mm: Z height to resume from (from checkpoint)'). This adds significant meaning beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it executes firmware-level print resume for OctoPrint+Marlin printers after power loss/failure. It specifies the action (positioning and preparing to resume) and distinguishes from sibling tools like start_print and resume_print.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (after power loss or failure) and when not to use (Moonraker/Klipper printers should use Klipper's SAVE_VARIABLE system). Provides clear alternatives and follow-up actions after the call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses side effects thoroughly: optional intent block and sidecar file for pro tier, inline 3D stage for supported hosts, and automatic decimation of oversized meshes. Even notes the free/public install behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed with multiple paragraphs, but each sentence contributes value. The inline 3D stage and tier details could be considered slightly verbose, but overall it remains focused and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage: purpose, usage, side effects, and parameter semantics are all addressed. Given the simple input schema and no output schema, the description sufficiently covers all relevant aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Explains both parameters in detail: template_id is from list_design_templates, parameters is an optional dict of overrides with example. The schema only provides types, so the description adds essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a 3D model from a parametric template with explicit parameters, and distinguishes it from smart_generate_from_template. The rendering of OpenSCAD code to STL is explicitly mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage guidance: 'Use when you know which template and parameter values to use' and contrasts with the AI-assisted alternative. Also points to list_design_templates for available templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: experimental nature, risks (non-printable geometry), workflow (submit job, poll, download), and provider differences (Meshy vs OpenSCAD).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections, bullet points, and front-loaded summary. Some verbosity in prompt examples, but generally efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and no output schema, the description covers all essential aspects: purpose, when to use, workflow, risks, parameter details, and provider-specific notes. Complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains all 5 parameters: prompt (text or OpenSCAD), provider (meshy/openscad), format (stl), style (optional, ignored by OpenSCAD), and material (design hint). Includes prompt tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates a 3D model from a text prompt via external AI API. Distinguishes from sibling tools by explicitly naming alternatives for image-based generation, parametric templates, and combined slice+upload.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (text description, no template/image) and when to use alternatives. Provides guidance on the 'material' parameter and OpenSCAD prompt requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: non-blocking HTTP round-trip, return statuses, side effects (writing tokens to ~/.kiln/auth_tokens.json), and free tier. No contradictions or omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, bullet points for statuses, and concise details. A minor point: it could be slightly tighter, but overall it's efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 parameter, clear outputs), the description covers all needed context: polling behavior, all possible return statuses with actions, side effects, and free tier. The output schema is directly provided in plain text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description explains the device_code parameter's origin ('from kiln_signin') and usage, adding essential meaning beyond the schema that only specifies it as a required string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check whether a sign-in started by kiln_signin is done', providing a specific verb ('check') and resource ('sign-in poll'). It distinguishes itself from sibling tools like kiln_signin by explaining its role as a follow-up polling mechanism.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Call this repeatedly (every interval seconds) with the device_code that kiln_signin returned', and details actions for each status (e.g., wait for pending, restart for expired). It provides clear usage context without needing exclusion statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It thoroughly discloses behavior: it explains for meshes the scoring dimensions and weights, and for CAD it details the three-band output, the reason grade is null (converter-dependent tessellation), and that 'about_our_copy' counts are never scored. This is exceptionally transparent, even explaining measurement methodology.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but highly structured with bullet points, bold labels, and clear sections. Every sentence adds value, covering two distinct use cases and their outputs. It could be slightly shortened, but the thoroughness justifies the length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must fully describe returns. It does so exhaustively: for meshes, it lists dimensions, weights, and grade; for CAD, it details all three bands and their contents. It also covers edge cases like null grade and the difference between measured and exact data. Nothing is left unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though the schema provides no parameter descriptions (0% coverage), the description compensates fully by explaining file_path accepts mesh or CAD file extensions (.stl, .obj, .glb, .step, .stp). This adds concrete format guidance beyond the bare schema, which is essential for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly distinguishes two modes: mesh assessment and CAD intake report. It specifies the exact verbs ('assess', 'returns a graded scorecard', 'returns an intake report') and the resource inputs (.stl, .obj, .glb vs .step, .stp). The purpose is unambiguous and distinct from siblings, as it is the only tool focused on quality scoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use for meshes and CAD files, and provides critical usage guidance such as quoting 'exact' measurements for CAD parts. It warns against using 'about_our_copy' for user-facing sizes and explains why grade is withheld, giving clear context on when to expect a grade vs an intake report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses key behavioral traits: returns a webcam image (base64 or saved file) alongside structured metadata (temps, progress, phase, cost estimate, failure hints) and can auto-pause on detected issues. This is comprehensive for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, usage pointers, and parameter list. It is slightly lengthy but every sentence adds value. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no annotations, and no output schema, the description covers all necessary aspects: purpose, usage, parameter semantics, behavioral traits, and expected return values. An agent can confidently select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description must compensate. It provides detailed explanations for all 6 parameters, including defaults (e.g., include_snapshot default True) and context (e.g., auto_pause defaults to an environment variable). This fully adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Snapshot + structured data for AI visual inspection of an in-progress print.' It contrasts with sibling tools by directing to 'monitor_print' for text status and 'watch_print' for persistent monitoring, thus distinguishing itself effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when analyzing camera images for print failures.' It also provides explicit alternatives for related tasks, such as 'monitor_print' for a quick text status and 'watch_print' for persistent background monitoring, offering clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that the tool delegates to printer_status, explains the return shape change (nested printer/job vs flat keys), and details the historical naming problem. No behavioral traits are hidden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat verbose but well-structured: deprecation, delegation, shape change, reason, then args. It could be slightly more concise but the extra detail is necessary for context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
It comprehensively covers the deprecation, replacement, return shape, historical problem, and parameter usage. For a deprecated wrapper, it leaves no relevant context unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The Args section adds meaning to printer_name: 'Target printer. Omit for the default printer.' This exceeds the schema info (optional, default null) and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a deprecated alias for printer_status with detail='lite', and states its role as a backward-compatibility wrapper. This distinguishes it from sibling tools like printer_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call printer_status(detail='lite') instead, making the alternative clear. The deprecation notice provides direct guidance on when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the data flow (reads retained copy, uploads gzipped, returns token), clarifies security (nothing crosses tenants, IDOR-checked), and mentions honest refusals for unsliced prints. This adds transparency beyond what annotations would provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for explanation, args, and returns, but includes some redundancy in phrasing. It is not overly long but could be tightened without loss of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, return values, edge cases (unsliced prints), and security considerations. Given no annotations, it effectively fulfills the need for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'printer_name' is clearly described with its purpose and default behavior. The description adds meaningful context not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: uploading the current print's sliced file for monitor viewing. It distinguishes itself from sibling tools by specifying the target (web Monitor) and the action (publishing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says when to use it (called by the web Monitor while a print is running) and that there's normally no reason to call by hand. This provides strong usage context without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden, disclosing key behaviors: printer DNA usage, wear warnings, availability scoping, needs-purchase labeling, and naming better materials not owned. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but somewhat lengthy. However, it is well-structured with clear sections (summary, details, tool comparison, Args) and every sentence adds value. Minor conciseness improvement possible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and 6+ sibling tools, the description covers all necessary context: inputs, behavior, edge cases (needs-purchase, best-of-have vs best-for-job), and ties to pricing tiers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by explaining all six parameters in detail with examples and context (e.g., intent as natural language, printer_id essential on mixed fleet, on_hand_only for inventory restriction).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Recommend material from intent + printer capabilities' and provides a dedicated section listing sibling tools with usage scenarios, making the tool's purpose distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a 'Which material tool to use:' section that explicitly differentiates this tool from six siblings with concrete when-to-use guidance. It also explains parameters like printer_id and on_hand_only in context of when they should be passed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It thoroughly explains the restart mechanism, the clean_env parameter behavior, and what the return value indicates, including 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and parameter documentation, but includes a somewhat tangential measured scenario that adds length without essential value. Still, it's appropriately detailed for a complex tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, behavior, parameter, return value, and usage context, including the client reconnection expectation. It is comprehensive for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The clean_env parameter is explained in detail: its default behavior, the footgun it prevents, and when to set it to False. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool restarts the Kiln MCP server process and elaborates on the mechanism, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific scenarios for when to use (after plugin updates, env changes, code modifications) and contrasts with a full client restart, offering clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavior: scans recursively, decrypts with old passphrase, re-encrypts with new, dry-run preview, and required post-rotation actions. Clearly states it modifies files. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: initial summary, then block with process, then parameter list. Front-loaded with main action. Slightly verbose with repetition (e.g., 'Scans *directory* recursively' and then parameter explanation), but overall clear and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a 5-param tool with no output schema: covers purpose, process, prerequisites, post-conditions (env variable, restart), and parameter details. No gaps given the complexity and absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully documents all 5 parameters. Explains each parameter's role (old_passphrase, new_passphrase, directory, pattern, dry_run), provides defaults, and clarifies dry_run usage. Adds meaning beyond schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Rotate the G-code encryption key by re-encrypting all files.' It explains the process (scan, decrypt, re-encrypt) and distinguishes from siblings like encryption_status by focusing on the rotation operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to run with 'dry_run=True' first to preview, then with 'dry_run=False' to execute. Also provides post-rotation guidance: update environment variable and restart server. Mentions requirements: Enterprise license and admin scope. No alternative tools for rotation, so no need for exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully discloses behavior: 'skipping is IRREVERSIBLE', 'skips are cumulative', 'only while a multi-object plate is actively printing', backend-specific ID handling, and printer support matrix. It also describes the return value shape. No contradictions 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized: general purpose, benefits, identifier details, printer support, agent contract, then args and returns. It is front-loaded with the core purpose. However, some details could be more compact without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of multi-backend support and irreversible actions, the description is very complete. It covers all necessary context: prerequisites, printer compatibility, identifier formats, behavior during print, and return value. Without output schema, it still describes return dict structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by detailing what object_ids are with backend-specific examples (Bambu, Klipper, OctoPrint) and explaining plate_number as 'which plate the ids came from (1-based, default 1) recorded for context'. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Abandon one or more failed objects on a multi-object plate, mid-print.' which clearly states the verb (abandon/skip) and resource (objects on a plate). It distinguishes itself from sibling tools like cancel_print (full cancel) and pause_print by specifying partial object skipping. The title also aligns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use: 'when one part on a full plate fails' and provides when-not-to-use: 'Prusa via Prusa Link can't be skipped remotely', 'Elegoo SDCP protocol... has no skip command'. It also references sibling list_plate_objects for discovering IDs and includes an agent display contract with usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses behavior: read-only, no side effects, tax computed only on orchestration fee, reverse charge for business in certain regions, and the effect of user_email on fee waiver. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, terms reference, calling shapes, Args, and Returns sections. Front-loaded with purpose. Slightly verbose due to legal reference but every sentence adds value. Appropriate length given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a 6-parameter tool with no output schema and 0% schema coverage. Describes both return shapes, free-tier waiver, reverse charge, and references sibling tools. Covers behavior, parameters, and return values adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates fully by detailing each parameter: fee_amount as legacy, jurisdiction with reference to tax_jurisdictions, business_tax_id for exemptions, manufacturer_quote_usd triggering canonical mode, currency default, and user_email for free-tier. Adds significant meaning beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool previews a complete price breakdown including tax before an order, distinguishing between canonical preview and legacy tax-only modes. It references sibling tools like tax_jurisdictions and tax_jurisdiction_lookup for finding supported codes, differentiating itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use each mode: canonical preview recommended when manufacturer_quote_usd is provided, legacy mode for compatibility. Also states it is read-only and does not charge or contact providers, and explains the free-tier waiver context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It thoroughly explains safety (doesn't stop physical prints), what can be affected (monitoring may stop), refusal conditions (job in flight), and the two-phase action (plan then confirm). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and bullet points, though it is lengthy. Every sentence contributes value; however, it could be slightly more concise while retaining all necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 3 parameters, the description covers all behavioral aspects: return format (plan vs. action), edge cases (printing, force), and user interaction flow. It is fully complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description expounds each parameter: confirm (returns plan vs acts), open_sessions (user's count of active sessions), force (override print protection). This compensates fully for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Close leftover Kiln servers left behind by closed sessions.' It provides specific context and positions itself as the cleanup tool, distinguishing it from sibling tools like troubleshooting or monitoring.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an 'AGENT CONTRACT' with explicit when-to-use (cleanup after sessions), when-not-to-use (while printing), and alternatives (offer to clean up after print, not force). It also instructs to ask the user for open_sessions rather than guessing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses behavioral traits: it changes installed software, is safe to call without confirm (returns offer only), swapping mid-print is unsafe, force override exists, and after success the old code remains loaded requiring a restart.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, agent contract, args), but contains somewhat verbose marketing language ('Apple-grade upgrade path') that adds little value. Still, every sentence earns its place overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description covers preconditions (no active print), user confirmation, side effects, and what to do with the result (relay restart instruction). No gaps remain for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds full meaning: confirm=True performs update, confirm=False returns offer; force overrides mid-print safety defer. This compensates completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and resource 'Kiln package to the latest version', and distinguishes from sibling tools like 'get_upgrade_url' or 'kiln_health' by specifying the user-facing upgrade process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to call (when newer Kiln available), user confirmation, avoiding mid-print calls, and how to handle success (restart instruction). It also instructs to offer the upgrade rather than making the user run a command.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses several behaviors: edge detection and triangle insertion, purpose (reduce stress concentration, improve printability), and side effects on output. It also mentions the interactive 3D stage side effect, including decimation of oversized meshes, which is valuable. No contradictions with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary, followed by usage guidance, parameter documentation, and a note about the 3D stage. It is detailed but each sentence adds value; no filler. The inline 3D stage note is extra but relevant and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with 4 parameters, no output schema, and no annotations, the description is complete: it explains the purpose, how it works, when to use, parameters, return value (dict with sharp edge count, triangles added, and output path), and the 3D stage side effect. This is sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explicitly explains each parameter in a :param block: file_path (path to STL), radius_mm (fillet radius with default), angle_threshold_deg (edge sharpness threshold), and output_path (output location with default). This adds meaning beyond the bare schema properties, fully compensating for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds fillets (rounded transitions) at sharp edges of a mesh, using specific verbs and resources. It distinguishes itself from sibling tools like 'add_mesh_chamfer' (which adds chamfers) and other mesh operations, making its purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use after design_scorecard() flags sharp corners or predict_print_failures() detects stress risers.' This clearly suggests the context and triggers, and implicitly differentiates it from alternative operations like chamfering by focusing on fillets for stress reduction and printability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description comprehensively discloses behavior: it validates the profile, saves only locally to a specific file path, notes the older filename that is still read, explicitly states nothing is uploaded or shared, describes the tightening-only constraint and the rejection of higher numbers, and notes that values are labelled owner-supplied in readouts. This exceeds expectations given no annotations were provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear paragraphs that each add value: purpose, location/scope, constraint, strategic guidance, labeling, and argument details. It is front-loaded with the key purpose and uses markdown for file paths and code identifiers, making it scannable without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (a validation/write operation with data structure specifics), no annotations, and no output schema, the description is remarkably complete. It covers validation, persistence, domain constraints, alternatives, and parameter structure fully, leaving no significant onboarding gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema description coverage is 0%, the description thoroughly explains both parameters. It defines printer_model as a 'Short identifier' and gives an example, and describes the profile dict with required keys (max_hotend_temp, max_bed_temp, max_feedrate, build_volume) and their types (e.g., 'a list of 3 positive numbers'), plus optional fields. This provides substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's primary function: 'Add a local safety-profile override for a printer model.' It specifies the resource (printer model) and the action (add/override safety profile), and distinguishes it from related tools like select_printer_variant, lock_safety_profile, and list_safety_profiles by emphasizing it is for local, owner-supplied overrides that only tighten limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use and when not to use: 'this is the right tool for a printer Kiln has never heard of, or for holding your own machine BELOW the curated limits' and 'It is the WRONG tool for "my hotend is upgraded". Use select_printer_variant for that'. This gives clear strategic guidance and names the alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: explains key field behaviors (tray_now='255' meaning none/external spool, A1/AMS Lite differences, bitmask fields), mentions Bambu Lab only restriction, and details return contents. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: starts with a one-line summary, then usage guidance, return field details, edge cases, and practical applications. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description fully compensates by explaining return fields, special values, printer-specific behavior, and use cases. Comprehensive for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% trivially. The description does not need to add parameter semantics but provides rich contextual guidance on how the tool is used without parameters, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it provides a full AMS hardware dump including all trays, humidity, and RFID, specifically for Bambu Lab printers. Explicitly distinguishes itself from sibling tools 'get_active_material' and 'get_material' by naming when to use those instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (check filament levels before printing, verify material, select ams_mapping for start_print()) and when-not-to-use (for just active material or Kiln's tracker), including specific alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden and succeeds: it discloses CAD conversion, that metrics are measured on a Kiln mesh copy, that an 'exact' block comes from the CAD file's own surfaces, and that mesh and exact values may disagree. It also states return type and score range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though fairly detailed, the description is front-loaded with the core purpose, then flows logically through metrics, usage timing, CAD-specific behavior, parameter docs, and returns. Every sentence contributes actionable information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single parameter, the description is unusually complete: it covers input formats, the full set of computed metrics, CAD conversion nuances, exact vs expected values, and an alternative tool. An agent has enough to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the schema only says 'file_path: string'. The description compensates fully by specifying supported input formats (.stl, .obj, .glb and .step/.stp) and noting automatic conversion of CAD files, meaningfully enriching the lone parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Deep geometric and printability analysis of a 3D mesh' and enumerates exact metrics (volume, surface area, center of mass, overhang detection, connected components, degenerate triangles, printability score). It also distinguishes itself from sibling mesh_quality_scorecard by noting that tool gives a fuller intake report, making its scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use this after generating a model to understand its geometry and identify printability issues before sending to the slicer.' It also gives an alternative ('mesh_quality_scorecard gives the same file a fuller intake report') and notes that STEP/STP files are converted automatically, informing when it can be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses safety behavior: it never cancels a running print, re-checks job status immediately before cancelling, skips jobs that are no longer queued, and emits the same `JOB_CANCELLED` event. It also explains `dry_run` behavior and the return payload, providing strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a leading summary, a clear bullet for parameters, and a safety/return section. Every sentence adds value, and the key purpose is front-loaded in the first sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is remarkably complete: it covers scope, parameter behavior, safety guarantees, event side effects, and the exact return structure. An agent has enough context to invoke this tool correctly and avoid destructive mistakes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates thoroughly: `printer_name` scopes the sweep to one printer and omitting it clears everything, while `dry_run=True` previews without changing anything. This adds meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Cancel ALL queued print jobs at once,' a specific verb and resource with clear scope. It distinguishes itself from the sibling `cancel_queued_job` by positioning as the bulk companion and clarifying it targets the QUEUED state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this when clearing a backed-up queue instead of cancelling one job at a time, and it names the alternative: 'Use `cancel_print` to stop the job that is actually running.' This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it acknowledges a firmware-held error, reconciles Kiln with the machine, does not fix the underlying cause, may halt again on retry, and is blocked during an active print. It also states the return value—whether the acknowledgement was sent plus the read-back printer state. This is exemplary transparency for a state-mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Though relatively long, every sentence adds real value: scope, differentiation from a sibling, exact trigger condition, non-goals, runtime constraint, parameter description, return behavior, and cross-references. It is well-structured in digestible paragraphs and avoids redundancy. The length is justified by the conceptual complexity of distinguishing firmware vs. Kiln latches.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This simple one-parameter tool is completely documented despite no annotations and no output schema. The description covers purpose, usage condition, behavior, side effects, limitations, parameter semantics, return value, and related tools. There is nothing an agent would need to know about this tool that is missing from the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only provides `printer_name` as an optional string/null with a default of null, and schema description coverage is 0%. The description compensates fully with ':param printer_name: Target printer. Omit for the default printer.' This adds complete semantic meaning beyond the schema, directly addressing the single parameter's purpose and optionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Clear a latched error on the PRINTER so it will accept prints again.' It clearly distinguishes itself from the sibling `clear_emergency_stop` by contrasting Kiln's own safety latch vs. firmware-reported errors. This leaves no ambiguity about what the tool does or how it differs from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit trigger condition: use when `printer_status` reports `error` and the printer's own screen looks fine. It also states what it does NOT do (fix the cause, overrule the machine) and notes that nothing is cleared during a print. This provides strong when-to-use and when-not-to-use guidance, while explicitly referencing `clear_emergency_stop` as an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly discloses behavioral traits: it can open an interactive 3D stage on success, decimates oversized meshes, requires OpenSCAD locally, has known limitations on left/right faces (rotation and offset axis scaling), and explains face-local offsets. No annotations are provided, so the description fully carries transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with clear sections (purpose, differentiation, parameter details, examples, side effects). It is front-loaded with the main purpose and uses bullet points and parameter blocks, maintaining readability without fluff. The repetition of image_style options is minor and acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all necessary context: dependencies (OpenSCAD), output details (STL path, preview, metadata), side effects (inline 3D stage), fallbacks (SVG import on OpenSCAD 2024+), and limitations (wall mode only for text, face orientation issues). It is complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 16 parameters are described in the parameter list with semantics, defaults, and examples (e.g., depth_mm auto based on material, offset_x/y_mm face-local positioning, image_style and its options). The schema has no descriptions, so the tool description provides complete parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool puts any image, text, or pattern onto a 3D model surface, and clearly differentiates from sibling tools (apply_geometric_texture, apply_procedural_texture) by specifying it is for one-off content placement versus repeating patterns. This provides a specific verb, resource, and sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance, saying 'For repeating patterns... use apply_geometric_texture or apply_procedural_texture instead. This tool is for one-off content placement.' It also provides detailed usage scenarios (e.g., 'wall' mode for cups, placement presets, and recommendations like preferring front-facing faces).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral aspects: it explains the temporary nature (short, per-printer override that expires), the safety classification (confirm), and the human-in-the-loop requirement. It does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with paragraphs, bullet points, and clear sections. Every sentence adds value, and the content is front-loaded with the core action. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is complete: it explains the tool's behavior, safety, parameters, and expected returns ('Grant confirmation, or a confirmation-required challenge'). It also references external documentation for safety details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since the input schema provides no descriptions (0% coverage), the description explains both parameters: printer_id (with example and default behavior) and ttl_minutes (with default and max), adding value beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to override the pre-print impossibility gate for a single printer. It explains the specific verb 'override' and the resource 'pre-print impossibility gate,' and distinguishes this tool from other print operations by highlighting it as an escape hatch for blocked prints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool (e.g., when a print is blocked due to physical limits and intentional bypass is needed) and when not to (autonomous agents cannot self-approve). It also mentions alternative uses like sending to a different printer and clarifies that design/slicing steps are unaffected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes reading live tray data, return fields (type, colour, remaining %, temperature range), and fallback logic for ambiguous tray_now. No annotation provided, but description carries full burden and is thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear paragraphs: purpose, differentiation, return details, edge case. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all necessary aspects: input, output, edge cases, fallback behavior. Adequate for a simple getter with one optional parameter and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Docstring explains the single parameter 'printer_name' is optional and defaults to default printer. Schema only provides default null, so description adds meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it 'Get the filament physically active in the AMS hardware right now' for Bambu Lab printers. Differentiates from sibling 'get_material' which tracks software-set material. Specific verb+resource with scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use 'get_material' for software-tracked material, and describes behavior for non-Bambu printers and edge case with tray_now==255. Provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses how the tool behaves with different inputs: the effect of calibration tier on the clearance range and the inclusion of a calibration_used block. It also explains the conservative assumption for mating hints, making the behavior predictable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed yet each sentence adds value, providing necessary context and examples. It is well-structured with separate explanations for each parameter, avoiding redundancy while being informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for the tool's operation, including the effect of external factors like calibration tier and the output structure (calibration_used block). It also covers all parameters and the return value, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter is thoroughly explained with examples, defaults, and specific effects. The description covers the meaning of joint_type, material_a/b, printer_id, and mating, including when they are optional and what values to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: providing recommended clearance settings for joint types and material pairings. It specifies the key inputs and the optional narrowing based on printer calibration, 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.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool, including conditions for providing printer_id and mating hints, and details the behavior for different cases. It also clarifies when parameters should be omitted, offering practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the two modes, that parameters are itemized as applied/absent/skipped, the output artifact type (3MF or G-code), the inline preview behavior (including the 3D stage and decimation), and that the rebuild never depends on the preview. It also notes that brief_id is recorded on the recipe. This is rich behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-organized with clear sections (mode details, parameter semantics, return value, preview note, example). Each section adds necessary information. While verbose, it is not redundant; every paragraph earns its place given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all aspects: purpose, modes, parameter details, return value, artifact type, preview/3D stage behavior, and example usage. The output is described as a Dict with print artifact and mode, which is sufficient since no output schema exists. The description is comprehensive and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only minimal type info for recipe_path and brief_id, with 0% description coverage. The tool description fully explains recipe_path (design directory or recipe file) and brief_id (optional saved-goal id, how it's recorded, and behavior when omitted). This adds significant semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Re-execute the full build pipeline from a saved design recipe.' It distinguishes between parametric and mesh modes, and explains what the tool does (re-derives geometry or re-slices meshes). This is a specific verb+resource, and it differentiates from siblings like tweak_and_compile_scad or rescale_model by focusing on full rebuild.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: for parametric resizing, use update_scad_parameter and rebuild; for mesh geometry changes, use rescale_model/thicken_mesh_walls first. It also warns against scaling the mesh instead of rebuilding. It names alternative tools (update_scad_parameter, rescale_model, upload_file) and explains when to use them. This is thorough and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and exceeds it. It discloses automatic pre-flight safety checks and the blocking behavior on failure, the three-value print_start branch with diagnostic guidance, the firmware's cool-on-new-job policy and the preheat reassert safety net, and false-positive bypass behavior for nozzle_clog_detect — all beyond the literal schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence adds value — no filler or restatement. It is front-loaded with the core action and alternatives, then organized as a clear parameter-by-parameter reference with bolded defaults and rationale. The detail is proportionate to the 15-parameter complexity (many only relevant to Bambu printers), and the structure keeps it scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers all essential context: preconditions (file already on printer), automatic safety checks, return branch semantics (started/accepted/failed), success flag meaning, multi-printer routing (printer_name affects pre-flight, preview token, emergency latch, nozzle-wear consult, watchdog), and resume-mode subtleties. This is a complete operational picture for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates richly for every parameter. Each parameter gets a purpose, default, and in most cases behavioral consequences (e.g., use_ams tri-state fallback, ams_mapping defaults based on AMS state, bed_leveling saving ~2 min, resume_from_paused auto-detection by file name). This is exemplary compensation for a sparse schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The first line states "Start printing a file already uploaded to the printer" — a specific verb and resource with a clear precondition. It further distinguishes itself from siblings by explicitly referencing upload_file, slice_and_print, and run_quick_print, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool vs alternatives: "Use upload_file first, or use slice_and_print / run_quick_print to slice + upload + print in one step." It also provides conditional guidance for params like resume_from_paused (for resume-mode 3MF) and printer_name ("upload the file to that same printer first"), forming a complete usage model.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although annotations are absent, the description thoroughly discloses behavioral traits: mesh may be modified in place if auto_repair or auto_scale is enabled, the response includes the final file path (which may differ if repairs created a new file), and STEP/STP conversion may return NO_BACKEND with a remedy. This exceeds the minimal disclosure needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with bold headers, bullet points, and emphasized sections. Despite being long, every sentence adds value and is front-loaded with the core purpose. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (11 parameters, no output schema, no annotations), the description provides complete context: the pipeline steps, parameter details, behavior under different conditions (e.g., auto-repair, auto-scale), and handling of unsupported conversions. It equips an agent with all necessary information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each of the 11 parameters, including accepted file types for file_path, the meaning of material, default values, and special notes like the STEP conversion behavior. This adds significant value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as a full validation pipeline: validate, repair, analyze, and prepare a mesh for printing. It differentiates from sibling tools like 'validate_and_prepare' (a more comprehensive 10-step pipeline) and 'validate_generated_mesh' by specifying that this tool provides the full pipeline including repair, printability scoring, and build volume checks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use this instead of validate_generated_mesh when you want the full pipeline' and 'See also: validate_and_prepare for a more comprehensive 10-step pipeline'. It clearly states the context for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/codeofaxel/kiln'
If you have feedback or need assistance with the MCP directory API, please join our Discord server