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

No annotations are provided, so the description carries the full burden. It does disclose expected outputs (STL and four PNG views) and a limitation of description-based input. However, it omits side effects, permissions, response format, or whether this is a mutating operation beyond the obvious creation act.

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

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

Two sentences with no filler and the key usage tip is front-loaded. The only flaw is the slightly ambiguous first sentence, which could be parsed as creating 'a primitive' and 'STL and PNG views' as separate objects.

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

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

There is no output schema, so the description must explain outputs; it mentions STL and four PNG views, which helps. It also routes the agent to get_capabilities for defaults. Still, it does not explain what primitives are available, what 'parameters' should contain, or what a successful call returns.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning by saying that model_type and parameters are preferred, and that description only works for named primitive dimensions. It does not explain the structure of the parameters object or how to reference primitive dimensions, leaving some gap.

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

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

The description names a specific verb ('Create') and resource ('primitive, STL and four PNG views'), which says what the tool produces. It also distinguishes itself from the sibling create_model_from_scad by focusing on primitives. Slightly awkward phrasing makes the exact object of creation ambiguous, but the intent is recoverable.

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

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

The description gives clear parameter-level guidance: 'Prefer model_type and parameters; descriptions only recognize named primitive dimensions.' It also points the agent to a sibling tool, get_capabilities, for defaults. It does not explicitly contrast with alternatives, but the context for when this tool is appropriate is implied.

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

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

The description discloses that the tool compiles source code and produces STL and PNG outputs, and clarifies it does not perform image reconstruction or AI generation. However, it does not mention other behaviors such as validation, error handling, or whether the compilation is executed in a sandbox. Without annotations, this is a reasonable but incomplete disclosure.

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

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

The description is brief and directly to the point, using one sentence to convey the primary function and a second to clarify boundaries. It avoids fluff and extra details, making it easy for an agent to parse quickly.

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

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

The description mentions the output types (STL and PNG previews) but does not provide an output schema. It also lacks parameter details, as noted. However, given the simple input schema and the explicit mention of expected outputs, it provides a baseline understanding of how the tool behaves.

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

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

The schema has zero description coverage for the two parameters (scad_code and description). The description implies that scad_code is the OpenSCAD source, but it does not explain the purpose of the optional description parameter or any constraints on the input. This leaves significant ambiguity about the parameters' roles and expected values.

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

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

The description clearly states the tool's purpose: compiling OpenSCAD source into STL and PNG previews. It also distinguishes itself from AI generation tools by explicitly stating 'No image reconstruction or implicit AI generation', which helps differentiate it from sibling tools.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives like create_3d_model or get_model_preview. The mention of 'trusted, self-contained' and 'No AI generation' offers only implicit hints about its intended use case, but no direct comparison or selection criteria.

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

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

With no annotations provided, the description carries full responsibility for disclosing side effects. It does not mention whether exporting creates a file, returns a URL, or has any other consequences, leaving the agent unaware of potential impacts.

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

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

The description is a single, concise sentence that effectively communicates the core functionality without unnecessary verbosity. It is well-structured and easy to parse.

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

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

The description lacks essential context about the output or return value. It does not state whether the export returns a file, a URL, or binary data, and there is no output schema. This leaves the agent uncertain about the result of invoking the tool.

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

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

The description partially clarifies the 'format' parameter by listing valid values, but it provides no explanation of the 'model_id' parameter. Since the schema offers no parameter descriptions, the tool description does not sufficiently compensate for the missing semantics.

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

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

The description clearly states the tool's purpose: exporting a model in specific formats (scad, stl/3mf, csg). It is distinct from sibling tools like get_model_preview or get_model by focusing on export actions.

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

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

No explicit guidance is given on when to use this tool versus alternatives. It does not mention any conditions or contrast with siblings such as get_model_preview or create_3d_model.

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

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

With no annotations, the description carries the full burden. The verb 'Report' clearly signals a read-only, non-destructive operation, and the description adds the useful context that all dimensions are in mm. It does not explicitly state side effects are absent, but for a capability query the meaning is clear enough.

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

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

The description is a single sentence of about 12 words, front-loaded with the action verb 'Report' followed by the specific output contents. Every word carries information, with no filler or repetition.

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

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

For a zero-parameter introspection tool with no output schema, the description adequately states what will be returned: version, supported primitives, and defaults, with the unit convention. It is not overly detailed about output structure, but that is acceptable given the simplicity of the tool.

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

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

The tool has zero parameters and an empty input schema, so the baseline is 4. The description does not need to explain any parameters, and it adds no param-related details because none exist.

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

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

The description uses a specific verb ('Report') and states the exact resource: OpenSCAD version and supported primitives with defaults. This clearly distinguishes it from sibling tools, which all focus on model creation, modification, or export rather than environment capabilities.

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

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

There is no explicit when-to-use or alternative guidance, but the nature of a capabilities report implies that it should be consulted before creating or modifying models to know supported primitives. The intended context is inferable from the tool's purpose, but the description does not state it directly.

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

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

With no annotations, the description carries the burden of indicating behavior. The word 'Read' implies a non-mutating operation, but the description does not explicitly state that it has no side effects or discuss authentication, errors, or permissions. It discloses the primary behavior but lacks fuller transparency.

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

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

The description is a single, focused sentence with no redundant words. It front-loads the action and resource, then specifies the exact data returned, making it highly efficient and easy to parse.

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

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

For a simple read operation with one required parameter and no output schema, the description provides enough context about what the tool returns. It could be slightly more complete with explicit statements about what is not returned or how errors are handled, but it is sufficiently complete for an agent to understand the core purpose.

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

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

The schema provides only the parameter name 'model_id' with no description, and the tool description does not explicitly define it. Although the context of reading a 'persisted model' implies that model_id identifies which model to read, the description adds minimal meaning beyond the parameter name itself.

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

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

The description clearly states a specific action ('Read') and resource ('persisted model') along with the exact data returned ('parameters and local artifact paths'). It also distinguishes this from sibling tools like get_model_preview or get_model_source by focusing on model parameters and artifact paths.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as get_model_preview, get_model_source, or export_model. It relies entirely on the verb and resource naming to imply its purpose, but does not state conditions or exclusions.

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

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

Since no annotations are provided, the description carries the full burden of transparency. It clearly states that the tool returns a PNG image and lists the supported views, which implies a read-only operation with no side effects. It does not explicitly state that it makes no modifications, but the 'get' nature and the return of an image make this reasonably clear.

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

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

The description is highly concise, consisting of just two short sentences. It gets straight to the point without unnecessary elaboration. The key information—the return type and the available view options—is presented clearly and efficiently.

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

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

With no output schema, the description must explain the return type, which it does by stating 'an actual PNG image'. It also covers the main input parameter (view) with its possible values. It does not address error cases or edge situations, but for a simple preview retrieval, the description is sufficiently complete for an agent to understand what it does.

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

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

The schema provides no descriptions for parameters, so the description must compensate. It partially does: it enumerates valid values for the 'view' parameter ('perspective, front, top, right'), which is helpful. However, it does not explain that 'model_id' is required, what it represents, or that 'view' has a default value. This leaves about half of the parameter semantics undocumented.

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

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

The description clearly states the tool's purpose: returning an actual PNG image to the client. It also lists the available views, making it obvious that this is a preview function. This distinguishes it from sibling tools like get_model or get_model_source, which likely return data rather than image binaries.

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

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

The description implies usage for retrieving previews but does not explicitly say when to use this tool versus alternatives like get_model or get_model_source. It does not mention any conditions or scenarios where this tool is preferred or not. The guidance is implicit rather than explicit, leaving some ambiguity.

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

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

With no annotations, the description carries the full burden. It discloses that the tool reads source and revision and mentions MCP/Docker context, but it omits return format, error behavior, or side effects. The behavior is partially transparent but incomplete.

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

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

The description is brief and mostly to the point, with no fluff. The second sentence is slightly out of place for a read tool but still within the workflow context, keeping the overall structure reasonably efficient.

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

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

The description provides some workflow context (read source, edit, pass revision to modify_3d_model) but is incomplete. It does not explain what the tool returns, how model_id is used, or any caveats, leaving important context gaps for an agent.

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

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

The only parameter, model_id, has no schema description and is not mentioned in the descriptive text. Since schema coverage is 0% and the description does not compensate, the parameter semantics are essentially undocumented.

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

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

The description clearly states the tool reads a saved UTF-8 SCAD source and its revision, which distinguishes it from siblings like get_model_preview. However, the second sentence shifts to editing and passing revision to modify_3d_model, which somewhat muddies the primary purpose.

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

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

It implies a workflow by instructing to edit scad_code and pass the revision to modify_3d_model, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The guidance is suggestive rather than explicit.

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

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

With no annotations, the description carries the behavioral transparency burden. It discloses two non-obvious behaviors: stale edits are rejected via expected_revision, and failed edits leave the previous revision intact ('Failed edits leave the previous revision intact'). It does not mention permissions or success response shape, but the failure semantics are substantive.

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

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

Three short sentences with the primary action first, then the prerequisite, then the failure guarantee. Every sentence contributes a distinct operational fact, and there is no filler.

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

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

The tool has five parameters, no annotations, and no output schema, so the description must carry significant weight. It covers the revision/concurrency contract well but omits how parameters and modifications should be used, when scad_code is needed versus optional, and what the success response looks like. Correct invocation remains partially underdetermined.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to scad_code (source replacement) and expected_revision (concurrency guard), but leaves model_id, parameters, and modifications semantically unexplained. An agent cannot determine how to express 'primitive dimensions' or when to use parameters versus modifications.

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

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

The description uses an action verb and resource ('Edit primitive dimensions or replace source') and names two concrete use cases: changing dimensions or replacing source via scad_code. It clearly conveys that this tool modifies an existing model, which differentiates it from create/export/get siblings, though it does not explicitly name alternative tools.

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

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

It gives concrete usage guidance: fetch expected_revision from get_model/get_model_source and pass it to reject stale edits. This tells the agent where to get a required input and why. However, it does not explicitly state when to prefer this tool over create_model_from_scad or other alternatives.

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