mcp-printable

by AaronGoldsmith

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.3
Disambiguation4/5
Most tools target distinct operations, but rendering tools (screenshot vs tiled vs turntable) and cross-section tools (single vs gallery) have overlapping purposes that could confuse agents. The descriptions mitigate ambiguity but don't fully eliminate it.
Naming Consistency5/5
All tools follow a consistent pattern: engine prefix (blender_/scad_) + verb + noun(s), all lowercase with underscores. Verbs vary (import, get, clear, render, check, validate, export, etc.) but the naming style is uniform and predictable.
Tool Count2/5
With 29 tools, the set exceeds the 25+ threshold for 'too many.' While the two-engine scope (Blender and OpenSCAD) partially justifies the count, the sheer number is heavy and risks overwhelming agents.
Completeness5/5
The toolset covers the full 3D-printing workflow: import, geometry creation/editing (via execute_code and boolean), inspection (renders, cross-sections), printability validation (overhang, thin walls, clearance, intersection, retention), and export (STL, BLEND, SCAD). No critical gaps are apparent.
Average 4.3/5 across 29 of 29 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.json to 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is established. The description adds value by explaining the meaning of the default clearance value and the consequence of exceeding it (parts fuse), which is useful behavioral context. However, it does not disclose what the tool returns (e.g., a number, boolean, or report) or how it behaves beyond the threshold check, leaving a gap in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the main idea front-loaded. The first sentence defines the tool's purpose, and the second provides practical context for the default parameter. There is zero wasted wording, and each clause earns its place. This is excellent conciseness for a tool with a simple input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (not shown), the description leaves key invocation details unclear. It does not specify acceptable formats for object_a and object_b, which are required parameters, nor does it state what the tool actually returns (pass/fail, distance, list of violations?). Given the tool has similar siblings and the agent must select and call it correctly, the lack of these details makes the description incomplete. The FDM context is useful but does not cover the operational essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does clarify min_clearance_mm by providing the default's meaning and typical usage, which is helpful. However, it does not explain what object_a and object_b should be (e.g., object names, paths, or selected meshes), leaving the most critical parameters underspecified. The description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the core function as 'Minimum gap between two objects', which clearly identifies the metric being checked. The added context about the default 0.3mm being typical FDM print-in-place clearance distinguishes it from other check tools, though it lacks an explicit verb like 'checks' or 'returns'. It does not differentiate from sibling tools such as blender_check_intersection or blender_check_clearance_sweep, but the purpose is unambiguous enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in contexts where print-in-place clearance matters, noting that below 0.3mm parts fuse. However, it provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The 'when-to-use' is only inferred from the FDM print-in-place example, which is insufficient for an agent deciding between similar check tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false and destructiveHint=false, indicating this is a mutating operation. The description adds the useful disclosure that relative paths are resolved against the MCP server's working directory. However, it does not clarify whether the import appends to the scene or replaces it, nor what happens if the file is missing or invalid, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The first states the core action, and the second adds a critical operational detail. Every sentence earns its place and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter import tool, the description covers the essential purpose and path-handling behavior. An output schema exists, so return value documentation is not the description's burden. Minor gaps remain around error handling and whether the import is additive, but given the low complexity, the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema for the single 'path' parameter is bare (0% description coverage), but the description compensates by explaining how relative paths are handled. This adds meaning beyond the schema, yet it does not specify accepted path formats (e.g., absolute vs. relative, file extension requirements) or whether directories are allowed, so the compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Import') with the resource ('an STL file') and target ('into the scene'), clearly stating what the tool does. It is distinguishable from siblings like blender_export_stl and scad_import_stl by the phrase 'into the scene' and the Blender tool name, though it does not explicitly compare itself to alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives such as scad_import_stl or blender_export_stl. The only additional context is the path resolution note, which is operational detail rather than usage guidance. There are no stated prerequisites, exclusions, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety. It adds context about the return format (isometric render plus dimensions), which is useful beyond the annotations. However, it does not disclose potential limitations or parameter effects (e.g., how object_names filters objects), leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and contains no filler. Every sentence adds useful information about what the tool does and returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description partially explains return values ('isometric render plus dimension measurements') but omits details like units, format, and the effect of the optional object_names parameter. Given the tool's modest complexity and the presence of annotations, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—the schema provides no descriptions for object_names. The tool description also fails to explain the parameter's meaning or how it affects output. While the parameter name 'object_names' is somewhat self-explanatory, the description does not compensate for the lack of schema documentation, so the agent is left guessing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Render the scene') with a specific output ('bounding box dimension data for each object' and 'isometric render plus dimension measurements'). This distinguishes it from sibling render tools like blender_render_tiled or blender_render_turntable, which likely produce different output formats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the tool's purpose: use it when you need dimension measurements alongside a render. However, there is no explicit guidance on when to choose this over other render variants (e.g., get_screenshot, render_tiled) or any exclusions, so it stays at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (idempotentHint=true, destructiveHint=false) already provide the safety profile. The description adds no extra behavioral detail, such as what happens if the old name isn't found or whether the rename affects references. It doesn't contradict annotations, but it doesn't enrich them beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an illustrative example. Every word earns its place, and the structure is front-loaded with the action then the example. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter rename tool with an output schema and safety annotations, the description is sufficiently complete. It covers the core action and parameter semantics. Missing details like failure behaviors are not critical for this simple operation, and the output schema handles return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the example 'Cylinder.001' -> 'hinge_barrel' clearly maps old_name to the current name and new_name to the replacement, adding meaning beyond the property titles. However, constraints like name uniqueness or valid character sets are not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Rename') and the target ('an object'), with a concrete example ('Cylinder.001' -> 'hinge_barrel') that makes the purpose unmistakable. This distinguishes it from sibling tools focused on rendering, import/export, or modeling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The example implies the tool is used when an object's name needs to be changed, but the description provides no explicit when-to-use or when-not-to-use guidance, nor does it mention prerequisites like the object needing to exist. It's adequate for a simple tool but lacks proactive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe nature is covered. The description adds valuable behavioral details: the mutual exclusivity error ('sending both raises ValueError'), the meaning of percent as a position along the axis, and that multiple objects are cut with the same plane and rendered together. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short paragraphs with strong front-loading of purpose. Every sentence earns its place: purpose, parameter meanings, and a critical error condition. No filler or repetition; it is appropriately sized for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, parameter semantics, and typical use cases, which is strong. However, with no output schema, it does not explain what the tool returns (e.g., an image path or in-scene rendering), and axis options beyond the default are not described. For a rendering-focused tool with sibling render tools, this missing output clarity is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains percent (0-100, 50=middle) and object_names (multiple objects cut together) plus the mutual exclusivity rule. However, axis is left undocumented (only default 'z' appears in schema), and object_name singular is only implied through the exclusivity rule. Not all parameters receive equal semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Cut and render the exposed internal face.' It clearly distinguishes itself from sibling render tools by stating it verifies internal geometry 'that renders can't show' and lists concrete use cases (pin holes, wall thickness, knuckle interleave, clearance gaps). This goes beyond a vague purpose and sets clear scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit context for when to use: 'Use to verify internal geometry that renders can't show' and details when object_names is essential (chain joints, ball-in-socket captivity). It also provides a critical usage constraint: provide exactly one of object_name OR object_names. However, it does not explicitly mention when NOT to use or name alternative sibling tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a snippet rather than performing a direct import, and that the snippet includes a NOTE about the --render-mode path caveat. This adds behavioral context beyond the annotations, which already declare the operation as read-only and idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and including only essential extra context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple code-generation tool with an output schema, the description covers the core purpose, use context, and a notable caveat. The main gap is parameter detail, but the tool's simplicity and present output schema make this mostly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero schema description coverage, the description should compensate by explaining parameters, but it does not mention stl_path or convexity. The parameter names are suggestive but left undefined, especially convexity where a default value is provided but no meaning given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Return an OpenSCAD snippet that imports the given STL,' using a specific verb and resource. It distinguishes itself from sibling Blender tools by explicitly mentioning OpenSCAD, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for Blender→SCAD handoff or further parametric modification' provides a clear use context. However, it does not explicitly mention alternatives or exclusion scenarios, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds behavioral context about the rendering modes (preview vs. CGAL) and the nature of the output (labeled grid image), which goes beyond the structured annotations. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose. Every sentence adds value: the first defines the tool, the second gives practical usage details. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a rendering tool with no output schema, the description should clarify the return format (e.g., how the grid image is delivered) and explain all parameters. It does not mention how the image is returned, and 'size' and custom 'views' are only loosely implied. The description is adequate for a simple tool but leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions the 'preview' parameter and lists the default views for the 'views' parameter, but does not explain 'code' or 'size'. This partial coverage is helpful but leaves some parameters under-described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Render multiple labeled views of an OpenSCAD model into a grid image.' It identifies the specific verb (render), resource (OpenSCAD model), and output (grid image), which distinguishes it from siblings like blender_render_tiled (Blender-specific) and scad_cross_section (cross-sectional views).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by specifying default views and instructing to set preview=False for CGAL-rendered final views, which is slower. It does not explicitly list alternatives or exclusions, but the instructions imply when to use different rendering modes. This is clear context without direct alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior, and the description adds behavioral context beyond this: it rotates the object, checks each step, returns worst-case clearance and the angle, and explains that passes=False means the joint WILL fuse. This enriches the agent's understanding of the simulation without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured. It starts with the core action, states when it's mandatory, provides a concrete illustrative example, and ends with the output significance. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which likely documents the return fields) and rich annotations, the description covers the essential usage context, including the importance of the sweep and the interpretation of passes=False. It does not mention the axis parameter or the min_clearance_mm threshold explicitly, but the overall description is sufficient for an agent to select and invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description has to explain the parameters. It clarifies inner_object (the one rotated), outer_object (implicitly the obstacle), steps (each step of rotation), and implies min_clearance_mm via the pass/fail threshold. However, it does not explicitly define min_clearance_mm or the axis parameter, so the agent must infer their exact meaning from context or the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rotates inner_object through 360° and checks clearance at each step, specifying both the action and the objects involved. It distinguishes itself from the sibling blender_check_clearance by adding 'sweep' and emphasizing rotation around a full circle, making it unique for articulating mechanisms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says it is MANDATORY for any joint, hinge, or articulating mechanism, and provides a concrete example (a hinge may collide at 90°). This gives clear when-to-use guidance, but it does not explicitly mention when not to use it or name an alternative tool like blender_check_clearance for static checks, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the behavioral process: translating a moving part by a displacement and checking intersection, and returning CAPTIVE or FREE. This is useful context beyond the annotations, though it doesn't state whether the translation is temporary (implied by read-only).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences cover the operation, parameters, return value, and example use cases. Every sentence provides meaningful information with no redundancy or filler, and the key message is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema (CAPTIVE or FREE) and annotations cover safety, the description is fairly complete. It explains the method (translation and intersection), the direction format, and gives typical use cases. It lacks some details like whether the object position is restored, but the read-only annotation mitigates that. Overall, it's sufficient for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explicitly defines `direction` values ('+X'/'-X'/'+Y'/'-Y'/'+Z'/'-Z') and indicates `displacement` is in mm. However, it does not explain `moving_object` and `static_objects` beyond implying their roles; the schema shows they are object names/arrays but the description leaves these somewhat implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Verify a moving part is captive by translating it displacement mm in direction and checking intersection with static_objects. Returns CAPTIVE or FREE.' This uses a specific verb (verify) and resource (moving part retention), and the outcome is defined. It also distinguishes itself from sibling tools like blender_check_intersection by focusing on the retention concept.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases: 'Use for: car body on axles, ball in socket, hinge pin in barrel.' This gives clear context on when to apply the tool. However, it does not mention when not to use it or explicitly name alternatives, though sibling tool names imply related checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations state idempotentHint=true and destructiveHint=false, but the description adds valuable context: it warns about non-manifold edges, clarifies the bundling behavior when no object args are given, and explains the path resolution quirk relative to Blender's install directory. This goes beyond the bare annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs totaling four sentences. Each sentence contributes important information: purpose, warning, default vs. specific behavior, and path resolution. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (four parameters, path ambiguity), the description covers the key decision points: how to choose between all meshes vs. a single object vs. a bundle, and the cwd caveat. It does not detail return values, but an output schema exists which likely covers that. Slight gap: no mention of binary format or overwrite behavior, but these are minor given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does explain the meaning and interplay of object_name and object_names ('Use object_name for one part, object_names=[...] for a specific bundle') and the default all-mesh behavior. However, it does not elaborate on the 'path' parameter beyond relative path resolution, and the 'binary' boolean is left entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Export mesh(es) to a single STL for 3D printing.' It names the specific verb, resource (mesh), and output format, and distinguishes it from sibling tools like blender_import_stl (import vs export) and render tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains default behavior with no object arguments ('exports ALL mesh objects bundled into one STL') and how to select specific objects via object_name or object_names. It also notes that relative paths resolve against the MCP server's cwd, which is critical usage context. However, it does not explicitly contrast against alternatives or give 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds valuable behavioral context: it states the output is a 'multi-angle tiled image plus issue counts' and explains the color coding for overhang, thin wall, and OK. This goes beyond what annotations provide, giving the agent a clear expectation of the result without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-sentence main purpose followed by a color legend and output summary. Every sentence earns its place, with no fluff or repetition. It is front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters, no output schema, and zero parameter descriptions, the description provides sufficient context for correct invocation. It explains the output format (tiled image plus counts) and the meaning of the colors, which are essential for interpreting results. It could detail the exact structure of issue counts, but that is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by linking the color legend to the parameters: 'Red = overhang' relates to overhang_angle, and 'Yellow = thin wall' relates to min_wall_mm. object_name is self-evident. While it does not explicitly map parameters to their thresholds, the meaning is clearly implied, adding value beyond the bare parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Render the object with faces colored by printability issues.' It uses a specific verb (Render) with a specific resource (object) and a clear purpose (printability heatmap). The color legend distinguishes it from sibling render tools like blender_render_tiled and blender_render_turntable, which do generic rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for printability analysis through the color legend and issue counts, but it does not explicitly state when to use this tool vs alternatives. There is no mention of when not to use it or pointing to sibling tools like blender_render_tiled for generic rendering. The context is clear but exclusions and alternative comparisons are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral details such as the step-to-angle mapping (steps=8 → every 45°, steps=12 → every 30°) and elevation semantics (negative=below), which go beyond the schema and annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with every sentence providing useful information. It front-loads the purpose, then gives formula-like parameter details without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (5 params, 1 required) and the read-only/idempotent annotations, the description covers the core purpose, usage scenario, and key parameter behaviors. It does not describe the output format, but that is likely implied by the tool name and sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains steps and elevation but does not clarify zoom or isolate. These are common terms with defaults, but the description only partially bridges the gap for 5 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders an N-angle turntable around a single object, with specific use cases for cylindrical geometry. The verb 'render turntable' and the scope 'around one object' distinguish it from sibling tools like cross-section or tiled rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use for cylindrical geometry (barrels, pins) where 4 fixed angles miss details.' This implies when the tool is appropriate, though it doesn't name alternative tools explicitly. The exclusion of non-cylindrical cases is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (idempotent, non-destructive), the description adds useful context about output_path resolution relative to the MCP server cwd and the tempdir fallback. This helps the agent understand file handling behavior without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences front-loaded with the core purpose, followed by a precise note on output_path. No filler or redundant repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, annotations, and sibling tools, the description covers the essential workflow sequence and the most non-obvious parameter behavior. It does not explain error scenarios or prerequisites like OpenSCAD installation, but the overall context is adequate for a scoped compile tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains output_path, but code and timeout are left unexplicated. Code is somewhat self-evident from context, and timeout is standard, yet the partial compensation only earns a mid-range score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compiles OpenSCAD code to STL via CGAL, which is a specific verb+resource+engine. It distinguishes itself from siblings like scad_validate_printability and scad_render_views by focusing on the compilation step.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to always follow with scad_validate_printability, giving clear workflow context. It does not explicitly mention when-not-to-use or alternatives, but the 'always follow' guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false), the description adds meaningful behavioral context: it compiles the code to STL first and warns about CGAL render time on heavy models. It also clarifies percent mapping onto actual model bounds. These details are not evident from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the core functionality, the second gives the primary use case, and the final part adds essential parameter context. Every sentence earns its place; there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, no output schema), the description covers the key aspects: purpose, when to use, performance expectations, and two critical parameter meanings. It lacks details on return format or other parameter defaults, but those are partially covered by the schema. Overall, it provides enough context for an agent to select and invoke the tool confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains two parameters (percent and slab_thickness) in practical terms: 'percent: 0-100 along the chosen axis (mapped onto the model's actual bounds).' and 'slab_thickness in model units.' However, it does not explain the remaining four parameters (axis, code, size, view), leaving gaps for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Slice the model with a thin slab and render the cut.' It clearly identifies the resource (model/cut) and the tool's unique purpose: 'The only reliable way to verify internal geometry (clearances, hollows, joints).' This distinguishes it from sibling tools like scad_render_views or blender_cross_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: to verify internal geometry (clearances, hollows, joints), positioning it as the 'only reliable way.' It implies a context where other tools (e.g., simple rendering) would not suffice. It does not explicitly list alternatives or when not to use, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive behavior. The description adds transparency by stating the specific checks (watertight, manifold, volume, overhang) and the output format ('PASS/WARN/FAIL verdict + structured report'). This goes beyond what annotations provide, though it could include more detail on report structure. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences. The first sentence lists the specific checks, and the second gives usage timing and output format. Every word earns its place, no redundancy, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values do not need to be detailed. The description mentions the PASS/WARN/FAIL verdict and structured report, which is sufficient. It also gives the run-after instruction. Annotations cover side effects. The description is complete for the tool's complexity, though the parameter thresholds are left to the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'volume' and 'overhang' checks, which map to the parameters min_volume_mm3 and max_overhang_deg, but does not explain their exact meaning, units, or default behavior. stl_path is obvious from context. The description provides minimal semantic added value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Watertight / manifold / volume / overhang checks on an STL via trimesh.' This clearly identifies what the tool does, the resource it operates on (an STL file), and the specific checks performed. It also distinguishes itself from sibling tools like scad_compile or scad_render_views, which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Run after every scad_compile.' This tells the agent when to use this tool in a workflow. It does not explicitly mention alternatives or when not to use it, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context (e.g., return format or side effects), but it does not contradict the annotations. Given the annotations, the description's lack of extra behavioral disclosure is acceptable but not enhancing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. The first sentence states the purpose, the second sentence gives the usage context, and the remaining lines concisely explain key parameters in a bullet-like format. Every sentence contributes necessary information with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only screenshot tool with no output schema, the description adequately covers purpose, usage, and parameter semantics. It does not explicitly describe the output image, but that is implied by the tool name and purpose. The description is complete enough for an agent to select and invoke the tool correctly, though it could optionally mention output format or dimensions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the critical parameters: elevation and azimuth with degree ranges, and focus_object/isolate for framing and isolation. More common parameters like width/height/zoom remain self-explanatory from names/types, so the description adds significant value without covering every parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Single screenshot from a custom camera angle.' It distinguishes itself from the sibling tool render_tiled by explicitly saying 'Use when render_tiled's 4 fixed views miss what you need,' which is a specific verb+resource+differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Use when render_tiled's 4 fixed views miss what you need' names the alternative and when to choose this tool. It also gives parameter-specific guidance for elevation, azimuth, and focus_object/isolate, making the invocation conditions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true, so the agent knows it's a mutation tool. The description adds meaningful behavior beyond annotations by stating that the tool executes bpy code between captures and returns a side-by-side comparison. This clarifies the mechanics and side effects of running arbitrary code, which is valuable context. It doesn't contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the purpose, explain usage, and state the return value. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (executing user code and capturing before/after screenshots) and the lack of an output schema, the description is reasonably complete: it states what it does, what to provide, and what it returns. It could mention the current scene context or potential side effects of code failure, but the essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter 'code' with no description (coverage 0%). The description compensates by explaining the purpose: 'Provide the bpy code to execute between captures.' This gives meaning to the parameter, though it could be more specific about the expected format or scope (e.g., that it's Python/Blender code). Still, it adds sufficient clarity for a single simple parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Capture before/after screenshots around a modeling operation.' This uses a specific verb ('capture') and resource ('before/after screenshots'), and distinguishes it from sibling tools like blender_get_screenshot or blender_render_tiled by emphasizing the before/after comparison aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: 'around a modeling operation' and instructs to 'Provide the bpy code to execute between captures.' This implies when to use it, though it doesn't explicitly name alternatives or exclusions. It's clear that this tool is for capturing a side-by-side comparison before and after a user's custom code execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by listing default views ('iso/front/right/top'), available angles, and the effect of focus_object/isolate. It does not describe output format or potential side effects, but with strong annotations this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: a strong lead sentence, a line on available angles, and a usage tip with a follow-up suggestion. Every sentence earns its place, with no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four optional parameters, no output schema, and a rich sibling set, the description covers the primary use case, angle choices, zoom-related parameters, and a follow-up tool. It misses the 'zoom' parameter and does not describe the output format, but the essential context for selection and invocation is present. The lack is minor because zoom is self-explanatory and the described workflow is actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the 'angles' parameter via 'Default views' and 'Available: iso, front, back, right, left, top,' and clarifies focus_object and isolate ('zoom into a specific part'). However, the 'zoom' parameter is not mentioned at all, leaving one of four parameters without any description-level semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with '4-angle labeled grid render — your primary feedback tool after every modeling step,' clearly stating the tool produces a multi-angle labeled grid render and establishing its role. It differentiates from sibling tools like blender_render_turntable by emphasizing '4-angle labeled grid' and later suggesting cross_section_gallery as a follow-up, which distinguishes this tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes when to use: 'your primary feedback tool after every modeling step.' It provides concrete usage hints for parameters ('Use focus_object (+isolate) to zoom into a specific part') and recommends an alternative for internal geometry verification ('Follow up with cross_section_gallery if internal geometry needs verification'), giving clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses important behavioral details: per-face issue lists are capped at 10 exemplars unless verbose=True, and verbose output can be very large on dense meshes. This adds value that the annotations do not convey, with no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four sentences, front-loaded with the main purpose, followed by replacement info, usage example, and a note on output truncation. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, output schema present, rich annotations), the description covers the main usage patterns, replacement behavior, and output size caveat. It falls slightly short by not explicitly defining the numeric thresholds, but the output schema and intuitive parameter names partially fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must explain parameters. It does explain the 'checks' enum, 'verbose' behavior, and 'clearance_partners' purpose. However, it leaves the numeric parameters (min_wall_mm, overhang_angle, min_clearance_mm) without explicit ties to the checks or units, though their names are somewhat self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb+resource: 'Run specified printability checks on a mesh.' It then enumerates the exact valid check values and explicitly states it replaces individual mesh_health, overhang, and thin_wall checks, distinguishing it from sibling validation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit usage context: 'Use checks=["ALL"] to run the full printability suite before STL export' and explains how to check clearance against named neighbors via clearance_partners. It also notes it replaces individual checks, but does not draw exclusions against sibling tools like scad_validate_printability or blender_check_intersection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, but the description adds substantial context: it mentions built-in checks, warns about silent annihilation when use_self is not set, explains the meaning of warnings, and describes return values. This goes well beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, followed by parameter details, and ending with return behavior. Each sentence provides useful information without redundancy, though the length is slightly full due to detailed parameter explanations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, conditional constraints, and an output schema, the description covers most critical aspects: operations, solver specifics, edge-case flags, and failure warnings. However, it leaves keep_cutter unexplained and does not clarify the nature of target/cutter identifiers, making it not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for parameter understanding. It explains operation, solver, use_self (with EXACT-only constraint), and use_hole_tolerant, but omits keep_cutter and does not explicitly define target/cutter as mesh names. Partial compensation, hence a mid score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it performs a boolean operation on two meshes with connectivity and manifold checks. It enumerates supported operations (DIFFERENCE, UNION, INTERSECT) and explicitly differentiates from raw modifiers in execute_code, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to 'Always prefer this over raw modifiers in execute_code', providing a clear directive on when to use this tool over an alternative. This satisfies the usage guidance criterion with an explicit recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which informs safety. The description adds significant behavioral context beyond that: the default axes/percent combinations, the X-axis heuristic, the object_names multi-object cut behavior, and the hard constraint that exactly one of object_name/object_names must be provided or a ValueError is raised. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is organized into three compact paragraphs, each with a clear role: (1) what the tool does and why, (2) default parameters and heuristic guidance, (3) the object_names variant and input validation constraint. Every sentence carries useful information without repetition, though the formatting could be slightly tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only rendering tool with strong annotations and no output schema, the description provides the essential context: purpose, use cases, default behavior, parameter semantics, and an error condition. It doesn't explicitly describe the return format (e.g., an image grid), but the name 'gallery' and the rendering context strongly imply it. Overall, it is complete enough for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for all 4 parameters, so the description must compensate. It meaningfully explains the difference between object_name and object_names and the exclusivity constraint, and it provides defaults for axes and percents. However, it does not enumerate valid axis string values (e.g., 'x', 'y', 'z') or clarify the percent range, leaving custom-value construction somewhat ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool produces a 'Grid of cross-sections at multiple positions along one or more axes' and explicitly claims it is 'the only way to verify complex internal geometry' (knuckle interleave, pin holes, socket bores). This distinguishes it from sibling tools like blender_cross_section and scad_cross_section by emphasizing its gallery/multi-cross-section nature and its specific verification role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete use cases: verifying complex internal geometry and chain joints/mating-part captivity. It also provides orientation guidance ('X-axis slices are usually most informative for hinges') and explains when to use the object_names variant. However, it does not explicitly state when NOT to use this tool in favor of the simpler blender_cross_section or other alternatives, so it stops short of a full when/when-not breakdown.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds that the tool produces a summary rather than exhaustive data, and specifies the exact fields returned. This adds useful context beyond the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the action and resource, and it enumerates the returned data types without waste. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, no-parameter read tool with strong annotations and an output schema. The description fully conveys the tool's purpose and return content, making it complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema is already fully covered. With no parameters to explain, the baseline is 4. The description doesn't need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' on the resource 'summary of all objects in the Blender scene' and explicitly lists what's included (names, types, dimensions, vertex counts). This clearly distinguishes it from the sibling blender_get_object_info, which presumably targets a single object.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scope is explicit: it's for a scene-wide summary. This gives clear context for when to use it. It doesn't explicitly name alternatives or when-not conditions, but the 'all objects' phrasing effectively differentiates it from per-object tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and non-destructive behavior, but the description adds rich behavioral context beyond that: it explains the meaning of each contact_type, how contact_area_mm2 is calculated (half the intersection mesh's surface area), and how to interpret mean_penetration_um with specific thresholds. This gives the agent deep insight into what the tool does and what the results mean, without contradicting annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, then usage guidance, then an explicit distinction from a sibling tool, and finally a detailed but organized breakdown of return values. Every sentence earns its place, providing high information density without unnecessary repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all essential context: when to use, how to interpret results, and how it differs from related tools. Given the tool's moderate complexity and the presence of an output schema that presumably lists return fields, the description provides sufficient behavioral and interpretative detail. The only minor gap is parameter semantics, already scored low, but overall the description is complete for an effective agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two string parameters with no descriptions, and schema coverage is 0%. The description only refers to 'two meshes' generically and does not explain that object_a and object_b should be object names or how they should be specified. It fails to compensate for the lack of schema-level parameter documentation, leaving the agent to guess about valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool checks if two meshes physically overlap, using a specific verb and resource. It further distinguishes itself from the sibling tool blender_check_clearance by explicitly contrasting volumetric overlap with clearance measurement. The return types (NONE, SURFACE_CONTACT, VOLUMETRIC_OVERLAP) clarify the tool's purpose even more.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Use after assembly' and states that separate parts should NEVER volumetrically overlap, indicating when this check is appropriate. It also explicitly names the alternative for non-touching objects (clearance), making the decision between tools clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior. The description adds value by listing the exact data returned (dimensions, mesh stats, etc.) and clarifying the deprecated alias behavior, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in one sentence, followed by a concise parameter clarification. Every sentence adds value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only info tool with strong annotations and an output schema, the description adequately covers purpose, parameter semantics, and the scope of information returned. No critical gaps remain, such as error conditions or return format, because the output schema and annotations cover those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining object_name as the target object and name as a deprecated alias, including the rationale for compatibility. This provides meaning the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('specific object'), and enumerates the information covered (dimensions, mesh stats, modifiers, materials, manifold check). This clearly distinguishes it from scene-level tools like blender_get_scene_info and other object-specific tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'specific object' implies a contrast with scene-level or batch operations, providing clear context. It also notes the parameter naming convention ('every other single-object tool uses object_name'), which is a usage guideline. However, it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=false, destructiveHint=false, and idempotentHint=true. The description adds behavioral details beyond annotations: the fallback to current file/temp location and relative path resolution against the working directory. It does not contradict the annotations and provides useful side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long and front-loads the core purpose: 'Save the current scene as a .blend file.' The subsequent sentence provides two necessary clarifications about path behavior. Every word earns its place; no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple save tool with one optional parameter, the description sufficiently covers the action, fallback behavior, and path resolution. It omits nothing critical that would prevent correct invocation, and the output schema likely documents the return value, so the description need not explain it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'path' with a default of null and no description (0% schema description coverage). The description compensates fully by explaining what happens when the path is omitted and how relative paths are resolved, giving complete meaning to the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action with a specific verb and resource: 'Save the current scene as a .blend file.' This distinguishes it from sibling tools like blender_export_stl (which exports a different format) and various validation/rendering tools. The output format is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on path behavior: explains what happens when path is omitted (saves to current file or temp location) and how relative paths are resolved (against MCP server's working directory). It does not explicitly name alternatives, but there is no comparable save tool among siblings, so exclusions are unnecessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (destructive, idempotent), the description details refusal behavior, error listing, confirmation requirement, and the side-effect of setting units to mm.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded action, and each sentence adds essential context about safety and force behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter destructive tool, the description covers behavior, override, and side-effect; output schema exists for return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Though schema coverage is 0%, the description fully explains the only parameter `force`: overriding safety for fresh-build scenarios.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Remove all objects from the scene' with a specific verb and resource, and distinguishes itself from sibling tools by its destructive all-objects operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains when to use force=True (fresh-build scenarios) and describes default behavior protecting work, but doesn't explicitly name alternative tools like restore_checkpoint for scenarios where recovery is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say destructiveHint=true and idempotentHint=true, but the description adds critical context: 'Replaces ALL current scene objects' and details about checkpoint lifecycle (saved before every blender_boolean and blender_execute_code call). This goes beyond annotations to explain the exact destructive scope and stateful behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: a clear one-line purpose, the mechanism, the destructive scope, and the critical temporal warning. It is front-loaded with the main action and efficiently structured without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive rollback tool with zero parameters, the description fully covers the key context: what it does, when to use it, what it replaces, and the overwrite risk. The output schema exists but doesn't need return-value explanation. This is complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The baseline for 0 params is 4, and the description does not need to add parameter details. It also doesn't mention params, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb and resource: 'Restore the scene from the auto-saved checkpoint' and characterizes it as 'the undo button for a destroyed mesh.' It explicitly ties to blender_boolean and blender_execute_code, distinguishing it from sibling tools like blender_clear_scene and blender_execute_code.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance: 'Use immediately after a DEGENERATE RESULT warning or a botched edit.' It also gives a crucial when-not-to-use warning: 'a subsequent mutating call overwrites the checkpoint with the broken state,' implying the tool must be the next call after a mutation. This is clear context and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly and idempotent, so the description adds meaningful extra context: it reveals that the addon is a static copy with manual updates, and that old addon versions (pre-0.2.3) will show as unknown. This highlights limitations and operational behavior not captured by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose in the first sentence. The following two sentences efficiently add update mechanism and a known limitation without any redundant wording. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple no-parameter diagnostic tool with an output schema (not shown), the description fully covers the relevant context: what it reports, why it matters, and a known edge case. There is no missing information that would hinder an agent in selecting or using the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty with 100% coverage, so the description doesn't need to explain inputs. However, it adds valuable meaning about what the version info represents (server vs. addon) and the implications of stale versions, which enriches the schema-less parameter space. Baseline 4 for zero-parameter tools is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Report' and clearly identifies the resource as 'the MCP server version vs. the installed Blender addon version'. This unambiguous phrasing distinguishes it from sibling tools, all of which involve scene manipulation, rendering, or validation rather than version diagnostics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'use this to diagnose stale-addon behavior'. It also explains the underlying update mechanism difference between the server (auto-updates via PyPI) and the addon (manual install.py + restart), giving clear context on when this tool would be relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, but the description adds critical behavioral context: the 20-line limit, the need to set `__result__` for returns, the internal-faces problem with join, and the mandatory validation after geometry changes. This goes well beyond the annotations and prepares the agent for safe execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise yet information-dense. It front-loads the core action ('Run Python in Blender'), then covers the return convention, size limit, alternative tool, dangerous operation warning, and post-condition validation in just a few sentences. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of arbitrary code execution, the description is highly complete. It specifies what to do, what to avoid, what to call afterward, and how to return values, all while providing clear guardrails. The presence of an output schema further reduces the need to describe return formats in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description fully explains the single `code` parameter: it is Python code executed in Blender with available modules, has a size limit, and uses `__result__` for return. This is complete parameter semantics that the schema alone would not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool runs Python in Blender with specific available libraries (bpy, bmesh, mathutils, math) and specifies the return convention via `__result__`. This distinguishes it from sibling tools that have more specialized purposes (e.g., boolean ops, rendering, 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use `blender_boolean` for boolean ops instead, never use `bpy.ops.object.join()`, and call `blender_validate(checks=['HEALTH'])` after geometry changes. It names exact alternatives and warns against specific pitfalls, giving clear when-to-use and when-not-to-use context.
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:

[![mcp-printable MCP server](https://glama.ai/mcp/servers/AaronGoldsmith/mcp-printable/badges/card.svg)](https://glama.ai/mcp/servers/AaronGoldsmith/mcp-printable)

Score Badge

Copy to your README.md:

[![mcp-printable MCP server](https://glama.ai/mcp/servers/AaronGoldsmith/mcp-printable/badges/score.svg)](https://glama.ai/mcp/servers/AaronGoldsmith/mcp-printable)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/AaronGoldsmith/mcp-printable'

If you have feedback or need assistance with the MCP directory API, please join our Discord server