NameSTL

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds useful negative scope — no plan display, no payment flow, no account mutation — which reinforces that this is a pure read with no side effects on billing.

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 short sentences, purpose front-loaded, with the scope exclusions following immediately. Every clause carries information; nothing is padded.

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?

An output schema exists and the tool is parameterless, so the description does not need to explain return values. It covers purpose and boundaries adequately; the only minor gap is that it never explains what to do with a negative result (i.e., the fallback path when access is absent).

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 takes no parameters at all, so per the baseline there is nothing for the description to disambiguate. No parameter gaps exist to compensate for.

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?

States a specific verb ('Check') and resource ('export access' for STL and 3MF) with a clear scope, so an agent knows exactly what question the tool answers. It does not, however, differentiate itself from the sibling export_design — it never says this is the entitlement check that precedes an actual export.

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 closing sentence bounds the tool by negation ('Does not display plans, initiate payment or modify account access'), which implies a pre-flight entitlement check, but it never states when to call it versus export_design or that it should be used before attempting an export. Usage is inferable 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description is consistent with them while adding useful behavioral context: the operation is non-persistent (no account save) and produces no file artifact. It does not describe refresh/statefulness of the preview or any limits, so it's solid rather than exhaustive.

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 no filler; the core purpose and the design-type list come first, followed by the two constraints and the font prerequisite. Nothing is repeated from the schema.

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 one-parameter tool with a deep nested schema, 100% schema coverage and an output schema (so return values need not be explained), the description covers purpose, constraints, and the font dependency. The main gap is the workflow link to save_design/export_design (e.g. what to do with the result), which is implied rather than stated.

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 100%, so the nested settings object is fully documented and the baseline is 3. The description adds value beyond the schema by naming the informal design variants (keychain, pet tag, cake topper, sign, flip) that correspond to baseMode values, and by pointing at list_design_options as the authoritative source for the font URL.

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 gives a specific verb pair ('Configure and show an interactive 3D preview') plus an explicit resource list (name, keychain, pet tag, cake topper, sign, two-name flip design). It also differentiates itself from siblings by ruling out saving and exporting, so an agent can distinguish it from save_design and export_design without opening a schema.

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 states two important exclusions ('Does not save to an account or export a file') which implicitly route persistent/finalizing work to save_design and export_design, and names list_design_options as the source of valid font URLs. It stops short of explicitly saying 'use this tool when you want a preview before saving', so it's clear but not fully prescriptive about when/when-not.

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?

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds real behavioral context: the output is a 'temporary ... download page', it 'Never starts checkout', and it does not save or overwrite a project. These are meaningful non-schema traits, though return/lifetime details are left to the output schema.

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?

Four short clauses, front-loaded with the core action, then the entitlement fallback and two negative scoping constraints. Every sentence earns its place with no redundancy.

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 2-parameter tool with a full output schema and complete schema descriptions, the description supplies the missing behavioral context (temporary page, entitlement gate, no checkout, no persistence) without needing to explain return values.

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 coverage is 100%, so both parameters (format, settings) are already fully documented, including enum, defaults, and nested properties. The description only restates the format options (STL or 3MF) and that the design must be 'complete', adding no syntax or constraint beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource: 'Prepare a temporary STL or 3MF download page for the provided complete design.' It also distinguishes itself from siblings by negating persistence ('Does not save or overwrite a project') and checkout behavior, so an agent can separate it from save_design and any purchase tool.

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?

Gives clear context and a fallback: it uses the account's 'existing export entitlement' and says to 'return a neutral explanation and stop' if unavailable. It does not explicitly name check_export_access as the prerequisite sibling, so the when-to-use routing is implied rather than spelled out.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds genuinely new behavioral context not in the annotations: 'This does not access an account,' which tells the agent no authentication or account scoping is needed. It says nothing about caching, ordering, or return shape, though the output schema covers results.

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 short sentences, zero filler. The content of the list is front-loaded and the account-access caveat is appended where it adds the most value without padding.

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 parameters, an existing output schema, and full annotation coverage, the description only needs to convey what is returned and any caller prerequisites, both of which it does. It is complete in practice, though it could note that these are static platform options independent of any saved design.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline is 4. The description correctly implies a no-argument enumeration by listing the categories returned rather than any filtering inputs.

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?

States a specific verb ('List') and enumerates the exact resource contents (fonts, bases, colors, thickness ranges), which is far more informative than a bare 'list options'. The word 'supported' implicitly separates it from list_saved_designs, but the description never names that sibling or explicitly contrasts static catalog data with user-owned designs.

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?

'before configuring a 3D name' tells the agent exactly where this fits in the workflow, namely as a prerequisite lookup ahead of create_design. It does not name alternatives or state exclusions, so it stops short of the explicit when-not/alternative routing a 5 would require.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the 'most recently updated' sort order and account scoping, but omits further behavioral details like pagination or rate limits, matching the calibration's 3 for minimal added context.

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 concise sentences, with the core purpose front-loaded and the alternative routed immediately after. No wasted words.

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?

Given the simple list operation, comprehensive annotations, complete parameter schema, and an output schema that covers return values, the description supplies everything an agent needs: what it lists, the ordering, and where to go for reading. No critical gaps remain.

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 100%, so the schema fully documents limit and offset, including defaults and ranges. The description adds no parameter-level information, so baseline 3 is appropriate.

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?

States a specific verb ('List') and resource ('saved designs') with scope ('connected account's most recently updated'), and names open_design as the read/preview alternative. However, it does not differentiate from the sibling list_design_options, so it falls short of a full 5.

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?

Provides clear usage context: use this tool to list recently updated saved designs, and use open_design to read/preview one. It lacks explicit when-not guidance or comparison to list_design_options.

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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The sentence 'Does not change the design' merely restates those annotations rather than adding new context (no auth requirements, no side effects on the client session, no rate limits).

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

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

Two short sentences, front-loaded with the action and resource, with no filler. The second sentence is mildly redundant given the annotations, but it is cheap and unambiguous.

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 an output schema present, return values need not be described, and a single-parameter read tool with full annotation coverage is nearly complete. The only real gap is the absence of when-to-use routing against the many sibling design tools.

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?

Only one parameter with 100% schema description coverage, so the schema already fully documents projectId including its UUID format and pattern. The description's 'saved design belonging to the connected account' adds nothing beyond the schema text, making baseline 3 the correct ceiling.

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?

States a specific verb pair (read and preview) and resource (saved design), and names the sibling-tool distinction implicitly by scoping to a single design identified by projectId. It stops short of explicitly contrasting with list_saved_designs/save_design, but an agent can still tell what this does.

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 when-to-use guidance and no alternatives named. The phrase 'belonging to the connected account' hints at a scope prerequisite, but nothing tells the agent when to pick open_design over list_saved_designs or list_design_options.

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?

Annotations declare destructiveHint=true and idempotentHint=false; the description usefully adds that omitting projectId always creates a new project (explaining the non-idempotent behavior) and that no export access is required. It stops short of warning what may be overwritten/destroyed when an existing projectId is supplied, which is the key risk implied by destructiveHint.

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, zero filler, with the primary action stated first and the conditional parameter rule immediately after. Every sentence carries distinct information.

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?

An output schema exists, so return values need not be described. The description covers the account-scoped save, the update path, and the permission requirement, though it omits what an update does to an existing saved design, which matters given the destructive annotation.

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 100%, so the schema already documents both parameters and the whole nested settings tree. The description reinforces the projectId omit-vs-pass rule but adds no formatting or behavioral detail beyond what the schema description already says, so baseline 3 applies.

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 states a specific verb and resource ('Save the provided complete design in the connected NameSTL account') and clarifies the create-vs-update branch driven by projectId. It does not distinguish itself from the sibling create_design, which an agent could reasonably confuse with the 'creates a new project' path described here.

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 an explicit conditional for the optional parameter: pass projectId only when the user asked to update that saved design, otherwise a new project is created. It also notes that saving does not require export access, implicitly steering away from check_export_access, but it never names the alternative tools (create_design, export_design) that an agent might otherwise pick.

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