Almond MCP
Server Quality Checklist
Latest release: v0.2.0
- Disambiguation5/5
Each tool targets a distinct entity or action (e.g., get vs list vs place for different asset types). The only potential overlap between publish_objects_to_chestnut and publish_to_chestnut is clearly differentiated by their descriptions (detailed vs simplified). No two tools serve the same purpose.
Naming Consistency5/5All 33 tools follow a consistent verb_noun snake_case pattern (e.g., apply_drawing_style, create_design_scene, list_capsules). No mixing of conventions like camelCase or different verb styles.
Tool Count4/533 tools cover a broad domain (scene creation, asset management, scripts, physics, publishing, validation). While slightly high compared to typical well-scoped servers (3-15), the number is justified by the breadth of functionality and each tool serves a clear purpose.
Completeness4/5The surface covers core workflows: creation, retrieval, placement, execution, validation, and publishing. Minor gaps exist, such as lack of explicit delete/remove tools for objects or scenes, and no update tool for scenes. However, most lifecycle stages are present.
Average 3.5/5 across 33 of 33 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 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 MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of revealing behavior. It only says 'searches', failing to disclose pagination, filtering behavior, or any constraints (e.g., case sensitivity, fuzzy matching). This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence) but under-specified. It sacrifices informativeness for brevity, failing to earn its place by providing necessary context. It would benefit from more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex input schema (7 parameters) and 31 sibling tools, the description is far from complete. It does not clarify how search differs from list, what the output schema returns, or any usage nuances. The presence of an output schema does not excuse the lack of context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage in the schema itself. The description does not explain any parameters (e.g., what 'category', 'query', or 'max_width_mm' mean), leaving agents to infer from names alone. It adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Searches the diagram asset library' clearly states the tool's purpose: to search for assets. It implicitly distinguishes from siblings like 'list_diagram_assets' (which lists all) and 'get_diagram_asset' (which retrieves a specific one).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_diagram_assets' or 'search_drawing_assets'. The description does not mention any prerequisites or context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description states it returns metadata but does not disclose behavioral traits like read-only nature, required permissions, or data freshness. Given no annotations, more detail is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (4 words) but lacks detail. It is front-loaded but does not effectively communicate all necessary information. Could be expanded without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return values are covered elsewhere. However, param semantics are incomplete and no usage guidance provided. The description does not sufficiently contextualize the tool for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter asset_id with no description (0% coverage). Description does not explain what asset_id is or how to obtain it. No additional meaning added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns metadata for a single diagram asset. The verb 'Returns' and resource 'diagram asset's metadata' are specific. Differentiates from sibling list_diagram_assets by implying single asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use get_diagram_asset vs alternatives like search_diagram_assets or list_diagram_assets. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must disclose behavior. It only states it returns a recipe but doesn't mention read-only nature, error behavior for missing recipe_id, or any side effects. Insufficient for safe agent decision-making.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at one sentence, but this conciseness comes at the cost of missing essential information. It is front-loaded but lacks structured detail.
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?
Output schema exists but description is too minimal. For a simple getter with one parameter, more context about the recipe's purpose or content would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must explain the parameter. It does not mention what recipe_id represents, how to obtain it, or any constraints. The description adds no value beyond the schema's property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns a single complete audited drawing recipe, distinguishing it from list_drawing_recipes which returns multiple. The verb 'Returns' and specific resource are clear, though 'audited' could be expanded.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_drawing_asset or list_drawing_recipes. Missing context for when a recipe is needed vs other drawing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. Description merely states it 'returns' data, implying a read operation, but lacks details on side effects, authorization needs, or rate limits. Could be improved with explicit read-only indication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but under-specified. It wastes no words but could include additional context without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, low parameter coverage, and absence of output schema details, the description is insufficient for an agent to fully understand tool behavior and return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning to the single parameter (plan_id). The parameter remains a raw string with no format or example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns a dependency graph and step states, which is a specific verb and resource. It distinguishes from siblings like create_generation_plan (create) and update_generation_step (update), but not from other get tools (e.g., get_design_scene).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context provided for selection among sibling tools like get_design_scene or list_capsules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It does not mention pagination, authentication, or any side effects. It only states the basic function, leaving significant behavioral aspects (e.g., rate limits, data freshness, response structure) undocumented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure (e.g., no bullet points, no separation of concerns). It is minimally adequate but could be more informative without being longer by using structured formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters and multiple sibling tools, the description is incomplete. It does not address typical use cases, the meaning of parameters, or how this list differs from search or list functions. The presence of an output schema does not excuse the lack of input and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and 3 parameters, the description adds no meaning beyond the parameter names. It does not explain 'limit', 'offset', or 'category' – for instance, what category values are valid or how offset works. The description fails to compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists' and the resource 'diagram assets' with examples (people, trees, symbols), making the purpose specific. However, it does not explicitly differentiate from the sibling tool 'search_diagram_assets', which also deals with diagram assets. The purpose is clear but not fully contextualized among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_diagram_assets' or 'list_drawing_assets'. There is no mention of prerequisites, expected contexts, or exclusions. The description only implies basic usage with no comparative or conditional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states the tool 'places' an asset but does not disclose side effects (e.g., overwriting, coordinate system, success/failure behavior) or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks necessary detail. It is front-loaded but sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and no annotations, the description is inadequate. It does not mention the return value or output schema, leaving the agent uncertain about what happens after placement.
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 input schema has 6 parameters with 0% description coverage. The description adds no meaning to the parameters; it only mentions the asset type but does not explain 'x', 'y', 'z', 'scale', 'rotation_degrees', or the required 'asset_id'.
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 specifies the verb 'places' and the resource 'indexed diagram asset', and lists supported formats (SVG, DWG, DXF), making the purpose relatively clear. It distinguishes from sibling tools like 'place_drawing_asset' by focusing on diagram assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'place_drawing_asset'. There is no mention of prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It mentions that the tool returns a 'summary' and uses a 'stable handle', but does not disclose whether it is read-only, if authentication is required, what happens on invalid scene_id, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. However, it sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential context such as usage guidelines, behavioral traits, and parameter details necessary for correct tool selection and invocation. The large set of sibling tools increases the need for disambiguation, which is absent.
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%, requiring the description to explain parameters. It only mentions 'by stable handle' which weakly links to the 'scene_id' parameter, but does not clarify what a stable handle is, how to obtain it, or any constraints on the input string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Returns' and resource 'scene summary', clearly indicating the tool retrieves a summary of a design scene. The qualifier 'token-efficient' adds some context but does not differentiate from other 'get_*' sibling tools like 'get_diagram_asset'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'create_design_scene' or other 'get_*' tools. There is no mention of prerequisites, limitations, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions 'searches' and the library. It does not disclose whether the tool is read-only, any pagination behavior, or other behavioral traits. Minimal transparency beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with purpose. However, it is too brief to cover needed details, sacrificing completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 undocumented parameters and no behavioral details, the description is incomplete. While an output schema exists, the description fails to provide necessary context for effective tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 7 parameters (limit, query, offset, category, max_depth_mm, max_width_mm, max_height_mm). The description adds no parameter information, failing to compensate for the schema's lack of documentation. This is a severe 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 tool searches a specific resource: the 'controlled architectural drawing-asset library'. This distinguishes it from sibling tools like search_diagram_assets or search_ikea_furniture, but it lacks a verb beyond 'Searches' and does not specify what is returned.
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 'only the controlled architectural drawing-asset library', which suggests it is for that specific library and not for others. However, it does not explicitly state when not to use it or provide alternative tools, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral traits: only compact violations are returned and geometry remains in Rhino (non-destructive). However, with no annotations, it does not cover permission requirements, error behavior, or performance implications. The info is useful but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the primary action and key behavioral outcomes. Every word serves a purpose, but the structure could include parameter clarification without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists but is not referenced, and parameters are unexplained, the description feels incomplete. The tool's specific method (R-tree broad-phase) is mentioned, which adds context, but missing usage guidance and parameter details lower completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the two parameters (scene_id, detail_limit) beyond what is in the schema. Since schema coverage is 0%, the description must compensate but fails to add any semantic detail about how to use these parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs collision and room-containment checks using an R-tree broad-phase approach. It specifies the action and resource ('validate scene layout'), but does not explicitly distinguish it from the sibling 'validate_structure' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, typical scenarios, or exclusions. The description implies usage for validation but lacks explicit context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden for behavioral disclosure. It indicates mutation ('creates or updates') but omits details on side effects (e.g., overwriting existing layers), required permissions, or the return value (though output schema exists but is not described). The term 'audited' implies validation but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It efficiently conveys the core purpose. However, for a tool with an output schema and no parameter descriptions, slightly more elaboration would be beneficial.
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?
Although the tool has an output schema (not described), the description lacks behavioral context for a mutation tool. It does not mention return format, error conditions, or the lifecycle of the audited recipe. Given one parameter with no description, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, the description does not mention the parameter 'recipe_id' at all, leaving its purpose and allowed values completely unexplained. The schema provides a default but no further 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 the tool 'creates or updates' Rhino layer hierarchy, plot weights, colours, and linetypes, and specifies that it uses an 'audited drawing recipe'. This is a specific verb+resource combination that distinguishes it from sibling tools like get_drawing_recipe or list_drawing_recipes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., recipe must exist), nor any conditions under which other tools like execute_rhino_script or create_design_scene would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the scene handle is persistent, metadata remains local, and retrieval by ID avoids repetition. However, it omits side effects, permissions, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action. Concise, but could briefly mention parameters without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (unknown content), the description lacks parameter explanations, which are critical for correct invocation. It also does not clarify what the output is, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not mention the 'name' or 'units' parameters at all, leaving their purpose and usage entirely to the parameter names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Creates') and the resource ('persistent scene handle for a house or interior generation'). It distinguishes from siblings like get_design_scene (read) and validate_scene_layout (validation) by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., register_scene_instance). The description does not mention prerequisites, when not to use it, or contrast with similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full weight. It mentions efficiency and return values but fails to disclose whether the tool creates or updates instances, side effects, permissions, or behavior when instance_id is provided versus omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action and return values. It is not verbose, but given the tool complexity, it could benefit from additional structured details without becoming lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 11 parameters, no annotations, and an output schema not elaborated, the description lacks completeness. It does not explain the relationship between registering and moving (e.g., instance_id determines action), nor does it cover required versus optional parameters or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only implies x_mm and y_mm are position coordinates, but provides no meaning for the 9 other parameters like rhino_guid, scale, locked, or room_id, leaving the agent with only parameter names to infer functionality.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool registers or moves an asset instance in millimetres without retransmitting full metadata, which is a specific verb+resource action that differentiates it from sibling tools like place_diagram_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for efficient placement or movement but does not explicitly state when to use this tool versus siblings like place_ikea_furniture or validate_scene_layout, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only hints at storing state ('handles and step state') but does not disclose side effects, permissions, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (two sentences, 28 words) with no repetition of schema or annotations. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values are less critical. However, with three parameters and zero schema coverage, the description is insufficiently detailed, especially for 'goal' and 'scene_id'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description partially compensates by explaining the 'scope' parameter with examples. However, 'goal' and 'scene_id' are left completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a dependency-ordered local plan, which distinguishes it from retrieval or update tools like get_generation_plan and update_generation_step. However, 'local plan' could be more precise.
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?
It mentions valid scope values but does not explicitly contrast with alternatives or specify when not to use this tool. The context of storing handles and step state hints at usage, but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates a read operation (returns data) and lists what is returned, but with no annotations, it does not disclose any behavioral traits beyond the basic functionality. No mention of permissions, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the tool's primary function. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essentials but lacks context on error handling (e.g., missing asset_id) and does not hint at any limitations or edge cases.
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 input schema has 0% description coverage and the description does not explain the 'asset_id' parameter, its format, or provide examples. The parameter's semantics are entirely left to inference from its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns specific attributes (dimensions, provenance, availability) for a single IKEA furniture asset. It distinguishes from siblings like list_ikea_furniture (which lists multiple) and search_ikea_furniture (which searches).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving a single asset by ID, but it does not explicitly state when to use this over siblings (e.g., list for browsing, search for filtering). No conditions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it is a read operation returning 'compact diagnostics', but does not disclose what specific information is included, any side effects, or authentication requirements. With no annotations, the description provides a basic but not thorough behavioral profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, highly concise and front-loaded. It conveys the core purpose without excess, but could be slightly expanded for completeness.
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 zero parameters and an existing output schema, the description is minimally sufficient. However, it does not explain what 'compact diagnostics' entails or how the agent should interpret the output, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no conflict with the schema. Per guidelines, 0 parameters yields a baseline of 4, and the description confirms the no-param structure.
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 uses a specific verb 'returns' and identifies the resource as 'diagnostics for the local structured retrieval system', clearly distinguishing it from sibling tools that create, apply, or list assets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or not use this tool, nor any mention of alternatives. The description assumes the agent understands the context of 'local structured retrieval system' without elaboration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only provides bounds_mm format. Does not explain behavior on create vs update, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no superfluous 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?
Describes basic operation and one parameter, but given 4 parameters and no annotations, more detail on idempotency and output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description clarifies bounds_mm format. However, name, scene_id, and room_id are not explained, so only partial improvement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb ('creates or updates') and the resource ('room in the local scene ledger'). Distinguishes from siblings as no other tool explicitly handles room upsert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states what is returned, but does not mention that the operation is read-only, safe, or any error behavior. Important safety context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the purpose and key return fields. No wasted words; efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to detail return structure. However, it lacks context on error handling, required permissions, or how this tool relates to similar tools. Adequate for a simple get operation but incomplete for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds no meaning for the required parameter 'asset_id'. It does not explain its format, constraints, or how to obtain it. The description fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a single drawing asset, specifying three aspects: provenance, scale guidance, and availability. This distinguishes it from sibling tools like list_drawing_assets (which lists many) and other get_* tools focusing on different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied for retrieving a specific drawing asset by ID, but no explicit guidance on when to use this vs alternatives like list_drawing_assets or get_diagram_asset is provided. No exclusions or contextual hints given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral details. It reveals that assets are 'representation-only' and 'do not participate in room collision checks unless explicitly registered,' which is useful context. However, it lacks details on pagination, sorting, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately stating the action and resource. No extraneous information, front-loaded with the verb 'lists.' It earns its place without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three optional parameters and an output schema, the description provides context about asset types and behavior but omits parameter guidance. With output schema present, return values are covered, but the description could be more complete regarding filtering.
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 coverage is 0%, meaning the description does not explain any of the three parameters (limit, offset, category). While the schema provides defaults, the description adds no meaning beyond that, leaving the agent to infer category usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists 'representation-only entourage and graphic proxy assets,' distinguishing it from sibling tools like list_diagram_assets or list_ikea_furniture. It specifies these assets are intentionally isolated from IKEA product search, which clarifies the 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?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for listing drawing-specific assets but omits when-not-to-use or mentions of sibling tools for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only mentions the stability requirement for references but does not disclose side effects, error conditions, permissions, or mutation behavior expected for an update tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The main action is front-loaded, and the second sentence adds essential constraint on parameter types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, 3 required, and no annotations, the description leaves gaps: status values are undefined, plan_id/step_id roles unstated, and error handling missing. The presence of an output schema slightly mitigates but does not compensate fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description partially explains input_refs and output_refs (stable GUID handles) but provides no explanation for the required parameters status, plan_id, and step_id. With 0% schema description coverage, this is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 ('Advances a generation step') and the precondition ('after its dependencies complete'), effectively distinguishing it from sibling tools like create_generation_plan or get_generation_plan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use the tool (after dependencies complete) but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full burden. It discloses 'compact paginated asset cards' and 'controlled' library, but does not mention permissions, rate limits, or whether listing is read-only. Adequate for a list tool, but room for improvement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well structured: purpose, args, returns, usage tip. It is relatively concise and front-loaded. Minor redundancy like 'Optional exact category filter' could be tightened, but overall effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and alternative tool, but is incomplete on pagination parameters (limit/offset) and return format. Output schema likely provides details, but description should at least mention standard pagination controls.
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 has 0% description coverage, so description must explain parameters. It only elaborates on 'category' with examples, but does not explain 'limit' and 'offset', leaving two of three parameters undocumented. This is 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?
Description clearly states it lists furniture in a specific model library ('controlled IKEA Singapore model library'), and distinguishes itself from sibling 'get_ikea_furniture' by noting that list returns compact paginated cards while get is for full metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises using get_ikea_furniture for a selected asset needing full metadata, implying list is for browsing. However, does not mention sibling search_ikea_furniture or specify when to use list over search, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: the tool creates a reusable block, places it on a specific layer (ALMOND-DRAW::ASSETS), and only accepts files from a controlled manifest. This is fairly transparent, though side effects or conflict handling are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short paragraphs, each sentence adding distinct value. No filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks important context such as how to obtain asset_ids, the meaning of coordinate system, or the expected output. Given the absence of parameter descriptions, the description is incomplete for a 6-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for any of the 6 parameters (asset_id, x, y, z, scale, rotation). The agent must infer meanings from parameter names alone, which is insufficient for proper invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool places an indexed representation asset as a reusable Rhino block, and distinguishes it from IKEA product blocks by specifying the layer and manifest source, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at usage by contrasting with IKEA blocks and mentioning the manifest constraint, but it does not explicitly state when to choose this tool over siblings like place_diagram_asset or place_ikea_furniture, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains the source constraint (manifest resolution) and the action (importing to hatch pattern table). It does not cover potential side effects, idempotency, or error cases, but for a simple import tool, basic transparency is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The first sentence immediately states the purpose, and the second adds a critical security constraint. The structure is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no nested objects) and the presence of an output schema, the description covers the essential behavioral and sourcing context. Minor gaps like error handling or prerequisites exist, but completeness is adequate for the complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter asset_id has no description in the input schema (0% coverage). The description clarifies that it identifies the drawing asset containing .pat definitions, but does not provide format, example, or constraints. Some context is added, but more explicit parameter details would improve usability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and 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 imports AutoCAD-style .pat hatch definitions from an indexed drawing asset into the active Rhino document's hatch pattern table. The verb 'imports' and resource 'hatch pattern definitions' are specific, and the tool is distinct from sibling tools like place_drawing_asset or get_drawing_asset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the tool accepts only .pat files from the controlled DrawingAssetfiles manifest, indicating a security boundary. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that the tool lists 'compact audited' recipes, implying some filtering or preprocessing, but does not detail potential side effects, performance implications, or authentication needs. A score of 3 is appropriate as it adds some context but lacks full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that succinctly states the action and resource, with no extraneous words. It is front-loaded with the verb 'Lists' and efficiently conveys the necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description reasonably covers the tool's scope by listing the types of recipes included. However, it could clarify whether the list is exhaustive or subject to filters, but with zero parameters and output schema handling return values, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so according to the rubric baseline is 4. The description adds meaning beyond the schema by specifying the types of recipes listed (layer, lineweight, projection, export) and the 'compact audited' qualifier, which compensates for the lack of parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter 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 'Lists' and clearly identifies the resource as 'drawing recipes' with qualifying details: 'compact audited layer, lineweight, projection, and export recipes'. This distinctly separates it from sibling list tools like list_diagram_assets or list_drawing_assets.
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 or any exclusions. It only states what it lists, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only discloses search criteria and labeling of series matches. It does not mention read-only nature, pagination, or side effects, though these are implied. The output schema may compensate for return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a blank line, front-loaded with purpose, and every sentence adds value. No waste, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no annotations, the description covers the main search dimensions and usage context. The output schema exists, so return value details are external. Could mention query string usage or pagination, but overall adequate for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description references product language and room-fit dimensions (matching parameters like query, max_width_mm) but does not explain each parameter's purpose, defaults, or interaction. Parameter names are self-explanatory, but with 0% schema coverage, the description could add more 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 tool searches IKEA furniture by product language and room-fit dimensions, which is a specific verb+resource+criteria. It distinguishes from sibling tools like get_ikea_furniture (single item by ID) and list_ikea_furniture (browse without dimension search) by highlighting the unique search capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool before placing furniture and distinguishes between exact-dimension matches for final layouts and series-only matches for concept design. It does not explicitly mention when not to use or alternatives, but the guidance is clear and contextually useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses compilation process, execution nature (JIT, native), error types (compile/runtime), and return format. However, it lacks explicit mention of potential destructive side effects on the Rhino document, which is important for an execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-organized with a code block and namespace list. It is front-loaded with the purpose. Every sentence adds value; no redundant phrases. Slightly verbose but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (C# script execution) and no output schema (but described in text), the description covers input format, code requirements, execution process, error handling, and output structure. It is fully sufficient for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It extensively explains the 'script' parameter: must be C# source with a specific class structure, includes a code example, lists auto-imported namespaces, and describes return value format. This far exceeds basic schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs like 'sends', 'compilation', 'execution' to clearly state the tool's action on a resource (C# script in Rhino). The code example and namespaces further clarify the resource. No sibling tool has similar script execution intent, making it distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use: to execute custom C# in Rhino. It provides code requirements and namespaces, but does not explicitly contrast with alternatives (e.g., 'run_gh_definition'). Still, the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides useful behavioral details: import only on first call, subsequent calls create lightweight instances, rotation is around world Z, and no arbitrary file paths. This helps an agent understand side effects and constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, well-structured, and front-loaded with the primary action. Every sentence adds value without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema exists), the description covers key behaviors. It lacks error handling or prerequisite info (e.g., asset must be indexed), but overall it is sufficiently complete for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning to parameters: x,y,z as position in active document units, rotation_degrees as rotation around world Z, scale as scale factor, and asset_id as the IKEA asset identifier. This provides essential context beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool imports an IKEA SketchUp model as a reusable block and places an instance. It specifies the 'import only once' behavior and distinguishes itself from sibling tools like place_diagram_asset by referencing IKEA and SketchUp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's purpose and key behaviors (block reuse, instance creation, position units, rotation axis). It also notes it does not accept arbitrary file paths, implying when to use it for IKEA assets. However, it could be more explicit about alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses behavior: reusing asset_id updates existing asset, excluded unrelated objects, collider fallback, static body mass zero, and deterministic asset_id generation. All key behavioral traits are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and clear sections, but slightly verbose. Each sentence adds value, though could be more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity and no annotations, description covers usage, parameters, and return values. Lacks explicit differentiation from siblings and output schema details, but mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description thoroughly explains all 7 parameters including defaults, constraints (e.g., static bodies always zero mass), and intent (e.g., body_type options). Adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it exports Rhino objects as a GLB and publishes to Chestnut, specifying the verb and resource. However, it doesn't explicitly differentiate from sibling tools like 'publish_to_chestnut', which may also publish to Chestnut but with different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance to use after execute_rhino_script and validate_structure, and explains asset_id reuse. Does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It discloses that the tool is read-only (retrieval), specifies the output format (JSON string with components, descriptions, metadata), and mentions error possibility. No side effects or permissions are noted, but for a retrieval tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, with a clear topic sentence, then structured parameter and return info. It is not overly verbose, though the examples are helpful. Slightly more conciseness could be achieved, but it remains well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers all necessary aspects: purpose, parameter semantics, return type, and linkage to sibling tool list_library. It leaves no ambiguity for an agent to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0% description coverage, the description provides comprehensive information for the logic_id parameter: format (filename without extension), prerequisite (use list_library first), and examples. This adds significant value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves parsed physics context for a specific Kangaroo2 or Karamba3D archetype, specifying the domain and return content. It distinguishes itself from sibling tools like list_library by directing users to use that first to get valid IDs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use list_library() first to see available IDs, providing a clear usage prerequisite. While it doesn't list alternatives or exclusion cases, the single-parameter tool is straightforward and the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently states that it 'hides collider, scale, mass, and rigid-body details' and explains the behavior parameter. Some side effects (e.g., overwriting) are not mentioned, making it slightly incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: purpose first, then usage cue, then parameter details. No redundant sentences; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 params, no annotations, and an output schema (exists but not shown), the description covers all parameters and provides usage context. However, it does not describe the output or post-publish behavior, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds detailed meaning for all 4 parameters: explains guids as Rhino GUIDs, asset_name as human-readable, behavior with enum expansions, and asset_id as stable link. Fully compensates for schema lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Publishes Rhino objects to Chestnut using safe semantic defaults' and positions it as 'the preferred publishing tool for normal use', distinguishing it from the sibling 'publish_objects_to_chestnut'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call it when the user says things such as "publish that to Chestnut"' and implies it's for normal use with safe defaults. However, it does not explicitly contrast with the sibling tool for advanced scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description appropriately conveys a read-only listing operation and specifies the return format as a JSON list, though it could mention any potential limitations or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences covering purpose, usage, and return format without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, straightforward list), the description fully covers the tool's purpose, usage, and output, making it 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?
There are zero parameters, and the description adds value beyond the schema by explaining the output and providing an example list, which aids interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the specific resource 'physics logic archetypes in the Grasshopper library', which distinguishes it from sibling tools like get_logic_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using this tool first to discover available logic IDs before calling get_logic_by_id, providing clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that only audited=true capsules can run, audited=false are retrieval context only, and lists output fields. It lacks details on pagination or error handling, but given the output schema likely covers structure, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with purpose, usage note, parameter explanation, and return format. Every sentence adds essential information; no fluff 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 the complexity of capsules and the presence of an output schema, the description adequately covers the tool's role, parameters, behavioral constraints, and return fields. It enables correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description entirely explains both parameters: capability (an optional filter with enumerated values provided) and audited_only (a boolean to filter runnable capsules). Adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists Grasshopper capsules, which are GH definitions with typed contracts executable via run_gh_definition. It distinguishes itself from siblings like run_gh_definition and get_logic_by_id, leaving no ambiguity about its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this FIRST to discover what capsules exist before calling run_gh_definition.' It also clarifies when to use get_logic_by_id for non-audited capsules, providing clear conditional guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: client-side validation, exact port error naming, input value forms (geometry, atomic, arrays), unit handling, optional input defaults, and response structure including analysis_method and confidence. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (purpose, workflow, input forms, restrictions, response) but is somewhat verbose. Every sentence adds value, but it could be more concise without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (4 params, nested objects, output schema), the description is highly complete, covering input formats, validation, output interpretation, and error cases. It complements the output schema with context on semantics and confidence levels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains all 4 parameters in detail: capsule_id from list_capsules, inputs with complex structure (geometry GUIDs vs simple values), optional seed for stochastic definitions, timeout_s with default and max. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs an audited Grasshopper capsule through the Rhino bridge and returns outputs. It distinguishes from siblings by specifying the workflow involving list_capsules and execute_rhino_script, making the purpose specific and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidelines: call list_capsules first to get capsule_id and port names, create geometry with execute_rhino_script, then pass GUIDs here. It also states when not to use (non-audited capsules) and refers to authoring docs for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: three analysis pathways with confidence levels, that the verdict names the method, confidence interpretation, return value structure (JSON unchanged), and iteration behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is lengthy but well-structured: starts with purpose, then usage, analysis details, failure handling, parameter list, return value. Every sentence adds value; minor wordiness but justified by complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters and presence of output schema, the description covers all aspects: parameter semantics, return fields (status, passed, verdict, etc.), analysis methods, iteration limits. Complete for a complex structural validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds full meaning: explains guids as Rhino GUIDs from script output, lists all structure_type options with descriptions, specifies load_kn default and unit, lists material options. Adds value beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it validates AI-generated geometry against Karamba3D structural analysis and specifies it should be called after execute_rhino_script. This distinguishes it from sibling tools like execute_rhino_script (generation) and validate_scene_layout (layout validation).
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 'Call this AFTER execute_rhino_script' and provides iteration guidance: modify design and call again on failure, edit only worst members when worst_member_guids present, iterate up to 3 times. Also explains how to interpret low confidence results.
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/liangjunglj-cpu/almond-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server