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

The description goes well beyond the annotations by disclosing that the operation is PAID, returns promptly without polling, uses saved IDs to prevent resubmitting completed stages, and requires recovery rather than repeat submission in uncertain cases. These are valuable behavioral traits not present in the structured 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 short sentences, each earning its place: the primary action, the no-polling behavior, and the recovery rule. 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?

The behavioral safety and workflow shape are well covered, and the presence of an output schema reduces the need to describe return values. However, with the sole required parameter undocumented and the uncertainty/failure conditions not fully operationalized, an agent may still be unsure exactly what to pass and when to decide a submission is uncertain.

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 explain run_dir at all. The only indirect clue is that 'Saved IDs' are involved, which may relate to the run directory, but there is no format, purpose, or example for the required parameter.

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 action: 'Check progress once and submit PAID adaptive low-poly remesh when generation succeeds.' This clearly identifies both the verb and the resource, and distinguishes the tool from siblings like meshy_workflow_status (checking only) or meshy_start_multiview (starting a different 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?

The description provides clear usage context: use it once generation succeeds, don't poll, and never retry blindly. It also routes uncertain outcomes to recovery rather than repeat submission or a new run. It does not explicitly name meshy_recover_submission, but the guidance is strong and actionable.

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

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

Annotations already mark the tool as read-only and idempotent, and the description adds meaningful behavioral guarantees: it will not expose credentials and will not call the API. This gives an agent confidence about side effects beyond what annotations 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?

A single sentence that front-loads the core action, then states two important exclusions. Every clause earns its place, with no redundancy.

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

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

For a parameterless diagnostic tool with an output schema, this description is fully sufficient. It states the purpose, the safety constraints, and the scope, leaving no ambiguity about when to invoke it.

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 meaning to explain. The baseline for parameterless tools is 4, and the description appropriately adds no irrelevant 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 uses a specific verb ('check') and a clear resource ('local Meshy credentials'), and it also states what it does not do ('exposing them or calling the API'). This cleanly separates it from the other Meshy workflow tools, which involve planning, starting, or downloading tasks.

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 diagnostic intent obvious: verify local credentials are configured as a prerequisite before using API-dependent Meshy tools. It does not explicitly name alternatives or when not to use it, but the zero-parameter, read-only nature makes the context clear.

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 indicate idempotent and non-destructive behavior, so the description adds value by disclosing a critical cost-related behavior: 'submits no paid tasks'. It also clarifies the concrete side effect of downloading artifacts into the saved run directory.

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 one sentence with the action front-loaded and the important cost/side-effect qualifier appended. Every word contributes meaning, and there is 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 one-parameter tool with an output schema, the description covers what is downloaded, where it goes, and the non-billing behavior. It could explicitly say that the workflow must be completed before calling, but 'completed model' sufficiently implies the prerequisite.

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 clarifies that run_dir is the 'saved run directory' and the destination for downloaded artifacts, but it does not specify whether the directory must already exist or how it is resolved. For a single self-named parameter, this is minimally acceptable.

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 object: download completed model and texture artifacts into the saved run directory. It also explicitly distinguishes itself from paid task submission with 'submits no paid tasks', separating it from siblings like meshy_start_multiview and meshy_advance_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?

The phrase 'completed model and texture artifacts' gives clear context that this is the retrieval step after a task has finished, and 'submits no paid tasks' tells agents when not to use it. It does not explicitly name alternative sibling tools, but the distinction from submission-oriented siblings is clear.

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 openWorldHint, so the read-only nature is covered. The description adds the 'up to 100' bound and the recovery use case, which is helpful context. It does not describe pagination or sorting, but for a read-only list tool with annotations, this is acceptable.

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 worded sentence that front-loads the operation and result. Every phrase adds meaning: the list cap, the purpose, and the read-only guarantee. There is no fluff or repetition.

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

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

The description gives the core purpose and safety profile, and an output schema exists. However, it leaves the required `kind` parameter unexplained and does not clarify how `limit` behaves beyond a cap. For a two-parameter tool with zero schema documentation, this is minimally complete but 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?

Schema description coverage is 0%, so the description must compensate. It only loosely hints at the limit parameter with 'up to 100' and says nothing about the required `kind` parameter or its enum values. An agent gets no guidance on what the two kinds mean or how they filter results.

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 names the operation ('List'), the resource ('existing Meshy tasks'), a specific bound ('up to 100'), and a purpose ('for inspection or uncertain-submission recovery'). It also explicitly says 'read only', which distinguishes it from mutation or recovery siblings 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 provides a clear use context: inspecting tasks or recovering uncertain submissions. However, it does not explicitly mention alternative tools such as meshy_workflow_status or meshy_recover_submission, nor does it say when not to use this tool. Context is present but exclusions are missing.

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 and idempotentHint; the description adds material behavioral context by explaining this is a dry-run validation with redacted request preview and no paid task. This is consistent with the annotations and goes beyond what they express.

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 with the core action front-loaded and the safety/cost qualifier clearly separated. Every word contributes useful information; there is no redundancy or 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 read-only, idempotent planning tool with an output schema, this description covers the essential behavior needed to invoke it safely. Minor gaps remain around exact validation rules and the optional texture_prompt, but the critical 'no paid task' boundary is explicit.

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 clarifies that the four view parameters represent image paths or HTTPS URLs, which adds meaning beyond the plain string types in the schema. However, output_dir and texture_prompt are left unexplained, and with 0% schema description coverage this only partially compensates for missing parameter documentation.

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 action (validate), a specific resource (four image paths/HTTPS URLs), and a preview behavior. The explicit boundary 'No paid task is submitted' clearly distinguishes it from paid submission siblings like meshy_start_multiview.

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 conveys a validation/preview context and explicitly signals that no paid submission occurs, which helps an agent decide when to use it. It does not explicitly name alternatives or provide when-not conditions, so it stops short of full 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?

The description adds meaningful behavioral context beyond the annotations: it clarifies that the tool only attaches an existing task and never creates one, and it requires prior verification from task history. This complements the idempotentHint and openWorldHint 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?

The description is two short sentences with the key behavioral constraint front-loaded. Every sentence earns its place, and there is no redundant prose.

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

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

With an output schema present, return-value details are not required. The description covers what the tool does, what it never does, and the necessary preceding step. It could mention a fallback when no matching task exists, but this is not essential for basic 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 description coverage is 0%, so the description must compensate. It ties task_id to 'verified existing task ID' and links run_dir/stage to selecting 'this exact run and stage,' giving meaningful purpose to all three parameters even without full formal definitions.

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 action ('Attach a verified existing task ID') and explicitly differentiates the tool from task-creation tools with 'Never creates a task.' This clearly distinguishes it from sibling tools like meshy_start_multiview.

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 provides clear when-to-use context ('after an uncertain submission') and prescribes a workflow: inspect Meshy task history first, then select the task matching the exact run and stage. It does not explicitly list exclusions or alternatives, but the guidance is actionable.

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 indicate readOnlyHint=false and idempotentHint=false, so the agent knows it is a mutating, non-idempotent operation. The description adds valuable context beyond that: it mentions the task is 'PAID' (cost implication), that local images are sent to Meshy, and gives practical advice about not repeating after uncertainty (reinforcing non-idempotency). 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?

The description is three sentences with no fluff. It front-loads the core purpose, then provides a next-step instruction and a caution. Every sentence contributes actionable information, and the structure is clear and efficient.

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

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

There is an output schema present, so return values are not required in the description. The tool is complex (paid, multi-view input, workflow continuation), and the description covers the key aspects: what it does, that it's paid, how to continue, and what to do on uncertainty. The only gap is the undocumented optional texture_prompt and the lack of explicit mention of prerequisites (like planning), but these are not critical for the start action.

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 mentions 'four views' which maps to the front, back, left, right parameters, and 'saved run directory' explains output_dir. However, it does not mention the optional texture_prompt parameter at all, and it does not specify the expected format (e.g., file paths vs. URLs) beyond implying local images. It adds some meaning but not comprehensive coverage for all 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?

The description clearly states the action ('Submit one PAID textured Multi-Image to 3D task'), the input (four views), and the result (return the saved run directory). It distinguishes itself from siblings like meshy_plan_multiview and meshy_advance_workflow by indicating it is the start step and that the workflow continues with meshy_advance_workflow. This is a specific verb+resource with clear differentiation.

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 'Continue this run with meshy_advance_workflow' and warns 'Do not repeat start after an uncertain submission; inspect tasks and recover its ID.' This tells the agent when not to use the tool (after uncertainty) and points to alternatives (meshy_list_tasks or meshy_recover_submission). It provides clear context for selecting this tool over others.

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, openWorldHint, and idempotentHint. The description adds beyond these by explicitly stating the tool is local-only and does not refresh remote task status, which is valuable behavioral context about network access and side effects. 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?

The description is one short sentence with a clear main clause followed by a key limitation. Every word adds value, and the most important behavioral scoping ('Local only; does not refresh remote task status') is placed immediately after the core purpose.

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

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

For a simple read tool with an output schema and full annotations, the description covers the core behavior and local-only scope. The main gap is the unexplained run_dir parameter, which prevents complete confidence in calling the tool. Still, the overall complexity is low, so the description is borderline adequate.

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 for the run_dir parameter, but it does not explain what run_dir should contain, its format, or how to obtain it. The phrase 'saved workflow' is a weak hint that run_dir points to a local directory, but it is insufficient for a parameter with zero schema documentation.

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

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

The description clearly states the tool reads a saved workflow and its next step, with a specific verb and resource. It also distinguishes itself from siblings by noting 'Local only; does not refresh remote task status,' which separates it from remote-status tools like meshy_list_tasks or meshy_recover_submission.

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

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

The description implies usage through 'Local only; does not refresh remote task status,' suggesting it is for local inspection rather than remote status checking. However, it does not explicitly name alternative tools or provide clear when-to-use vs. when-not-to-use guidance, leaving some inference to the agent.

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