3DLogo.io

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 needs no repetition. The description adds genuinely new behavioral context: no account is required, and each returned look bundles a rendered image, best-for use, underlying presets, and an editor link. 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.

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

Three sentences, each carrying distinct information: when to use, what results contain, and when not to use. The trigger is front-loaded first, and there is zero filler or repetition of schema/annotation content.

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 read tool with an output schema and safety annotations already covering the risk profile, the description covers all agent-relevant decisions: when to call it, what it returns, auth requirements, and which sibling to use instead. Nothing material is missing.

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 100% schema coverage, so the baseline is 4 per the rubric; there is nothing for the description to document. The 'Works without an account' note implicitly signals no auth parameters are needed, which is a small bonus beyond baseline.

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 ('browse') plus a concrete resource ('example looks') and enumerates the full content scope (chrome, gold, glass, holographic, brushed metal, gradient, 3D text, animated). The closing clause ('Do not use to get material ids... list_materials has the full catalogue') actively differentiates it from the sibling that would otherwise be confusable.

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 an explicit trigger condition ('Use when the user wants to see what is possible or pick a style before designing') and an explicit exclusion with a named alternative (list_materials for material ids). This is stronger routing guidance than most tool descriptions, matching the calibration HIGH example's structure.

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 cover readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context by stating the tool returns a link and requires no account. There is no contradiction with annotations, and the extra context is meaningful even beyond the structured hints.

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 return behavior is front-loaded, followed by a compact list of look options and a highly relevant account note. Every sentence earns its place.

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 link-building tool with an output schema, safe annotations, and self-descriptive enums, the description is adequate. It clearly explains the main purpose, output form, and account requirement. More explicit param semantics or alternative-tool routing would help, but the agent can still invoke the tool correctly from this definition.

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 56%, so the description is expected to compensate moderately. It adds meaning for 'text' as a struck mark and repeats the look values, but the schema already lists those enums. It does not describe blank, motion, or font, though their enum value names are fairly self-explanatory. Overall, the description adds some value but depends on the schema for most parameter meaning.

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 verb and resource: 'Returns a link that opens the 3D coin studio with a mark struck into a coin.' This distinguishes it from sibling tools like build_logo_editor_link or create_share_link, and the one-sentence core purpose is unambiguous.

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 makes the intended use clear: generate a link that opens a coin studio with a struck mark. It also adds a useful usage condition with 'Works without an account.' It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to select it for link-generation requests.

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 mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral context: the result is a link, it opens the editor pre-styled, it works without an account, and it supports three distinct starting states. This goes beyond the 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.

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

Three dense sentences cover the main function, all three input modes, a key dependency, and the auth behavior. The most important information is front-loaded, and there is no redundant or filler wording.

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 covers the essential context: what the tool returns, how to invoke each mode, where to get material ids, and the fact that no account is needed. Since an output schema exists, return-value details are not required here. A minor gap is that it does not explain how the optional styling parameters interact with the three modes, but the schema and enum descriptions cover most of that.

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 already documents 78% of parameters, and the description adds meaningful semantics: text means wordmark, mark refers to a stored logo from upload_logo_image, and upload=true opens the upload panel. It also connects material to list_materials. This adds real value beyond the schema, though some optional styling parameters are left to the schema alone.

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 opens with a specific verb and object: 'Returns a link that opens the 3D logo editor already styled.' It then distinguishes the three main input modes (text, mark, upload), which clearly separates this from sibling tools like create_text_logo_project and create_image_logo_project that create actual projects rather than return editor links.

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 usage context: use text for a wordmark, mark for a stored logo via upload_logo_image, or upload=true for the upload panel. It also directs the agent to list_materials for material ids and notes that no account is required. It does not explicitly name negative cases or alternatives, so it stops 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.

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

Beyond the sparse annotations, it discloses that a persistent project appears in the user's Projects, that image-to-3D tracing is deferred until first open, that the user must open and save before publishing, and that the operation does not spend credits. None of this contradicts the annotations' readOnly/destructive flags.

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 sentences, each carrying distinct information: the main action, the deferred-tracing caveat with required follow-up, and the cost implication. The most important information is front-loaded 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?

For a create-with-7-parameters tool, the description covers source prerequisite, persistence, deferred processing, required follow-up action, and credit behavior; an output schema exists so return values need not be described. It could be slightly stronger by naming the text-logo sibling as the alternative, but nothing critical is missing for invoking it with a valid mark.

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 86%, so the schema already documents most parameters and the description does not need to compensate. It adds useful context connecting 'mark' to the upload functions and mentions material/lighting, but it does not elaborate on depth, title, motion, or background beyond the schema.

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 opening sentence states the exact operation: 'Saves a new 3D logo project from a mark stored with upload_logo_image or request_logo_image_upload.' The verb 'saves', the object '3D logo project', and the source 'mark' make the tool's purpose unambiguous and distinguish it from text-logo and generation-saving siblings.

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 clearly names the prerequisite upstream tools ('upload_logo_image or request_logo_image_upload') and gives a specific post-creation instruction ('open it once and save before publishing'). It does not explicitly name create_text_logo_project as the alternative for text-based logos, so it falls just short of full when-not guidance.

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 meaningful behavioral constraints beyond what the annotations convey: the invitee must be signed in, there is a 50-use limit, a 7-day expiration, and owner-only permission is required. No contradiction exists with the annotations, which provide no positive safety hints. It does not describe revocation or what happens after limits are reached, but the disclosed details are substantial.

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, tightly written sentence with no filler. It front-loads the core purpose and packs the important limitations into a compact clause with parentheses, earning every word.

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 definition is mostly complete for a two-parameter tool: it gives the action, role options, limits, and a permission constraint. However, it leaves the id parameter ambiguous and does not mention return values; though an output schema exists, the absence of any param-level guidance makes the description not fully self-sufficient.

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?

With 0% schema description coverage, the description needed to compensate by explaining the parameters. It covers the role values ('editor or viewer') and implies that the invite is project-scoped, but it never explicitly states that the 'id' parameter is the project ID or explains its format. This leaves a critical mapping gap for an agent invoking the tool.

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 explains the tool's effect: it creates a link that lets a signed-in person join a project as editor or viewer, with specific limits. While it is phrased as a noun phrase rather than an explicit action verb, the title and tool name supply the 'create' action, and the details distinguish it from create_share_link.

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 a key prerequisite ('Owner only') and the link's scope (up to 50 uses, 7 days), which implies a short-term collaborator invite. However, it does not explicitly state when to use this instead of create_share_link or any alternative, nor does it mention exclusion cases.

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?

Even though annotations carry idempotentHint, openWorldHint, readOnlyHint=false, and destructiveHint=false, the description adds genuine behavioral context beyond them: it explains the idempotency mechanism ('Reuses the project's active link of the same visibility, so calling twice is safe'), the side effect of public visibility ('makes the page indexable'), the ownership requirement, and the save-once precondition. All behavioral claims align with the annotations; no contradiction.

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

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

A single dense paragraph with no filler. The purpose is front-loaded in the first sentence, followed by visibility semantics, idempotency, prerequisites, ownership, and the alternative routing. Every sentence earns its place and the total is compact given the richness of information conveyed.

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 output schema exists (so return format is covered there), this description covers everything else an agent needs: when to use it, when not to, prerequisites, ownership, visibility behavior, idempotency, and returned artifact types. It even mentions return contents despite the output schema. No meaningful gap remains for a share-link creation 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?

Schema coverage is 50%, with title and allow_download already documented in the schema. The description compensates for the undocumented visibility parameter by explaining unlisted vs public semantics and the default. The required id parameter lacks a schema description, but the description's context ('saved design', 'project must have been opened and saved once') makes clear it is the project ID. Minor gap: no explicit statement that only the project owner's id is valid.

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 (create) plus resource (share link) and a concrete use case: send, post, or embed a saved design. It names exactly what is returned (share page, iframe embed snippet, oEmbed endpoint, poster image URL), and explicitly differentiates itself from create_invite_link by saying 'Do not use to let someone edit.' An agent can instantly tell this tool apart from its siblings.

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 explicit when-to-use conditions ('send a saved design to someone, post it, or embed it on a site'), excludes the editing use case, and names the alternative (create_invite_link). It also states prerequisites ('must have been opened and saved once'), authorization ('Owner only'), and explains the unlisted vs public visibility semantics. Nothing is left to inference.

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?

Beyond the annotations, the description adds useful behavioral context: the operation creates a new persistent project, opens it in the editor, and does not consume credits. It does not discuss overwrite behavior or auth requirements, but 'Saves a new' plus the idempotentHint=false annotation already signal non-overwriting creation.

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 front-load the core action, then state persistence/editor behavior and credit cost. There is no filler or repetition of schema content.

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 creation tool with a rich schema and output schema, the description captures the essential outcome and credit behavior. It is slightly weakened by not naming the closest sibling alternatives, but the schema carries parameter details and the output schema removes the need 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 descriptions already cover title, material, background, and environment, and the description maps 'wordmark' to the required text and 'material and lighting' to material/environment. It does not add semantics for the remaining optional parameters (font, depth, motion), though their enums/ranges provide some guidance, so the description neither fully compensates nor is redundant.

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 action ('Saves a new 3D logo project'), the input ('a wordmark with a material and lighting'), and the user-visible outcome ('appears in the user's Projects and opens in the editor'). This clearly distinguishes it from sibling tools like create_image_logo_project by focusing on a text/wordmark input and the resulting editable project.

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 use when the user wants to persist a text-based 3D logo as an editable project, and it notes that no credits are spent. However, it does not explicitly state when to choose this over create_image_logo_project, save_generation_as_project, or quote_generation, nor does it provide exclusion 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?

Annotations already declare destructiveHint=true and idempotentHint=true, and the description adds valuable context beyond them: permanence of the deletion ('Permanently'), the exact cascade of what gets destroyed (share page and invites in addition to the project), and the ownership authorization requirement. No contradiction with annotations — in fact, the permanent-deletion language strengthens destructiveHint, and a delete is conventionally idempotent.

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 tightly packed clauses: the action with its full destruction scope, the confirmation requirement, and the ownership restriction. Every sentence earns its place, the core action is front-loaded, and there is zero 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?

For a low-complexity tool with only 2 required parameters and an output schema present, the description covers everything an agent needs to invoke it correctly: what is destroyed, the confirmation gate, the authorization boundary, and permanence. Return values are handled by the output schema, and idempotency is declared by the annotations, so no critical information is missing.

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 50% — the confirm parameter already has 'Must be true' and const:true in the schema, but the description adds the missing why: 'Confirm with the user first' ties the boolean flag to a real-world consent gate. The id parameter is undocumented in both schema and description, but is made unambiguous by the tool name and the UUID format/pattern in the schema. The description meaningfully supplements the schema without fully covering the id 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 uses a specific verb ('deletes') against a precise resource ('saved project, its share page and invites'), naming the full scope of destruction. It clearly distinguishes from all 29 siblings — none of which perform deletion — so there is no ambiguity about which tool to pick.

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 explicit invocation conditions: 'Confirm with the user first' (only call after obtaining user consent) and 'Owner only' (only for the project owner). It provides clear context for when the tool is appropriate, though it does not explicitly name alternatives or when-not conditions — acceptable since no sibling tool handles deletion.

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?

Beyond the annotations, the description discloses important behavior: the original is untouched, the copy counts against the project cap, and no credits are spent. It also clarifies that artwork is carried over, which helps the agent set user expectations accurately.

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 compact, front-loads the use case, and every sentence adds meaningful guidance: behavior, side effects, and follow-up action. No filler or redundant restating of the tool name.

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 output schema and annotations, the description covers the essential non-obvious context: source preservation, project cap effect, credit usage, and the relationship to update_project_style. It is fully adequate 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.

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

Schema description coverage is 0%, so the description must supply meaning for the parameters. It does for 'title' ('optionally under a new title') and implies 'id' identifies the saved project, but it never explicitly names the 'id' parameter or states that it must reference an existing project, leaving partial ambiguity.

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 duplicates a saved logo or coin project along with its artwork, optionally under a new title. It also explicitly contrasts the result with update_project_style, making the core purpose unambiguous and distinguishable from sibling creation/editing 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 opens with a concrete when-to-use scenario ('a gold version of this one') and explains the key consequence of not touching the original. It points to update_project_style for restyling the copy, though it does not explicitly enumerate cases where a different tool, such as create_*_logo_project, should be used instead.

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 cover read-only, idempotent, and non-destructive behavior. The description adds useful output details—text summary, opening URL, metadata—without contradicting annotations. It does not discuss errors or rate limits, but for a simple read operation with strong annotation coverage 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.

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

The description is a single well-structured sentence that front-loads the core behavior and then lists the returned contents. No words are wasted, and the structure is easy for an agent 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 one-parameter fetch operation with full annotations and an output schema, the description is complete. It states what the tool returns, how to source the id, and relies on annotations for safety behavior; nothing essential is missing.

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 has 0% description coverage, but the description compensates by clarifying that the id is 'one project id returned by search.' Since there is only one parameter and the schema enforces UUID format, this added context is enough to make the parameter meaningful.

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 fetches full detail for a single project id, including summary, opening URL, and metadata. It is a specific verb + resource, but it does not explicitly differentiate from the sibling get_project tool, so it falls short of full sibling-level distinction.

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 phrase 'returned by search' gives clear context that this tool is meant for ids obtained from search results. However, it does not provide exclusions or directly name alternatives, so the guidance is contextual rather than fully 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?

The description discloses two important behaviors not fully captured by annotations: it spends the user's credits and it returns only a run id to poll rather than the final model. This makes the asynchronous, cost-bearing nature of the operation 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?

Three short sentences cover the action, the input modes, the cost implication, and the follow-up polling mechanism. There is no fluff or redundant restating of the title or 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?

The description covers the essential invocation path: what to provide, that it consumes credits, and how to track the result. With an output schema present and annotations supplying the safety profile, this is mostly sufficient, but the unaddressed density and texture parameters keep it from being fully complete for correct invocation.

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 phrase 'from a text prompt or a public image URL' adds useful meaning to mode/prompt/image_url and signals the two input modes. However, density and texture are entirely unexplained, and the required mode parameter's enum semantics are only implied. With only 40% schema coverage, this is a meaningful 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 states a concrete action—'Starts an AI generate'—and specifies the two input sources: a text prompt or a public image URL. It clearly differentiates this tool from siblings like get_generation_status and quote_generation by positioning it as the initiation step.

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 explicitly directs the agent to quote_generation for credit cost and to get_generation_status for polling the returned run id, giving a clear usage path. However, it does not explicitly state when not to use this tool or compare it with other generation-related siblings like save_generation_as_project.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful context about the account-level scope and the specific limit categories, but 'Read-only' only repeats the annotations. No hidden side effects are disclosed or needed for this read-only tool.

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, well-structured sentence that front-loads the primary use case before enumerating the specific data categories. The final 'Read-only.' is slightly redundant with annotations but does not waste significant space.

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 no-parameter read-only tool with an output schema, the description provides sufficient context: when to use it, what account information it exposes, and the fact that it is safe. There is no missing critical information an agent would need to call this tool correctly.

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, so there is nothing for the description to clarify beyond the schema. Baseline for 0 params is 4; the description appropriately focuses on the return semantics rather than parameter details.

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 identifies the resource ('the connected account') and the action ('know what... can do'), and enumerates the data returned: plan, remaining Generate credits, counts against caps, and export limits. It does not explicitly contrast this with the sibling get_plans, but the phrase 'connected account' makes the current-account focus reasonably distinct.

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 clear contextual guidance: use this tool 'before acting' to understand account capabilities and limits. It does not state explicit exclusions or name alternative tools such as get_plans, but the timing and purpose are clear enough for an agent to decide when to invoke it.

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 mark this as read-only and idempotent, so the bar for additional disclosure is lower. The description adds useful behavior beyond the annotations: the signed URL is valid for an hour, and inline image data is returned only on hosts that display image content. This gives the agent practical expectations about side effects and environment-dependent behavior.

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 carry the precondition, the return behavior, the optional parameter nuance, and the sibling-tool exclusion. Every clause earns its place, and the most important usage condition is front-loaded.

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 annotations, output schema, and the clarity of the description, nothing essential is missing. It covers when to call, what to expect, the optional parameter's effect, the URL validity window, and when to use an alternative tool instead.

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 documents include_image_data directly, and the description clarifies its host-dependent behavior. For the required run_id, the description does not explicitly state that it is the generation run identifier, though this is strongly implied by the tool name and the reference to get_generation_status. With only 50% schema coverage, the description partially compensates but leaves some inference to the agent.

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 what the tool does: returns a signed URL to a provider-rendered mesh preview, optionally including inline image data. It distinguishes itself from get_project_preview and ties to get_generation_status, so an agent can tell it apart from siblings without opening schemas.

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 an explicit precondition ('once get_generation_status reports completed with hasPreview true') and an explicit exclusion ('Do not use for saved logo or coin projects; get_project_preview covers those'). This is model usage guidance with named alternatives and clear conditions.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds workflow context (which run it applies to and what to do when complete), but does not describe behavioral details such as polling semantics or error on unknown run_id; with annotations, this is adequate.

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

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

Two short sentences, front-loaded with the tool's purpose and immediately followed by the workflow note. No filler or repetition of schema or annotation details.

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 status checker with a readOnly/idempotent annotation and an output schema, the description covers what the run is, where the ID comes from, and what to do after completion. Nothing essential is missing for correct invocation.

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 0% for the single run_id parameter, so the description must compensate. It does so by explaining that the run is one started by generate_3d_model or found in user history, giving semantic meaning to run_id beyond its UUID type. It does not explicitly spell out that run_id is required, but the schema marks it required.

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 identifies the resource ('a run'), the process that creates it ('generate_3d_model'), and the title supplies the verb ('Check'). It is distinct from list_generations, which lists runs, and from save_generation_as_project, which persists a completed run, so an agent can route to it correctly.

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 a clear context for use: status of a run from generate_3d_model or user history, and it tells the agent the follow-up action once completed ('save it with save_generation_as_project'). It does not explicitly name alternatives like list_generations for finding history runs, so it earns a 4 rather than a 5.

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 cover readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to restate safety. It adds useful behavioral scope by clarifying the tool returns general plan/credit-pack information rather than account-specific state, and by noting what packs do and do not unlock.

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 deliver the trigger conditions, returned content, safety signal, and an exclusion with no wasted words. The routing-relevant information is front-loaded.

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, read-only tool with an output schema and rich annotations, the description fully covers when to use it, what it returns, and the key sibling to avoid. Nothing needed for correct invocation is missing.

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, so there is no parameter documentation burden on the description. Schema coverage is trivially 100%, and the description's scope statements are sufficient for correct invocation.

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 concrete trigger questions ('what is free, what Pro or Ultra add, what a Generate run costs in credits') and names the returned resources: plan features and one-time credit packs. It also explicitly distinguishes itself from get_account, helping disambiguate within a large sibling list.

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 explicit when-to-use guidance tied to user intents, and an explicit when-not-to-use with the correct alternative: 'Do not use to check the connected user's own plan; get_account does that.' This gives an agent actionable 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context: it returns openings, public page only if published, the GLB, and workspace settings only when include_config is set. 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.

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

Two tight sentences with no wasted words. The first sentence fronts the core purpose and return contents, and the second sentence immediately routes to the relevant sibling. Every phrase earns its place.

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 get-by-id scope, read-only annotations, and existing output schema, the description covers the essential return parts, conditional behavior, the include_config toggle, and the sibling tool for previews. Nothing an agent needs to invoke it correctly is missing.

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 50% and the schema only describes include_config as 'Also return the saved workspace config (large)'. The description enriches this by listing the config contents (material, lighting, motion) and clarifies id as the project identifier. This compensates well for the partial schema coverage.

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 opens with 'Details and links for one saved project by id,' identifying the exact verb, resource, and scope. It also distinguishes itself from get_project_preview by explicitly directing image requests elsewhere.

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 clearly states when to use this tool: when you need the details and links for one saved project. It names the alternative get_project_preview for a picture, and clarifies the conditional include_config behavior, making usage guidance 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?

The description adds substantial behavioral detail beyond the annotations: the URL is valid for one hour, inline PNG is only returned when include_image_data is true, and on hosts that don't display images this costs many tokens. It also discloses the empty-state behavior ('Nothing to show until the project has been opened and saved once'). No contradiction with the readOnly/idempotent/destructive annotations.

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 tightly packed sentences cover use case, return value, caveats, prerequisites, and sibling routing. Every sentence adds information, and the main purpose is front-loaded.

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 a simple two-parameter interface and an output schema, so the description need not enumerate return fields. It covers when to use it, what it returns, the inline-image token concern, the saved-project prerequisite, and the correct sibling alternative. Nothing essential is missing.

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 already documents include_image_data, but the description enriches it by explaining the token-cost and host-display tradeoff. The id parameter is not described in the schema, but the description's reference to 'a saved project' makes its meaning inferable. Overall the description compensates for the 50% schema coverage.

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 purpose: returning a signed URL for a saved project's last render, with optional inline PNG data. It also explicitly differentiates from get_generation_preview, so an agent can distinguish this tool from the sibling set based on the description alone.

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 explicitly says when to use it ('when the user wants to see a saved project, or you need to describe it') and when not to ('Do not use for Generate runs; get_generation_preview covers those'). It also gives a practical prerequisite: the project must have been opened and saved at least once.

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 cover read-only/idempotent/non-destructive behavior; the description goes beyond them by adding 'no account needed' (auth context not present in annotations) and enumerating the data domains it returns. This adds genuine behavioral context and is fully consistent with readOnlyHint=true.

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?

A single sentence with zero filler. The workflow position is front-loaded, the content list is compactly parenthesized, and the safety note is a terse tag at the end. Every clause earns its place.

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, read-only tool backed by an output schema, the description covers when to use it, what it returns, and auth requirements. The only gap is the unaddressed browse_looks sibling, which could leave an agent uncertain which 'looks' tool to choose.

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, so the baseline is 4. The description's enumeration of returned categories gives the agent useful expectations about the tool's domain even though there are no parameters to document.

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 ('list coin looks') and enumerates exactly what is returned: preset looks (gold, chrome, silver, bronze), blank edges (reeded, milled, smooth), motions, lighting rooms, and fonts. It also positions itself relative to the sibling build_coin_studio_link, so an agent can tell what this tool provides and how it fits the coin-studio workflow.

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?

'Use before build_coin_studio_link or a coin restyle' gives explicit when-to-use guidance tied to a workflow step. However, it does not address the sibling browse_looks or state when NOT to use this tool, leaving some alternative-selection 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description reinforces read-only behavior. It adds useful behavioral detail beyond annotations: results include status, prompt, render existence, and are ordered newest first. This is enough transparency for a non-destructive list operation.

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?

One tight sentence front-loads the use case, then lists return contents and ordering, capped with 'Read-only.' Every word earns its place 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 is simple, has one optional parameter, a full output schema, and strong annotations. The description covers purpose, returned fields, ordering, and read-only behavior, so nothing needed for correct invocation is missing.

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%, and the description does not mention the 'limit' parameter at all. The schema itself provides default, min, and max, but the description does not compensate for the low coverage or explain how limit affects the returned run list.

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: 'find an earlier Generate run' and describes exactly what is returned (status, prompt, render existence, newest first). It clearly distinguishes this list operation from sibling tools like get_generation_status or get_generation_preview by framing it as a discovery step before preview/save.

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 context: use when you need to locate an earlier Generate run to check, preview, or save it. It does not explicitly name alternatives or state when not to use it, but the intended use is evident and sufficient for this simple listing tool.

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 convey read-only, idempotent, non-destructive behavior. The description adds useful behavioral context by specifying the output fields (category, Pro requirement) and the exact-string nature of IDs for downstream tool calls. This goes beyond the 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.

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

Three focused sentences with no filler. The main use case is stated first, followed by downstream integration details, and the exclusion/alternative is clearly separated. Every sentence earns its place.

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 list tool with one optional enum parameter, an output schema, and strong annotations, the description fully covers when to use it, what data it returns, and what it should not be used for. Nothing needed for correct invocation is missing.

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% and the only parameter, category, is fully documented with an enum and its own description. The tool description confirms categories are part of the returned data but does not explicitly explain the filtering behavior of the category parameter; still, the schema carries the weight.

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 identifies the tool's purpose: retrieving material IDs for the 3D logo editor, including presets like chrome and gold, with category and Pro-requirement details. It also distinguishes itself from the sibling browse_looks by explaining what it is not for.

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 explicitly states when to use the tool ('Use when you need a material id') and when not to use it ('Do not use to show the user what a look is like'), naming browse_looks as the alternative. It also explains how the IDs connect to other tools, giving agents actionable routing guidance.

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 establish read-only, idempotent, and non-destructive behavior. The description adds useful behavioral context beyond those annotations: newest-first ordering, the saved-project scope, and the available optional filters. It does not mention pagination behavior, but the output schema and annotations cover much of the operational picture.

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 that front-loads the core action and scope, then adds the sort order and filters. Every word earns its place, and there is no repetition of information already in the annotations or 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?

Given the rich annotations (read-only, idempotent, non-destructive), an output schema, and a clear schema for kind/page/query, the description is complete enough for an agent to invoke the tool correctly. The only minor gap is explicit alternative routing, but that is not required for successful execution.

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 only 33%, so the description partially compensates by explaining 'title search' and 'kind filter' for the query and kind parameters. However, it says nothing about the page parameter, and the schema provides only default/min/max for it, so the coverage gap is not fully closed.

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: list the user's saved projects, scoped to 'logos, coins and generated meshes', and adds the sort order 'newest first'. This clearly distinguishes it from sibling tools like get_project (single project) and list_generations (generation history).

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 when to use the tool: whenever the user's saved projects are needed, with optional title search or kind filtering. However, it never explicitly names alternatives or says when not to use it, so the agent must infer usage context from the resource scope.

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, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds useful behavioral context by noting that only active links are listed and what each link entry contains. 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.

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

A single well-structured sentence that front-loads the primary behavior, then appends the optional scope modifier and return contents. 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?

For a simple list operation with one optional parameter, complete annotations, and an output schema, the description covers scope, filtering behavior, and return contents. Nothing essential is missing.

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% and the id parameter already has a description. The tool description adds meaning by explaining the default behavior (account-wide) versus the id-based behavior (one project's links), which complements the schema.

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 verb (list), the resource (share links), the scope (account-wide or project-specific), and the returned data (page, embed, poster URLs, view count). This distinguishes it from mutation siblings like create_share_link and revoke_share_link.

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 context for when to use the tool: without an id for all account share links, with an id for one project's links. It does not explicitly name alternatives or state when not to use it, so it falls 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.

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, and the description reinforces this with 'Read-only, spends nothing.' It adds useful behavioral context beyond annotations by explaining that this is a preflight cost check and that credits depend on mode and density.

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 compact sentences with no filler. The key instruction 'Use before generate_3d_model' is front-loaded, and the rest of the description explains cost and safety without redundant restating of schema fields.

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 low-complexity quote tool with an output schema and strong annotations, the description covers what it does, when to call it, the meaning of its parameters, and its non-destructive nature. The only minor gap is not distinguishing it from other pricing/plan-related siblings, such as get_plans.

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 does: mode is mapped to 'text or image' and density is tied to the credit charge. This adds domain meaning beyond the raw enum values, though it doesn't detail relative costs for each density.

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 clear purpose with a specific verb and resource: quote the credit cost of a Generate run before generating. It differentiates the tool from generate_3d_model and explains the input scope (text/image run at a density), so an agent can understand what this tool does at a glance.

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 explicitly says to use it before generate_3d_model so the user knows the cost, giving a concrete trigger condition. It does not explicitly exclude alternatives like get_plans or other pricing-related tools, which keeps it just 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.

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

Annotations already convey read-only false, idempotent, and non-destructive. The description adds useful behavioral context beyond those: it names the required permission level (Owner or editor) and promises that no other project attributes are modified.

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, each adding information: the action, the permission gate, and the side-effect boundary. No filler or repetition of schema details.

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 low-complexity rename operation with a detailed schema and output schema present, the description covers the action, authorization, and non-destructive scope. Nothing essential is missing.

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?

With 0% schema description coverage, the description must signal parameter roles. 'Renames a saved project' ties title to the new name and id to the existing project. This is minimal but sufficient for two self-descriptive parameters.

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?

Description states a specific action (Renames) on a concrete resource (a saved project), and explicitly scopes the operation with 'Nothing else about the project changes.' This clearly distinguishes it from siblings like delete_project, duplicate_project, and update_project_style.

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 a clear context for use—renaming an existing saved project and the permission requirement (Owner or editor). It does not explicitly name alternatives or state when not to use it, but the scope statement separates it from other update-style tools.

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 important behavior beyond the annotations: it returns a mark id and a one-shot HTTPS PUT URL, requires raw file bytes to be uploaded by the caller, and specifies supported formats and size limits (PNG, JPEG, GIF, WebP at 8 MB, SVG at 1 MB). This gives the agent a solid model of how the tool works. The 'one-shot' detail is especially valuable because it warns the URL cannot be reused.

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 well-structured and front-loaded: it states the purpose, explains the returned artifact, gives a concrete curl example, and lists constraints. Every sentence earns its place, and the length is appropriate for the complexity of the workflow.

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 is complete for the tool's workflow: it explains why this tool exists, what it returns, how to upload the file, what to do next, and what file types and sizes are accepted. Even though an output schema exists, the description gives enough context for an agent to invoke the tool and use its result correctly.

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%, and the schema already explains that file_name is used as the project title later. The tool description adds general context about logo files but does not add much specific meaning to file_name beyond what the schema provides. A baseline of 3 is appropriate because the parameter is adequately documented by the schema.

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 purpose: requesting a one-shot HTTPS PUT URL for a logo file that cannot be included in a tool call. It clearly identifies the resource (logo file), the action (request upload URL), and the key outputs (mark id and upload URL). It is easy to distinguish from siblings like upload_logo_image because it explicitly scopes itself to files that cannot be sent inside a tool call.

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 when-to-use context: use this for a logo file on the user's machine that cannot be sent inside a tool call. It also provides the subsequent steps, telling the agent to call build_logo_editor_link or create_image_logo_project with the mark id. It does not explicitly name an alternative tool such as upload_logo_image, but the condition 'cannot be sent inside a tool call' implies the alternative case.

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?

Beyond the destructiveHint annotation, the description discloses concrete behavioral details: the page, embed, and poster stop serving within minutes, the operation cannot be undone, and only the owner may perform it. This adds meaningful context about irreversible side effects and authorization without contradicting any annotation.

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 two compact sentences that front-load the primary action and effect. Every clause adds a distinct fact: what stops serving, the time frame, irreversibility, the recovery path via create_share_link, and the owner-only restriction. 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?

For a single-parameter tool with an output schema and annotations that already cover readiness and destructiveness, the description covers the essential behavior, irreversibility, and authorization. The only minor omission is explicitly telling the agent where to find a token, but this is inferable from sibling tools and not necessary for correct invocation.

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 0% description coverage and the only parameter, token, is explained only as 'by token' in the description, which largely repeats the property name. The description does not clarify how to obtain a token, whether it is the same token returned by create_share_link, or how a token relates to list_share_links, so it fails to compensate for the schema's silence.

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 ('Turns a share link off') and names the exact resource and scope, including what stops serving: 'the page, the embed and the poster.' It also distinguishes itself from create_share_link by noting the action cannot be undone, so an agent can correctly separate it from nearby 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 gives clear context for use: it is a permanent, owner-only revocation. It explicitly points to create_share_link as the alternative for obtaining a fresh link, which helps an agent decide between the two. It does not explicitly mention listing share links to discover a token, but the core when-to-use guidance is present.

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?

Beyond the idempotentHint annotation, the description adds meaningful behavioral context: setting public=true causes publication, creates a share page, and provides a public GLB URL for download. This is valuable side-effect information that the annotations alone do not convey.

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 carry the core behavior and the key conditional side effect without fluff. The most important information is front-loaded, and every sentence earns its place.

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 is largely complete given the annotations and presence of an output schema. It explains the main action, idempotency, and public-publishing behavior; the only notable gaps are explicit alternative routing and the optional title parameter.

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?

With 0% schema description coverage, the description must compensate for parameter meaning. It explains public=true well and links run_id to a completed run, but it does not clarify the title parameter beyond what its name and schema imply.

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 clear action—keeping/ saving a completed run into Projects—and pairs well with the title 'Save a generated mesh as a project.' It is specific enough to be understood, though it does not explicitly differentiate itself from sibling project-creation 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 phrase 'completed run' implies the tool should be used after generation finishes, and the public=true condition clarifies an optional publishing use case. However, it does not explicitly say when NOT to use it or name alternatives such as set_project_public or create_text_logo_project.

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 readOnly, idempotent, and non-destructive behavior, so the description does not need to restate safety. It adds useful context beyond annotations: searching is by title and the return contract is 'ids with links'. This is meaningful behavioral disclosure, though it stops short of describing edge cases or result 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 sentences, no filler. The primary function and return value are front-loaded, and the sibling routing is given in a compact second sentence. The parenthetical '(the ChatGPT search contract)' is slightly jargon-heavy but does not add meaningful length or reduce clarity.

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 is simple (one required string parameter), has full annotation coverage for safety, and has an output schema, so the description does not need to explain return fields. It covers what the tool searches, what it returns, and when to use sibling tools. Nothing necessary for correct invocation is missing.

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 0%, so the description carries the burden of explaining the query parameter. It does so by specifying that the search is 'by title', which gives the parameter clear meaning. While it doesn't describe fuzzy matching or case sensitivity, for a single simple query parameter this is adequate compensation.

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 ('Searches'), a specific resource ('the user's saved projects'), and a specific search dimension ('by title'), and says it returns ids with links. It also names sibling tools (fetch, list_projects) for related tasks, so an agent can clearly distinguish this from alternatives.

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 explicit routing guidance: 'Use fetch for the detail of one result; list_projects for browsing with filters.' This tells the agent when to choose this tool versus the closest alternatives, leaving little to inference.

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?

Beyond the annotations, the description discloses concrete behavioral effects: published projects get a shareable page, meshes get a public GLB URL, and only owners can perform the action. It does not describe all side effects (e.g., whether unpublishing invalidates existing links), but the annotations already cover read/write, idempotency, and destructiveness.

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, purposeful sentences front-load the core behavior and then add the most important consequence and authorization constraint. No filler or redundant restating of 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 two-parameter, idempotent boolean toggle with an output schema and annotations, the description covers the essential behavioral and authorization context. The only minor gap is that the boolean mapping and project-id semantics are left to inference rather than stated explicitly.

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, but it only indirectly clarifies the 'public' parameter via 'on or off' and never explicitly identifies 'id' as the project ID. The tool name and title make the id meaning inferable, but an agent gets little explicit parameter guidance beyond the schema types.

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 (turn the public view link on or off) and the resource (project), and it adds concrete consequences like a shareable page and public GLB URL for meshes. It is not a tautology and is easily distinguished from share-link tools, though it does not explicitly name a sibling.

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 'Owner only' note gives an important access condition, and the on/off framing implies the tool is used to manage a project's public visibility. However, it does not explicitly state when to prefer this tool over create_share_link or other sharing-related siblings, nor 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.

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

Beyond the annotations, the description discloses important side effects: only supplied fields change, and saved render/thumbnail/share posters refresh only after the project is next opened and saved. It also clarifies that mesh appearance is fixed, which helps set expectations.

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 sentences cover purpose, scope, side effects, and exclusions without padding. The long field list is necessary detail, and the most important usage rule is front-loaded.

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 tool's complexity and the presence of an output schema, the description fully covers when to use it, what it affects, how fields map to project types, and what side effects occur. Nothing essential is missing for correct invocation.

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 adds project-type context to the parameters, explaining which fields apply to text projects vs coins vs logo projects. This meaningfully supplements the schema, which only has brief per-field annotations, and helps the agent select valid parameter combinations.

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 precise action—restyling an existing logo or coin project—and lists the changeable attributes. It explicitly distinguishes this tool from creation and mesh-related tools, so an agent can tell it apart from siblings like create_text_logo_project and duplicate_project.

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 opens with 'Use when the user wants...' and closes with explicit exclusions: 'Do not use for meshes... or to make something new (create_text_logo_project, duplicate_project).' This gives the agent clear when-to-use and when-not-to-use guidance with named alternatives.

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?

Beyond the annotations (idempotentHint, destructiveHint), the description discloses file type/size limits, the 7-day mark expiry, and the return payload (mark id plus editor link). It also warns that image_url must point to the image file itself, not a page. 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.

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

Four sentences with no filler; the core purpose and constraints are front-loaded, and the alternative-tool pointer is placed at the end without diluting the main instruction. Every sentence adds 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?

For a 9-parameter tool with an output schema, the description covers the essential behavioral contract: what is stored, what is returned, size limits, expiry, source selection, and the alternative for local files. Remaining parameter details are already present in the input schema.

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 high (89%), so the schema already documents most parameters. The description adds the critical 'exactly one source' constraint, the small-files-only caveat for image_data, and the public-https requirement for image_url, which materially improves correct invocation.

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 opens with a specific verb and resource ('Stores a logo image') and states the outcome ('returns a mark id plus an editor link already styled'). It also separates itself from request_logo_image_upload, so an agent can distinguish this upload path from the local-file alternative.

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 the selection rule explicitly — 'Give exactly one source: image, image_url, or image_data' — and defines when each is appropriate, including 'small files only' for base64. It also names the sibling for local-machine files (request_logo_image_upload), giving clear when-to-use-versus-alternative guidance.

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