shapeweld

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

Annotations already declare readOnly, non-destructive, non-open-world, so the safety profile needs no restating, and the description instead spends its words on useful behavior: the shape of the returned content and what happens when a pair is not offered (it reports the miss and suggests the nearest alternatives). Minor gap is that it does not say whether the notes are static curated docs or derived per request, which affects how much trust an agent places in the 'limits' section.

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?

It is a single dense sentence pair whose very first clause is the actionable constraint ('Before uploading anything'), so the agent gets the trigger before the payload description. The parenthetical enumeration of preserved attributes is efficient, though the middle clause is long enough that the 'page for that pair' return value is easy to skim past.

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

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

With no output schema, the description carries the burden of describing returns and does so adequately: surviving features, losses, limits, a page reference, plus the negative case. What remains unstated is the response shape (prose vs structured) and whether the 'page' is a URL the agent can surface, which is a modest gap for a two-parameter read-only lookup.

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%, with the 'from' enum vocabulary and the 'to' vocabulary both documented in the schema itself. The description adds a concrete worked example (fbx to glb) that anchors the argument order, but nothing about normalization, casing, or unsupported target strings beyond the general 'not offered' behavior, so it sits at the baseline for a fully described 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 makes clear this is a reference/lookup tool keyed on a source-target format pair, returning what survives (skeleton, shape keys, materials, vertex colours), what is lost, format limits, and a documentation page. That is a specific and distinct resource from the sibling convert_file, which actually performs conversions, though the description never names that sibling to make the contrast explicit.

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

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

'Before uploading anything' gives a concrete trigger point that tells the agent to call this prior to a conversion attempt, and the unsupported-pair clause signals it is safe to probe pairs speculatively. It stops short of explicitly stating 'then use convert_file to perform the conversion', so the routing to the actual conversion sibling 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 discloses that this starts an asynchronous conversion and returns a job id for polling, which is important behavioral context. It also explains source-format inference and the zip exception, though it does not cover failure modes or rate limits.

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

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

The description is front-loaded and dense with actionable information, with no obvious filler. It is slightly packed but remains readable and appropriately sized for a six-parameter conversion tool.

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?

Although there is no output schema, the description states that the tool returns a job id and points to job_status for polling. Combined with the fully described input schema, it gives an agent enough information to invoke the tool correctly and follow up on the result.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds useful meaning: example target formats, the list_tools mesh-kind option, zip handling via `from`, and an example `options` object. It also clarifies how the source format is inferred from the file name.

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: 'Starts a conversion.' It clearly explains that the tool converts 3D files to a target format or applies a mesh tool kind, which distinguishes it from siblings like list_tools and job_status.

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 invocation guidance: supply `to` and either `file_url` or an attached `file`, and poll with job_status afterward. It does not explicitly state when not to use this tool or compare it against alternatives, but the workflow is unambiguous.

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, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that by enumerating the response state machine and explaining that 'failed' carries a reason and 'refused' means the file needs a choice only the page can offer — a non-obvious behavioral detail. It omits polling/rate behavior and expiry timing, hence 4 rather than 5.

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 tightly-packed sentence with no filler, and the most discriminating information (which job, which states) comes first. The parenthetical about 'refused' is slightly buried at the end, which keeps it from a perfect score.

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 read tool with no output schema, enumerating the possible states effectively substitutes for documenting return values, which is exactly what an agent needs. Missing only lifecycle/operational detail such as how long jobs live or whether repeated polling is expected.

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

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

Only one parameter, documented at 100% coverage as 'The id convert_file answered with', so the schema already carries the semantics. The description reinforces the link to convert_file but adds no format or sourcing detail beyond the schema; baseline 3 is appropriate.

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

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

The description names the resource precisely ('the state of a conversion started by convert_file') and ties it to the sibling that creates the job, so an agent can tell it apart from convert_file and result_link. It is a noun phrase rather than an explicit verb ('check/poll'), which keeps it just short of a 5.

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

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

Usage is only implied: the phrase 'started by convert_file' suggests polling after a conversion request, and the 'expired'/'refused' states hint at terminal conditions. There is no explicit statement of when to call it versus result_link or conversion_notes, and no guidance on polling cadence or when to stop.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the exact shape of each returned record, which matters because there is no output schema — it tells the agent it will get extension lists, an upload cap in MB, a zip flag, and a browser URL per entry.

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 front-loaded sentence that wastes no words — every clause maps to a returned field. The dense comma-chained list is slightly harder to scan than a short enumerated form would be, but nothing is redundant.

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 listing tool with no output schema, the description covers the essential return contents well enough to decide whether to call it. Minor gaps remain: it does not say whether the catalog is static or how the entries are ordered, and it offers no routing to convert_file.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. The field enumeration it does provide describes output, not input, which is appropriate here.

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 makes clear this returns the catalog of conversions the server supports and enumerates exactly what each entry carries (job kind, source extensions, target, upload cap, zip acceptance, browser page). It lacks an explicit verb ("list"/"enumerate") and never names a sibling, so an agent must infer the differentiation from context rather than read it here.

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

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

There is no explicit when-to-use statement and no reference to convert_file, conversion_notes, or any other sibling. Usage is only implied: because it exposes job kinds, extensions, and upload caps, an agent can infer it should be called before convert_file to discover valid inputs, but the description never says so.

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 this a safe, closed-world read, so the description earns credit for adding behavior annotations can't carry: the link expires in 3 days and requires no sign-in. It stops short of describing the failure case when the job is not yet ready.

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 front-loaded sentence with a colon list and no filler. It is a sentence fragment rather than a full clause, but every element listed is meaningful output the agent cares about.

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

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

With no output schema and one well-documented parameter, the description usefully sketches the return payload (link, filename, expiry, viewer URL) plus link lifetime. The only missing piece is behavior when the conversion isn't ready yet.

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 single jobId is described as 'The id convert_file answered with'. The description adds no further meaning about the id itself, so the schema does the work and the baseline 3 applies.

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

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

The description enumerates concretely what the tool returns for a finished job: the download link, file name, expiry date, and a viewer link on the site. The phrase 'For a ready conversion' scopes it to completed jobs, which distinguishes it in spirit from job_status and convert_file, but it never names those siblings explicitly.

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?

'For a ready conversion' implies the prerequisite (the job must be finished) but does not tell the agent to poll job_status first or what happens if the conversion is still running. Usage is inferable rather than stated.

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