orcaslicer-mcp
Server Quality Checklist
Latest release: v0.1.9
- Disambiguation5/5
Each tool has a clearly distinct purpose, even within overlapping areas like slicing and presets. For example, slice, slice_and_wait, apply_and_slice, and compare_settings are differentiated by whether they just start, wait, apply config, or iterate over values. Detailed descriptions eliminate ambiguity.
Naming Consistency5/5Tool names follow a nearly consistent verb_noun or verb_phrase pattern in snake_case (e.g., get_slice_status, list_presets, delete_object). The few single-verb names (slice, consult, remember) still fit the verb-first convention and don't break the overall pattern.
Tool Count2/5With 40 tools, the server is heavy. While the breadth covers many subdomains (slicing, config, presets, objects, plate operations), the count exceeds the 25+ threshold that typically indicates a toolset is too large for agents to navigate effectively.
Completeness5/5The tool surface is remarkably complete for the OrcaSlicer domain: slicing lifecycle, configuration discovery and modification, preset CRUD, object manipulation and analysis, plate diagnosis, G-code retrieval, and even rendering. There are no obvious dead ends or missing critical operations for the stated purpose.
Average 4.2/5 across 40 of 40 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 3 community issues answered or closed in the last 6 months
- 126 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
Tools from this server were used 2 times in the last 30 days.
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?
Annotations indicate the tool is not read-only (readOnlyHint=false) but also not destructive (destructiveHint=false). The description adds minimal behavioral context beyond this—only the allowed type values—and does not disclose side effects, prerequisites, or what happens when a preset is selected (e.g., whether it changes the current configuration or affects other operations). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no wasted words. The purpose and key parameter constraint are front-loaded, making it easy to parse.
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 is simple (2 params, no output schema), but the description is too sparse given the rich sibling context. It does not explain what 'selecting' entails (e.g., setting the active preset for a given type), when it is appropriate, or what side effects might occur. This is a minimal viable description that leaves significant gaps for an 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?
With 0% schema description coverage, the description must add parameter meaning. It does clarify that 'type' accepts print, filament, or printer, which is valuable. 'name' is implicitly defined by the phrase 'named preset' but lacks explicit detail. Overall, partial compensation for the schema gap.
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 ('Select') and the resource ('a named preset'), and it specifies the valid types (print, filament, printer). This distinguishes it from sibling tools like save_preset or list_presets through the verb and scope, though it does not explicitly describe the effect of selecting (e.g., setting the active preset).
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 gives no guidance on when to use this tool versus alternatives such as list_presets, save_preset, or set_config. It only states what the tool does, leaving the appropriate usage context entirely 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?
The description goes beyond the sparse annotations by disclosing atomic behavior, the return shape {applied, errors}, and that nothing is applied on any invalid key. This provides meaningful behavioral context that the annotations do not cover. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, and no redundant words. Every sentence contributes useful information about atomicity and error behavior.
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 atomicity and return values, which are key for a config setter, but omits important context such as how to discover valid keys, whether the tool applies to session or persisted config, and when to prefer sibling tools like set_object_config. Given the simple one-param schema, this is a moderate gap.
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%, and the description does not compensate. The term 'config changes' vaguely implies the structure of the 'changes' object but offers no example, key format, or details on how valid keys are determined. The parameter name alone does not suffice.
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 ('Apply config changes') and resource ('config changes'), and the atomicity aspect distinguishes it from simple getters. However, it does not explicitly differentiate from set_object_config, relying on the sibling name to imply broader scope.
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 versus alternatives like set_object_config, set_layer_height, or find_config_keys. It simply describes the operation without contextualizing its applicability.
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 already declare destructiveHint=true and readOnlyHint=false, so the description does not need to repeat safety traits. It adds limited context by specifying 'current plate', but does not disclose consequences like permanence, undo options, or impact on associated settings. Since annotations carry the safety burden, a baseline 3 is appropriate, with 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 11 words that states the action, resource, and key mechanism with no filler. It earns its place entirely and avoids restating schema fields.
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?
With one simple parameter, no output schema, and strong annotations, the description covers the basic what and where, but misses important contextual information such as prerequisites (e.g., object must exist), behavior on invalid IDs, or post-deletion plate state. It is adequate for a trivial delete but leaves gaps in operational 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% for the sole parameter object_id, and the description only says 'by its id'—redundant with the parameter name—while adding 'current plate' context. It fails to explain how to obtain the ID, whether it is plate-local or global, or any constraints beyond the schema's integer type, so the description provides minimal added 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 clearly states the action ('Delete'), the resource ('an object from the current plate'), and the modifier ('by its id'), distinguishing it from sibling tools like delete_preset. It goes beyond the title by specifying the deletion 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 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., transform_object, duplicate_object) or when not to use it. It gives clear context ('current plate') but lacks exclusions or alternative tool references, which is a significant gap for an AI agent choosing among many 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?
Annotations indicate it's not read-only and not destructive. The description adds that it will 'report the resulting stats/warnings,' which is a behavioral output. It does not disclose whether changes are persisted, whether it blocks until slicing completes, or how failures are handled. Some value added 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?
A single, concise sentence that front-loads the action and includes the key output (stats/warnings). No wasted words or redundancy.
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?
This is a compound mutating operation with no output schema, no param descriptions, and minimal annotations. The description gives a high-level overview but lacks critical details such as the format of the 'changes' object, whether the apply is persistent, how the stats/warnings are returned, and error behavior. Not sufficient for reliable invocation without further exploration.
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 schema has one free-form object param 'changes' with no description (0% coverage). The description only says 'Apply config changes,' which tells the agent the parameter should hold changes, but gives no structure, allowed keys, or format. For a free-form object, this is insufficient 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?
The description clearly states a specific verb+resource: 'Apply config changes, then slice and report the resulting stats/warnings.' It distinguishes itself from sibling tools like set_config (which applies config only) and slice (which just slices) by explicitly combining both actions and reporting outputs.
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 a combined workflow—use this when you need to apply config changes and slice in sequence. However, it doesn't explicitly mention when to prefer this over calling set_config followed by slice, or whether slice_and_wait would be more appropriate for waiting on slicing. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates this is a safe read operation, lowering the transparency burden. The description adds the temporal scope 'current/last' and lists the categories of information returned, but it does not provide further behavioral detail such as whether the value is cached, how recently it updates, or how warnings are formatted. There is no contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase that immediately communicates the tool's purpose. It has no filler or redundant restating of the tool name, and every word contributes to 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?
For a simple, parameterless, read-only status tool, the description provides enough context by naming the three result categories: state, stats, and warnings. There is no output schema, so the description partially covers return expectations, though actual field names and structure are not specified. It is adequate but not 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 tool has no parameters, so the input schema is empty and the description adds no parameter meaning. With zero params, the baseline is 4; there is nothing else needed here.
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 'Current/last slice state, stats, and warnings' clearly identifies a status-reporting tool for the current or most recent slice. It names the resource (slice) and the kind of data returned (state, stats, warnings), but it does not explicitly distinguish itself from the sibling tools get_slice_warnings and get_slice_breakdown, which likely cover the warnings and stats aspects in more detail.
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 usage guidance is provided. The description does not state when to use this tool versus get_slice_warnings, get_slice_breakdown, get_status, or get_job_status, nor does it mention any prerequisites or context such as whether it should be called before or after slicing.
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?
The description explicitly states 'delete the old', which is a destructive operation, while annotations set destructiveHint=false. This is a direct contradiction and dominates the otherwise useful disclosure of the multi-step copy/select/delete 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 a single well-structured sentence that front-loads the purpose and then lists the exact behavioral steps. Every word contributes, with no redundant or vague filler.
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 rename tool, the description covers the main operation and its side effects, including the deletion of the old preset. However, it does not explain the exact value or format for the `type` parameter, nor any return value or error conditions, leaving some ambiguity 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?
The schema has 0% parameter descriptions, but the description compensates by mapping old_name/new_name to the old and new preset names and implying the type is 'USER' preset. It does not explicitly define allowed values for `type`, but enough meaning is provided for most 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 'Rename a USER preset' with a specific verb and resource, and then details the exact composite steps (save copy, select, delete old). This distinguishes it from siblings like edit_preset, save_preset, and delete_preset.
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 clearly indicates this applies to USER presets and explains the rename workflow as a copy-select-delete operation. It does not explicitly name exclusions or alternatives, but the context is sufficient for selecting this tool over related preset 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 annotation readOnlyHint=true already indicates a safe read operation, so the description adds the idle-state context and polling timing. However, it doesn't describe the return format or potential states (e.g., busy/error), leaving some behavior undisclosed.
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 that conveys purpose and usage with no unnecessary words. It's perfectly 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 there is no output schema, the description should clarify what the response looks like. Saying 'whether... is idle' implies a boolean but doesn't specify the response structure or any extra fields. It's adequate 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?
With zero parameters, the schema requires no explanation. Baseline 4 applies since the description doesn't need to add parameter 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 the tool checks whether the plate job worker is idle, and distinguishes it from general status tools by specifying 'plate job worker' and the polling use case. It conveys the exact 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to poll after arrange_plate/auto_orient, providing a clear usage context. While it doesn't name alternatives, the specific scenario 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description does not need to repeat that. It adds context by enumerating the types of status data returned (dirty keys, slice validity, running state), but does not disclose further behavioral traits such as auth requirements or rate limits. This is sufficient but not extensive.
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 lists the key status categories. It is front-loaded with the main purpose and contains no unnecessary words or 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 zero-parameter read-only status tool with no output schema, the description gives a reasonable overview of the return content (app/project/preset status, dirty keys, slice validity, running state). However, it does not describe the return structure or provide any usage context, such as when a status might be stale or what 'dirty keys' means. Given its simplicity, it is mostly complete but leaves some nuances unexplained.
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 trivially 100%. With no parameters to describe, the description does not need to add parameter information. The 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?
The description clearly states what the tool does: it retrieves status information about app/project/preset, dirty keys, slice validity, and whether a slice is running. This specific list distinguishes it from siblings like get_slice_status or get_job_status, which are more narrowly scoped.
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 is provided on when to use this tool versus alternatives. With many sibling tools like get_slice_status and get_job_status, the description does not clarify that this is the general status overview or when one would choose it over those.
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 annotations by disclosing the reuse of valid results, waiting behavior, and the return of final stats and warnings. Annotations indicate readOnlyHint=false and destructiveHint=false, which aligns with the described behavior of potentially starting a slice while not being destructive. It does not mention timeout/error behavior, but the extra context is valuable.
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 well-structured sentence that front-loads the primary action (slice/wait) and clearly separates the return value. Every word earns its place, with no filler or repetition. It is appropriately sized 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?
The description covers the core flow and return value, but lacks important contextual details such as what constitutes a 'valid result', how timeout works, and behavior on failure or cancellation. Given the presence of sibling tools for status and cancellation, a bit more context would help, but the description is adequate for a basic grasp of the tool.
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 schema has one parameter, 'timeout', with 0% description coverage. The description completely ignores this parameter, failing to explain its purpose, units, or behavior on timeout. Since the schema is bare and the description does not compensate, the agent has no guidance on how to set or interpret the timeout.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 operation: slice (or reuse a valid result) and wait for completion, then return final stats and warnings. This distinguishes it from sibling tools like 'slice' (just initiates) and 'get_slice_status' (just polls), making the tool's purpose explicit and specific.
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 the use case: when you want a synchronous slice operation that waits for completion and returns final results, as opposed to separately calling slice and polling status. However, it does not explicitly name alternatives or state when NOT to use it, so it falls short of a perfect score.
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 meaningful behavioral context beyond the readOnlyHint annotation by noting the tool works offline and returns static metadata. This is valuable and not contradicted by 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?
One concise sentence that front-loads the purpose, lists returned fields, and adds the offline note. Every word 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?
For a simple 1-parameter tool with no output schema, the description covers the return fields and offline behavior. It would benefit from clarifying the 'key' parameter, but the overall context is reasonably complete.
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 implies 'key' identifies a setting but does not specify the format, examples, or how to find valid keys. This leaves the agent guessing what value to pass.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 provides an authoritative definition of one OrcaSlicer setting, enumerating the specific fields returned. This distinguishes it from siblings like search_settings, which likely search across 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 mentions it works offline, which is a useful usage signal, but it does not explicitly state when to use this tool instead of alternatives like search_settings or get_config. No exclusions or alternatives are mentioned.
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 two important behavioral traits beyond the annotations: idempotent update ('Same exact range again = update') and clearing behavior ('clear=True removes all ranges'). This adds value over the sparse readOnlyHint/destructiveHint flags, though it does not cover all edge cases like overlapping ranges.
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, with the main purpose front-loaded and additional behavioral details following. It is concise, every sentence adds information, and it avoids unnecessary repetition of schema data.
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 five parameters and no output schema, yet the description only covers the core range-setting behavior. It omits important context such as what happens with null min/max, how overlapping ranges are handled, and what the return value is. This is adequate for a simple setter but leaves gaps for nuanced 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?
With 0% schema description coverage, the description must compensate, but it only provides a single example mapping to parameters (min_z, max_z, layer_height) and explicitly mentions clear. object_id is not explained, and there is no systematic parameter breakdown, leaving some guessing for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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: 'Set a per-height-band layer height on an object' with a concrete example ('0-5mm at 0.1mm'). This distinguishes it from sibling tools like set_layer_height, which likely sets a uniform height, by specifying the per-band 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?
No explicit guidance on when to use this tool versus alternatives such as set_config or set_layer_height. The description implies usage for variable layer heights and provides behavioral notes about update/clear, but lacks direct 'use this when' or 'instead of' 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?
The description discloses the return state ('started / already_valid / conflict') and implies idempotency with 'already_valid', which is useful. However, it does not define what 'conflict' means, whether the operation is asynchronous, or any side effects. Annotations (readOnlyHint=false, destructiveHint=false) are neutral and provide no additional safety 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 a single, concise sentence that states the action and the possible return values without redundant words. It is front-loaded with the primary verb and resource, making it highly scannable.
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 no parameters and no output schema, the description provides the core purpose and basic return states. However, it lacks explanation of the return values' meanings ('already_valid' vs 'conflict') and does not distinguish this tool from the sibling slice_and_wait, which is a notable gap given the related tools.
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 an empty input schema, there is no parameter detail to convey. The description adds the 'current plate' context, which clarifies the implicit scope. Since schema coverage is 100% (vacuously), the baseline of 4 for 0 params 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 'Start slicing the current plate' clearly states the verb 'start' and the resource 'slicing the current plate', making the tool's purpose unambiguous. It differentiates from sibling tools like get_slice_status (view status) and cancel_slice (abort), as well as slice_and_wait (which likely waits for completion).
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 stating the action, but it does not explicitly mention when to use this tool versus alternatives like slice_and_wait or apply_and_slice. There is no exclusion or guidance about prerequisites, so the agent must infer from context and 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?
Annotations mark the tool as readOnlyHint=true, and the description adds an explicit guarantee that the original value is restored even on error. This provides useful behavioral context beyond the annotation, though it does not detail the return format of stats/warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action and then a safety note. Every word earns its place; there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior and non-destructive guarantee, but omits what the collected stats/warnings look like and the role of 'extra'. Without an output schema, the agent lacks clarity on return values, making the description adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It clarifies that 'values' are iteratively assigned to 'key', giving meaning to these params. However, the 'extra' parameter is completely unexplained, and the expected format of 'values' is not specified, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool iterates over values for a key, slices, collects stats/warnings, and restores the original. This specific verb+resource structure distinguishes it from sibling tools like get_slice_status or get_slice_warnings, which focus on single aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is clearly implied: use this tool to compare how different values of a setting affect the slicing outcome. It does not explicitly name alternatives or exclusions, but the action of iterating over values makes its purpose distinct from siblings like slice_and_wait or get_slice_warnings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint: true annotation already indicates a safe read operation. The description adds useful context by specifying that it retrieves text and refers to the 'last successful slice', but it does not disclose behavior such as what happens if no slice has been performed or whether it triggers any side effects. This is additional but not extensive context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action and outcome. Every word contributes to meaning, with no redundancy or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 nearly complete: it explains what is retrieved and in what form. However, it does not specify the behavior when no successful slice exists, which could be a relevant edge case. The readOnlyHint annotation covers the safety profile, so this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings since there are none. It correctly focuses on the return value instead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Retrieve' with a clear resource ('G-code') and qualifier ('last successful slice', 'as text'). It clearly distinguishes from sibling tools like 'slice' (which generates) and 'get_slice_status' (which checks progress).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'last successful slice' implies this tool should be used after a successful slicing operation, but it does not explicitly state when to use it instead of alternatives or mention exclusions. The usage context is implied rather than articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds the side-effect-free behavior ('without selecting it') and the type enumeration, which is useful context. It doesn't disclose return format, error conditions, or prerequisites, but with annotations the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, with the main verb and object front-loaded. The second sentence adds the essential type clarification without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (2 required params, no output schema) and the readOnlyHint annotation, the description covers the core purpose, side-effect behavior, and type restrictions. It could specify the return format in more detail, but 'full settings' is reasonably informative for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 clarifies that 'type' takes print|filament|printer values and implies 'name' is the preset name, which provides some meaning beyond the bare schema. However, it doesn't elaborate on validation, case sensitivity, or how to discover valid names, leaving gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('full settings of a named preset') while adding a key qualifier ('without selecting it') that distinguishes it from sibling tools like select_preset and get_config. It also clarifies the allowed types, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly establishes when to use this tool: to inspect a preset's settings without applying it. The phrase 'without selecting it' implies this is a read-only inspection and implies that other tools handle selection, though it doesn't explicitly name alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses atomicity ('nothing applied if any key is invalid'), which is important behavioral context beyond the annotations. The example also clarifies expected input format. No contradiction with readOnlyHint=false or destructiveHint=false.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the core action, followed by an illustrative example and the atomic guarantee. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (mutation, two params, no output schema), the description covers purpose, example, and atomicity. It does not mention return values or error behavior beyond atomicity, but these are not critical for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by referencing 'by id' for object_id and providing an example for the changes object. However, it does not fully elaborate parameter types or the structure of valid keys/values beyond one example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets per-object config overrides by object id, with a concrete example. This specific verb+resource+scope distinguishes it from the global set_config sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'per-object config overrides' implies this is for object-specific settings, contrasting with global config, but it does not explicitly state when to use this versus set_config or provide exclusions. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, and the description adds valuable behavioral constraints: system presets and the currently-selected one are refused. This goes beyond the annotations by clarifying edge cases where deletion will not occur. It could still describe the exact error behavior or confirm permanence, but the provided context is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences: a clear action statement and a compact type enumeration. Every word earns its place, and the most important information (delete, user preset, refusals) is front-loaded. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple destructive operation with annotations covering the safety profile, the description is reasonably complete. It states what it deletes, the constraints, and the type values. It does not describe return values, but no output schema exists, and the operation is straightforward. Slightly more detail about consequences (e.g., permanent deletion) would improve completeness, but the current description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates partially by enumerating allowed values for 'type' (print|filament|printer). The 'name' parameter is not explicitly described, though it is implied as the preset name from the tool's purpose. The added type enumeration provides some meaning beyond the bare schema, but the lack of any name description keeps this from being higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 the resource 'USER preset', and explicitly distinguishes from sibling tools by defining the scope (user presets only) and constraints (system and currently-selected presets are refused). It also provides the type enumeration, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: when deleting a user preset of a specific type. It implicitly differentiates from siblings like edit_preset or rename_preset by focusing on deletion, and the refusal of system/selected presets acts as a usage precondition. However, it does not explicitly mention alternatives or when not to use it beyond the stated refusals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that it matches keys containing the substring, but does not disclose case sensitivity, return format, or pagination. This is acceptable given the annotation coverage, but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, front-loaded with the action, and includes only essential context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one required parameter, read-only, no output schema. The description explains purpose and parameter usage adequately for a search/discovery tool. It does not describe return values, but that is implied for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 clarify the parameter. It explains that 'substring' is what config keys must contain, giving clear meaning. It does not add syntax details like case sensitivity, but for a single string parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it finds config keys by substring, using specific verb and resource. The parenthetical about ~600 keys adds helpful context and differentiates it from direct get/set config tools as a discovery aid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to discover config keys among the ~600 available. It does not explicitly contrast with sibling tools like search_settings, so exclusions are absent, but the intended use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds valuable behavioral details: it searches across specific fields (key, label, tooltip), returns a compact structure (key, label, category, short tooltip), and ranks results with key/label matches first. The 'Offline' note is an additional behavioral trait not present in annotations. This goes beyond what structured fields provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each earning its place. The first sentence states the action and scope, the second describes the result format and ranking plus an offline note. No fluff, and the key information is front-loaded. This is an example of concise, well-structured documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and no output schema, the description covers the core purpose, return shape, and an operational detail (offline). It doesn't specify pagination or behavior on no matches, but these are not critical for a search tool of this simplicity. With annotations covering read-only safety, the description is sufficiently complete for an agent to use it effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 the 'query' parameter by stating the search is 'by keyword' and enumerates the fields searched (key/label/tooltip), adding meaning. However, it does not mention the 'limit' parameter or its default behavior (25), leaving part of the semantics undocumented. The description partially compensates but not fully for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies 'Search settings by keyword across key/label/tooltip', naming the exact verb, resource, and scope. This immediately distinguishes it as a search tool over settings, and the return format ('compact matches... ranked key/label first') further clarifies its role. It stands apart from sibling tools like 'get_config' or 'find_config_keys' by stating its unique behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use when you need to find settings by keyword, and what results look like (compact matches, ranked by key/label). It doesn't explicitly name alternative tools or state when not to use it, but the purpose is so well-defined that an agent can infer appropriate usage. No exclusions are mentioned, but the context is sufficiently clear for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds behavioral context beyond that by specifying the bounded window and the specific event categories collected. This gives the agent a clear sense of the tool's scope and duration without needing to infer it from annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('Collect') and packs key details (event types, bounded window) without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one param, no nested objects, no output schema). The description covers what it does and gives the event types and time bound. It doesn't explain the return format, but for a streaming tool this is less critical, and the readOnly annotation plus bounded window give sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'seconds' with a default of 10, but description coverage is 0%. The description mentions 'bounded window' which hints at the seconds parameter, but it does not explicitly explain that seconds controls the collection duration. This adds some meaning but is still somewhat ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Collect' and identifies the exact resource ('live events') with a scoped set of event types (slice.*/config.changed/project.opened). It clearly distinguishes from sibling tools like get_slice_status which provide status snapshots, not streaming events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for watching live changes over a bounded window, which provides clear context. However, it does not explicitly state when to prefer this over polling or mention alternatives, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations. It discloses that changes are applied atomically, that a physics gate (check_profile_physics) runs first, and that it returns error=physics_blocked for changes that would introduce new failures. It also clarifies that pre-existing failures do not block unrelated edits. This adds significant behavioral context. The destructiveHint is consistent with 'overwrites stored settings'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense. It front-loads the core purpose, then adds essential details (atomicity, physics gate, error behavior) without redundancy. Every sentence adds value, and the structure is well-organized: purpose, execution steps, and validation/error handling.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no output schema, the description covers the key aspects: what it does, the atomic apply, the physics gate, and error handling. It does not explain the return value, but that may be less critical for a write operation. The main gap is the ambiguous 'type' parameter, which prevents full completeness. Overall, it is quite thorough for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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. It clarifies 'name' (the preset's name) and 'changes' (the settings to edit), but 'type' is left entirely unexplained. The description does not indicate what values 'type' should take, how it relates to 'name', or the structure of the 'changes' object beyond being a nested object. This is a significant gap for an agent to invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Edit a named preset's settings and persist them.' It specifies the action (edit), the resource (named preset), and the outcome (persist). The title 'overwrites stored settings' and the detail about saving under the same name further distinguish it from sibling tools like save_preset or delete_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: to modify and persist an existing named preset. It does not explicitly list alternatives or exclusions, but the phrase 'selects it ... saves under the same name' implies editing existing presets rather than creating new ones. Sibling tool names (save_preset, delete_preset, rename_preset) help contextualize, though the description does not directly reference them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint=true, the description adds valuable behavioral context by mentioning 'merged config values' and the optional filtering to 'keys'. It does not contradict the annotations and enriches the understanding of what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the verb 'Read', and contains no unnecessary words. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter and no output schema, the description covers the core functionality and parameter usage sufficiently. The read-only nature is already annotated, and 'merged config values' conveys the expected return content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for the 'keys' parameter, but the description explicitly states it filters config values by 'keys', giving essential semantic meaning. This compensates well for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Read merged config values' uses a specific verb and resource, clearly indicating a read operation on the merged configuration. It also notes the optional filtering by keys, which distinguishes it from related config tools like get_preset_config or set_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for retrieving the effective merged configuration but provides no explicit guidance on when to use this tool versus alternatives like get_preset_config or find_config_keys. There are no exclusion conditions or named sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate the tool is not read-only and not destructive. The description adds useful behavioral details like units (mm, degrees), relative vs absolute transformations, and the 'at least one' requirement. Does not disclose side effects or return behavior, but with annotations the bar is lower.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences contain all necessary information: action, parameter specifications, and usage constraint. No fluff, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a medium-complexity tool with no output schema, the description covers the essential invocation details completely. It could mention return values or edge cases, but the core usage and parameter semantics are adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates fully. It explains each transform parameter: translate (relative mm), rotate (relative degrees), scale (absolute factor), and implies object_id as the target. The array formats are explicitly shown, leaving no ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (move/rotate/scale) on a specific resource (object by id), distinguishing it from siblings like set_object_config or delete_object. The verb and target are unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use (transforming an object) and the constraint to provide at least one transform parameter. Does not explicitly mention alternatives or exclusions, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation is asynchronous, which is a key behavioral trait beyond the annotations. It also notes that it affects all objects, adding context. The annotations already indicate non-read-only and non-destructive, and the description does not contradict this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs purpose and usage into one line. It is front-loaded and every word adds value, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 behavioral context: it's async and requires polling get_job_status. It might also clarify the return value, but the instruction implies a job handle. Overall, it's sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 complete. Under the rubric, the baseline for 0 params is 4, and the description does not need to elaborate on any parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: auto-orient all objects for printing, with a specific verb (auto-orient) and resource (all objects). This distinguishes it from sibling tools like arrange_plate or transform_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 noting it's an async job and instructing to poll get_job_status until idle. This is a crucial operational guideline, but it does not explicitly state when to prefer this over alternatives like transform_object or arrange_plate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the agent knows it is a safe read operation. The description adds valuable behavioral context: it composes principles per situation, never returns preset bundles, and falls back to other tools if empty. This goes beyond the annotation without contradicting it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded. The first sentence states the core purpose, followed by a critical usage rule, a fallback note, and a practical recommendation guideline. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter, read-only annotation, and no output schema, the description covers the essential aspects: what it retrieves, when to call it, its fallback behavior, and how to use its output. However, it does not elaborate on the exact content of 'slicing knowledge' or the structure of the returned principles, which could be a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required 'query' parameter with no description (0% coverage). The description partially compensates by clarifying the query can be a topic, symptom, or intent, but it does not specify expected format (e.g., natural language vs. keywords) or provide examples, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves curated slicing knowledge and saved context notes for a topic, symptom, or intent. It uses a specific verb (retrieve) and resource (slicing knowledge + context notes), and differentiates from siblings by noting it composes principles per situation rather than returning preset bundles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to 'ALWAYS call before deriving or changing settings for a user goal,' which is a clear when-to-use directive. It also mentions fallback to find_config_keys/web search, providing an alternative path, and gives presentation guidance for recommendations, all of which help the agent decide when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the minimal annotations by disclosing accepted file formats and version-specific STEP support. It also notes that large STEP files can take a minute to tessellate and that the call waits, which gives the agent a realistic expectation of blocking behavior. This is valuable context the annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, packing the core action, supported file types, and a performance caveat into two sentences. Every clause adds value, and the main action is front-loaded, making it easy for an agent to quickly understand what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is largely sufficient. It covers the operation, accepted formats, and potential blocking for large STEP files. However, it does not explicitly mention what the tool returns after loading or whether it replaces or adds to the current plate, which leaves a small but non-critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines a 'path' string with no description, so the description adds crucial meaning by clarifying the path is on the OrcaSlicer host and listing how the available formats, suggesting what file types are acceptable. While it could be more explicit about path format (absolute vs. relative), it compensates well for zero schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool loads a model file from a host path onto the current plate, using a specific verb and resource. It distinguishes itself from sibling tools like delete_object or transform_object by focusing on the import action. The added list of supported formats further sharpens its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool to import supported model files from the host into the current plate. It also includes the useful caveat that large STEP files may cause a wait. Although it doesn't explicitly mention alternatives or when not to use it, the purpose is unambiguous enough for a single-purpose load tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare readOnlyHint=true, so the description adds value by explaining view semantics, default frame selection per view, and the visual nature of output. It does not mention potential failure cases (e.g., preview before slice) but discloses the key behavioral distinction between editor and preview. No contradiction with the read-only annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with line breaks and purposeful sections. Each sentence adds information: the opening defines the output, then view definitions, angle list, and frame details. There is no redundant wording, and the format aids scanning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five optional parameters, no output schema, and no enums, this description gives enough context for correct invocation: it explains the two main views, angle options, frame defaults, and when to override frame. The only gap is the width/height parameters, but these are generic and unlikely to cause misuse. Overall it is nearly complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains 'view' values (editor vs preview), 'angle' options, and 'frame' behavior and defaults. However, width and height parameters are left entirely undocumented; though self-explanatory, they receive no semantic explanation, so the coverage is not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific statement: 'Render a PNG picture of the current plate so you can SEE it.' It then distinguishes between editor and preview views, which directly separates it from sibling tools that manipulate models or slicing. The purpose is unambiguous and action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete when-to-use guidance for each view: editor view for checking orientation/contact before slicing, preview view for checking support after slicing. It also explains when to pass the frame parameter explicitly (side view of a small part). However, it does not explicitly mention alternatives among sibling tools or state when not to use this tool, so it falls short of full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false, which the description aligns with by describing a non-destructive mutation. It adds valuable behavioral context: what 'adaptive' does, the quality range, and that 'reset' restores uniform layers, going beyond the minimal annotation hints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core purpose, and every clause adds value. It efficiently covers modes, parameters, and aliases without unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters and no output schema, the description adequately covers the main behaviors and parameter semantics. It lacks explicit mention of return values or error conditions, but these are less critical for a simple setter tool and are not required by the schema context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description compensates by explaining the 'mode' values and the 'quality' scale (0..1, higher = finer). It does not explicitly explain 'object_id', but it is naturally implied by 'for one object' in the description and the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: setting variable layer height for one object, with specific modes ('adaptive' and 'reset'). It distinguishes itself from sibling tools like 'set_height_range' by explicitly scoping to a single object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 this tool: to generate an adaptive layer height profile or restore uniform layers. It does not explicitly mention when not to use it or name alternatives, but the mode-based behavior makes the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate it is neither read-only nor destructive. The description adds important behavioral context about being an async job and needing to poll a status endpoint, which is valuable beyond the annotations. It does not contradict the annotations and clarifies the execution model.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is a single, focused sentence with an embedded instruction. It is front-loaded with the core action and adds the necessary async detail in parentheses. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 covers everything an agent needs: what it does, that it is async, and how to check completion. It is a complete specification for this simple action.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is empty. The description does not need to explain parameter meanings. A baseline of 4 is appropriate since there is nothing to clarify; the tool's behavior is fully described for a parameterless action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Auto-arrange all objects on the plate'. It uses a specific verb ('arrange') and resource ('objects on the plate'), and the parenthetical about async job distinguishes it from similar tools like auto_orient by signaling it's a batch operation on all objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on how to use the tool ('poll get_job_status until idle') and implies the asynchronous nature. However, it does not explicitly mention when to avoid this tool or discuss alternatives such as auto_orient or transform_object, so it falls short of full alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate this is a mutating action (readOnlyHint=false, destructiveHint=false). The description adds useful behavioral context: it can unwedge stale 'slicing' states and is safe when idle, which goes beyond the simple annotation flags. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences cover the main action, an edge case, and a safety note. Every phrase adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless action with no output schema, the description is complete: it states what it does, when it applies (including stale state), and its safety profile. No further context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes no parameters, so the schema coverage is 100% trivially. The description doesn't need to add parameter details; the baseline for zero-parameter tools is 4, and the description adequately explains the action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 identifies the resource ('a running slice'), and also explains the secondary purpose ('unwedge a stale slicing state'). It clearly distinguishes from siblings like slice and get_slice_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (aborting a running slice, resolving stale state) and includes a safety note ('Safe when idle'). It doesn't explicitly name alternatives or say when not to use it, but the usage is well implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive behavior. The description adds value by specifying the copy is offset from the original, and that it operates by object id. This gives concrete behavioral context beyond the annotation flags.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and object, includes the key detail (offset copy), and contains no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and non-destructive annotations, the description fully captures the action and outcome. It explains what happens (adds a copy) and how the copy is positioned (offset), making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the sole parameter. The phrase 'by id' clearly indicates that object_id is the identifier of the object to duplicate, adding semantic meaning beyond the raw type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Duplicate') and resource ('an object on the plate by id'), clearly indicating the operation. It also adds 'adds a copy, offset from the original', which distinguishes it from sibling tools like delete_object or transform_object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it duplicates an existing object, implying when to use it (when a copy is needed). It does not explicitly name alternative tools or state exclusions, but the context is unambiguous enough for an agent to select this over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, covering safety. The description adds meaningful behavioral detail: it notes that the id is 'stable', which is valuable for agents that need to persist references across calls. It also explicitly discloses the data fields returned, which is especially useful because no output schema is provided. However, it doesn't discuss ordering or pagination, though that may be unnecessary for a simple list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and the data returned. Every word earns its place; there is no fluff or repetition of the title. The colon and the field list are efficient and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with no parameters and no output schema, the description is complete: it identifies the operation scope (current plate) and the exact fields returned. The readOnlyHint annotation covers the safety profile, and the field list suffices without a formal output schema. No additional context is needed for an agent to use this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description provides all necessary semantic context by indicating that it operates on the 'current plate', which is the singular implicit context. No parameter clarification is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'List objects on the current plate.' It enumerates the returned fields (id, name, size_mm, transform), making the purpose unambiguous. It is distinct from sibling tools like list_presets, which list presets rather than plate objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies usage: call when you need to see the objects currently on the plate and their properties. It does not explicitly name alternatives or exclusions, but the scope is well-defined. Sibling tools like set_object_config or transform_object suggest mutations; list_objects is the read-only counterpart, which is evident from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses a significant API limitation: the current fork build may report valid with an empty warnings list even when the GUI shows a plate-boundary toast, explaining the fork must populate the plater warning list. This is rich behavioral transparency about potential false negatives.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The opening sentence is a clear, front-loaded purpose statement. The NOTE adds a necessary caveat but is slightly verbose/run-on; could be tightened while preserving the important behavioral limitation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description covers what it returns (warnings/errors plus validity), why to use it, and a critical edge-case limitation. The caveat about fork behavior makes it a complete, self-contained reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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; the description appropriately avoids adding parameter details. Baseline 4 for zero-param tools applies, since there is nothing to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns warnings/errors and validity from the last/current slice, positioning it as the fast 'did anything go wrong' check. This distinguishes it from sibling status/breakdown tools by focusing exclusively on warnings/errors and the fix-cleared confirmation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames usage as the fast health check and the way to confirm a fix cleared, giving clear context for when to call. It lacks explicit references to alternatives or when-not-to-use, but the context strongly implies selecting this over heavier status/breakdown endpoints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavioral details beyond the readOnlyHint annotation: variants are applied over the original config and reset between runs, the config is restored exactly, and slice validity is left false. It also explains that all deltas and percentages are precomputed and should be relayed as-is, which is valuable context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries relevant information: purpose, variant format, reset/restore behavior, output contents, recommendation logic, and performance caveats. It is well-structured and free of filler, earning a top score for a tool of this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no output schema, this description covers inputs, outputs, side effects, and performance guidance. It explains the returned headline/table_markdown/variants structure and the meaning of recommended and recommended_is_dominant, making the tool fully self-contained for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates well by defining the variants structure, the meaning of changes={}, baseline default behavior, and the effect of detail=True. The timeout parameter is not mentioned, but it is a conventional integer with a default; the other three parameters receive clear semantic explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Slice the current plate under several named variants and compare the cost of each.' This clearly states the tool's function and differentiates it from siblings like slice, compare_settings, or slice_and_wait.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context for when to use the tool (comparing costs across variants) and gives explicit guidance on when to set detail=True and how to present results with many variants. However, it does not explicitly name alternative tools or state when not to use it, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and description adds meaningful context: that it aggregates multiple data sources, that slice warnings are only as complete as the fork exposes, and that it's a starting point. This goes beyond the annotation by explaining the tool's synthetic nature and caveats.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, and the second sentence adds important caveats and pairing advice. No wasted words or repetition of schema/annotation info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 is the primary source of semantic info. It lists the key categories (app/slice status, objects, bed settings, warnings), notes the limitations of warnings, and points to complementary tools. This is complete enough for an agent to understand the tool's behavior and decide when to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description does not need to explain parameters; instead it compensates by explaining the tool's scope and what it checks, enriching the agent's understanding despite the absence of inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('diagnose') and resource ('plate'), and enumerates exactly what it covers (status, objects, bed settings, warnings). It distinguishes itself from sibling tools by positioning as a one-call aggregation that avoids chaining status->objects->config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly provides when to use ('Start here for why won't this slice / fit'), and names alternatives/partners: 'see get_slice_warnings' for completeness and 'pair with check_placement' for bed fit. This is clear guidance on usage vs. alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing storage details: 'local plain files' and 'user-readable and deletable'. This adds meaningful context about the tool's side effects and accessibility, which annotations do not provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences with no filler. It front-loads the core purpose and then efficiently packs scope formats and storage behavior. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is fully sufficient. It covers purpose, parameter semantics, and behavioral details, leaving no critical gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema coverage at 0%, the description compensates well for the 'scope' parameter by enumerating valid formats ('machine:<printer>/<filament>', 'user', 'project:<name>'). The 'note' parameter is self-explanatory from its name. This adds necessary semantic meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 with a specific verb ('Persist a context fact') and resource ('for future sessions'). It distinguishes itself from all sibling tools, which focus on slicing/printing operations. The scope examples further clarify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the scope examples (machine, user, project), indicating when this tool is relevant. However, it does not explicitly state alternatives or when not to use it, though no sibling offers similar functionality. This is clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint=true, and the description adds valuable behavioral context: the tool 'overwrites stored settings' (in the title), creates/updates, is visible in the GUI immediately, and handles inheritance via the detach parameter. It also adds the important safety precondition about not saving when verdict=blocked, going well beyond what annotations provide. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary action, and every sentence serves a purpose: purpose, parameter meanings, and safety precondition. It avoids wasted words and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 moderately simple parameters, the description covers all essential aspects: what it does, parameter semantics, side effects (GUI visibility), and a critical precondition. It is complete for an agent to decide when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description carried the burden of explaining parameters. It explicitly defines the allowed values for 'type' ('print|filament|printer') and explains the effect of 'detach=True'. The 'name' parameter is self-evident as the preset's name but lacks explicit uniqueness or format details. This is solid compensation, though one parameter remains implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Save') and resource ('currently edited settings as a named user preset'), and clearly distinguishes this from sibling tools like list_presets or delete_preset by adding 'create or update, visible in the GUI immediately'. It unambiguously identifies the tool's scope and differentiates it from related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit preconditions for use: 'Run check_profile_physics first; do not save when verdict=blocked.' It also clarifies the supported type values. However, it does not explicitly discuss alternatives like edit_preset, though 'create or update' largely covers that distinction, so it is clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals key behavioral traits: default filtering to user presets plus the selected preset, the 'noise' of ~400 system presets, and the hidden_system counter for filtered entries. This gives the agent significant insight into expected behavior and output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: first sentence states the purpose, second explains default behavior and parameter usage, third describes the hidden_system output. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given only two optional parameters, a readOnlyHint annotation, and no output schema, the description covers the essential contextual information: default filtering, parameter effects, and a key return field (hidden_system). It is sufficient for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameter descriptions (0% coverage), but the description fully explains both parameters: include_system=True for the full list, and type='print'|'filament'|'printer' to restrict to a category. It also clarifies the default behavior associated with leaving parameters unset.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists print/filament/printer presets with flags for system/selected/visible. This specific verb+resource+scope differentiates it from sibling preset tools like save_preset, delete_preset, and select_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (listing presets) and how to adjust behavior via include_system and type parameters. However, it does not explicitly name alternative tools for exclusions or when-not-to-use scenarios, so it misses the 'alternatives' criterion for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that it uses object footprint rather than sliced toolpath, excludes skirt arcs/travel/wipe, and is approximate. This is rich behavioral context that helps manage expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by return info and limitations. It is succinct, well-organized, and every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 fully explains return values (per-object fit, bbox, clearance, overflow) and limitations. It is complete for an agent to decide when and how to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters; it adds no param-specific semantics, but none are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool estimates whether objects fit in the printable area, including skirt/brim. It distinguishes itself from siblings like get_slice_warnings by emphasizing it is an approximate first-pass estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to prefer this (fast first-pass) and when to use the alternative (get_slice_warnings for tight margins). Also notes the limitation 'single-instance objects only', helping an agent decide when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds the behavior of fetching live config, overlaying proposed changes, running math, and the significance of the blocked verdict. This is valuable, non-contradictory context beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by a clear action directive. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a pre-save check tool with one optional parameter and no output schema, the description covers purpose, key behavior, the critical blocked verdict, and its place in the workflow via the save_preset reference. Complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 `changes`. The description clarifies it as an 'optional proposed changes' object, giving it meaningful semantics. However, it does not detail the expected structure, though the open-object schema makes this less critical.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Deterministic pre-save gate' that fetches live config, overlays optional changes, and runs flow/temperature/geometry/cooling math. It distinguishes itself from save_preset by explicitly instructing to run before saving.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'RUN THIS BEFORE save_preset' and warns 'verdict=blocked means DO NOT SAVE,' providing clear when-to-use guidance and a critical exclusion condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses significant behavioral details: the stateless predicted-vs-observed check, the 'prediction_check' flag for 'clamped' speed, and the degraded response format on incompatible builds or missing slices. This adds substantial transparency about return values and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the primary purpose, then details the return data fields, and ends with degradation behavior. Each sentence adds value, with no redundancy or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 enumerates the return types (per-role time/filament, speed/flow ranges, global distributions, per-layer aggregates, prediction_check) and explicitly mentions degradation scenarios. For a zero-parameter tool, this is complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 100%, so there is nothing to add. The baseline for 0 params is 4, and the description compensates by clearly describing the output semantics, which is the relevant aspect here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's function: 'Per-feature breakdown of the last slice + a stateless predicted-vs-observed flow check.' It answers 'which feature is the time hog' directly, clearly distinguishing this from sibling tools like get_slice_status or get_slice_warnings by focusing on per-feature time/flow breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'Answers which feature is the time hog directly instead of trial slicing.' It also states when it cannot be used: 'Degrades to {"available": false, "reason": ...} on fork builds that don't emit the breakdown, or when there is no valid slice.' This gives clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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/MaxEllis/orcaslicer-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server