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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description's job is to add nuance — and it does, by stating that partial outputs and the receipt survive cancellation, which materially softens the destructive read. It does not say whether cancellation is immediate or graceful, nor what error surfaces for a non-owned job id.

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 compact sentence with the ownership constraint front-loaded before the data-preservation guarantee. No filler, no repetition of the tool name 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?

An output schema exists, so return values need no explanation. For a destructive mutation, however, the definition is thin: it omits how to obtain job_id, whether cancellation is cooperative, and what happens when the id belongs to another session — gaps an agent would otherwise hit at call time.

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% and job_id has no description in the schema, so the description must carry the load. It implies job_id refers to a job owned by the current server session, which is genuinely useful scoping, but adds no format, example, or source (where to obtain the id) beyond that.

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?

Uses a specific verb ("Stop") plus an explicit scope qualifier ("only a process owned by this server session"), which tells an agent this is a cancellation tool restricted to session-owned jobs. It is distinguishable from siblings like danceflow_job_status and danceflow_job_logs by name and verb, but does not explicitly contrast itself with them in the text.

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 "only a process owned by this server session" implies a precondition for use, but the description never states when to cancel versus checking status/logs first, nor what to do if the job is not session-owned. Usage is implied rather than spelled out.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered by structured data. The description adds one piece of genuine behavioral context beyond that: "observed runtime availability," which tells the agent the response includes live status rather than static metadata. It does not say whether unavailability is reported per component or as a summary.

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, front-loading the verb and the scope. Nothing in it is redundant with the tool name or could be cut without losing 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?

With zero parameters and an output schema present, the description need not explain return values, and it covers the scope of what is enumerated. A note on whether this is the recommended first call in the danceflow family would make it fully complete, but nothing required 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?

The tool takes zero parameters, so there are no semantics to clarify and the baseline of 4 applies. The description correctly implies a no-argument, whole-inventory call rather than suggesting any filtering.

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?

"Discover all 17 components, their MCP tools, references and observed runtime availability" names a specific verb (Discover) and enumerates the resources returned, so an agent knows exactly what this yields. It stops short of naming siblings such as danceflow_component or danceflow_search, so the boundary between 'discover everything' and 'fetch one component' is inferable but not stated.

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

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

There is no explicit when-to-use or when-not-to-use statement. The word "Discover" plus "all 17 components" implies this is the entry-point/inventory call before drilling into danceflow_component, but that routing is left to the agent to infer rather than stated.

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 and openWorldHint=true, so the safety and network profile is known. The description adds that results are fetched fresh and that no installation or deployment side effect occurs, which is real added value, but it says nothing about how the "installed" input affects comparison or what the response contains beyond the output schema.

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

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

It is a single short sentence with no filler, which is good, but the phrasing is compressed to the point of ambiguity ("optional observations"). Front-loading the query verb works; the trailing clause is unclear rather than economical.

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

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

An output schema exists, so return values need no explanation, and annotations cover the safety profile. The remaining gap is the unexplained "installed" parameter and the vagueness of "afresh" — for a one-parameter tool this is a modest but real omission.

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 single parameter "installed" has 0% schema description coverage, so the description carries the full burden — and it does not explain the parameter at all. "Optional observations" is the only hint and it does not map clearly onto an object map of string values, leaving an agent to guess its shape and purpose.

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?

"Query official stable releases afresh" gives a concrete verb and resource, and the clause about never installing or deploying packages distinguishes it from siblings like framerudiments_presets_install. The second half ("optional observations") is cryptic and blurs an otherwise specific statement.

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 a partial when-not signal ("never install or deploy packages"), but no positive guidance on when to call this versus siblings such as danceflow_capabilities or the various list/status tools. "Afresh" hints at bypassing cached data but the condition that would make an agent choose this tool is left implicit.

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 supply readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value by naming the categories of information returned (schemas, effects, references, host requirements), but says nothing about behavior on an unknown component, depth or size of the payload, or any prerequisites.

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 with the object of inspection front-loaded after the verb; nothing is redundant. It is efficient, though a little more content would have been justified given the parameter gap.

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

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

An output schema exists, so the description need not document return values, and the description does gesture at the returned categories. The remaining hole is the sole input parameter's format, which is undocumented in both the schema and the description for a tool whose entire invocation hinges on identifying the right component.

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 single required parameter "component" has 0% schema description coverage, and the description does not compensate at all — it never says whether the value is a name, an ID, a path, or a qualified key. With one undocumented parameter, an agent must guess the accepted identifier form.

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 ("Inspect") and enumerates the concrete resource contents: typed operation schemas, effects, references and host requirements. An agent can tell it is a read-only introspection tool for a single component. It does not, however, differentiate itself from siblings like danceflow_capabilities or danceflow_read_reference, which sound adjacent.

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 statement of when to reach for this tool rather than danceflow_capabilities, danceflow_search or danceflow_read_reference, and no preconditions (must the component exist, must it be a workflow component). Usage is only implied by the verb "Inspect".

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 and openWorldHint=false, so safety is covered; the description extends this usefully by saying the response includes full text and source identity, and that procedures retain their runtime/input/permission requirements outside this call. It does not mention behavior for unknown names or lookup failures, which keeps it short of a 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?

Two tight sentences, front-loaded with the core action and identifier source, followed by a single scoping caveat. No redundant restatement of the tool name or annotations.

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 one parameter and an output schema present, the return-value explanation is correctly omitted, and the description covers sourcing, scope, and the non-execution guarantee. The only gap is disambiguating 'linked reference ID' against siblings like danceflow_read_reference.

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 'name' parameter, so the description carries the burden, and it does: it explains the value is a workflow name OR a linked reference ID obtained from danceflow_list_workflows or danceflow_search. That is meaningful added meaning, though it doesn't give format examples or say whether a linked ID and a plain name are distinguished syntactically.

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 (read a workflow) plus the accepted identifier forms (workflow name or linked reference ID), and names the sibling tools that produce those identifiers. It also draws a clear boundary by stating the call does not execute procedures, which separates it from run-style 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?

Explicitly tells the agent where the input comes from -- danceflow_list_workflows or danceflow_search -- which is real routing guidance. It also gives a negative case (this doesn't run procedures), but it doesn't contrast with danceflow_read_reference or danceflow_component for other reference types, leaving that distinction 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is partly covered. The description still adds real value beyond that: output is explicitly framed as untrusted data (a prompt-injection caution) and reads are declared bounded with a next_offset continuation token, neither of which appears in the annotations or schema.

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

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

One sentence, front-loaded with the action and the safety caveat, with the pagination instruction second. Nothing is redundant or wasted.

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

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

An output schema exists, so return values and next_offset need not be explained in prose. However, with three undocumented parameters and no sibling differentiation, the definition is only minimally sufficient for an agent to page through logs 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 carry parameter meaning, and it largely does not. 'Bounded' loosely hints at limit, but the units of limit and offset (bytes vs lines), what offset is relative to, and the role of job_id are all unstated; next_offset referenced in the text is not even an input 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 states a specific verb and resource: reading bounded job output (logs). It is clear what the tool returns, but it never distinguishes itself from nearby siblings such as danceflow_job_status or danceflow_read_artifact, so an agent must infer which one yields log text.

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?

'follow next_offset for more' implies the pagination loop and when to call again, which is useful. There is no guidance on when to prefer this over danceflow_job_status, danceflow_list_jobs, or danceflow_read_artifact, so tool selection 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description does add one piece of behavioral context beyond them by naming two status values (needs_review, unknown_after_restart), but it does not explain what those states mean or what an agent should do on 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?

One short sentence with the action front-loaded and no filler. The trailing clause is terse to the point of being cryptic, but nothing is wasted.

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

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

An output schema exists, so return values need no explanation, and annotations cover the read-only profile. However, the dangling reference to needs_review and unknown_after_restart without explanation, plus the undocumented job_id origin, leaves the definition thinner than a job-status tool should be.

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% for the single required job_id, and the description does not say what form the ID takes or where it is obtained (e.g., from danceflow_list_jobs). The one parameter an agent must supply is entirely undocumented.

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

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

"Inspect an adapter job" gives a verb and a resource, and the tool name implies status retrieval, but the description never says it returns the job's current state or what an 'adapter job' is. It also does not distinguish it from siblings such as danceflow_job_logs or danceflow_list_jobs.

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 statement of when to call this versus danceflow_job_logs (logs of a job) or danceflow_list_jobs (enumerating jobs). An agent must infer from the name alone that this is the single-job status lookup.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The word 'retained' hints that results are a stored subset of past jobs rather than live state, which is genuine added context, but the description says nothing about ordering, pagination, or how far back retention goes. With annotations doing the heavy lifting, this is adequate but thin.

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 short sentence, scope first and the alternative second, with no filler or redundancy. Every clause carries information an agent needs to choose this tool or reject it.

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

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

An output schema exists, so return contents need not be described, and with one optional parameter the surface is small. Still, the description leaves 'adapter' and 'receipt' undefined and does not clarify how this listing differs in content from danceflow_job_status or danceflow_job_logs, which an agent needs in order to call the right tool.

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

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

The single parameter 'limit' has 0% schema description coverage and the description never mentions it, so an agent gets no meaning for it beyond its name and default of 50. Because coverage is below 50%, the description was expected to compensate for the schema gap and does not.

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

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

The description gives a concrete verb and resource ('List retained adapter job receipts') and explicitly separates that scope from 'native StemLab jobs', so it is more than a restatement of the name. It falls short of 5 because 'retained adapter job receipts' is unexplained jargon and it does not distinguish this from nearby siblings such as danceflow_job_status or danceflow_job_logs.

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 supplies an explicit when-not-to-use rule with the alternative named ('native StemLab jobs use stemlab_list_jobs'), which is exactly the routing an agent needs for the adapter vs. native split. It gives no guidance about relationship to the other job-related siblings in the same server (status/logs/cancel), so the surrounding decision space is only partly covered.

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 annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine context by saying what the listing returns (summaries, coverage, the follow-up call to read each procedure) and that it does not execute anything, but it says nothing about pagination defaults, result-size limits, or what happens when no workflows are configured.

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 front-loaded sentence that leads with the core capability and appends the return-content detail. The semicolon-chained clauses get dense toward the end, 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?

An output schema exists, so return values need not be documented, and the annotations cover safety. The remaining gap is parameter behavior for a four-parameter tool with zero schema coverage, which the description does not fill.

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 carries the whole burden for four parameters, and it largely fails: 'query' and 'component' are never mentioned, and 'pagination' gestures at limit/offset without explaining ordering, defaults, or the meaning of the offset/limit pair. Only a vague hint is added beyond the bare 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 gives a specific verb ('Browse') and resource ('workflow guides and WorkflowMoves skill recipes') with a clear scope qualifier: no IDs needed. That implicitly separates it from danceflow_get_workflow, though the sibling is never named, so differentiation relies on the reader inferring it.

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 one clear selecting condition ('without knowing their IDs') and one boundary ('does not execute them'). It never names danceflow_get_workflow or danceflow_search as the alternatives, so an agent must infer which of the many lookup tools to choose when an ID or search term is available.

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 and openWorldHint=false, so safety and locality are covered structurally. The description still adds real value by disclosing that content is UTF-8, bounded to a page, workspace-scoped, and explicitly untrusted data rather than instructions — a useful prompt-injection caveat. It stops short of describing error behavior for missing paths or how paging terminates.

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 with no filler, and the trust caveat is appended compactly after the core action. Every clause carries information the agent needs.

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

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

An output schema exists, so return-value explanation is not required, and annotations cover the safety profile. What remains thin is the relationship to sibling read tools and the meaning of the paging parameters, but for a simple three-parameter read call the description is largely 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 all three parameters (path, limit, offset) are undocumented in the schema. The description's "bounded ... page" hints that limit/offset control paging, but it never explains path resolution, offset units, or what happens when limit is exceeded, leaving most parameter meaning to inference.

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 ("Read a bounded UTF-8 report page") and scopes it to "the selected workspace", so the agent knows this returns report content rather than metadata. It does not, however, distinguish itself from the closely named sibling danceflow_read_reference, which an agent could easily confuse with it.

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 statement of when to use this tool versus danceflow_read_reference, danceflow_search, or the workflow/timeline tools. The intended use (paging through an artifact) is only implied by the phrase "bounded ... page".

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 and openWorldHint=false, so the safety profile is covered. The description adds one genuine behavioral trait beyond that: reads are restricted to an 'allowlisted' catalogue, implying unknown or non-allowlisted IDs will not resolve. It does not say what happens on a missing/unallowlisted ID, but the added restriction is real value.

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 compact sentence with no filler, front-loaded on the verb and resource. It is perhaps too terse for the information it needs to convey, but nothing is wasted.

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

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

An output schema and annotations exist, so return values and safety need not be described. Still, for a three-parameter tool with zero schema documentation, the description omits the section parameter, the defaults, and any routing versus siblings, leaving real gaps an agent must guess around.

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 carries the full burden, and it only partially delivers. It hints at kind values (component, skill/guide, workflow, overview) but never explains the defaults (kind=component, section=capabilities), never mentions the 'section' parameter at all, and labels the required 'name' parameter as 'catalogue ID', a terminology mismatch that could cause wrong arguments.

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 (Read) and enumerates candidate resource types (component skill/guide/capabilities, workflow, overview) from a catalogue. However, the enumeration is muddled and the phrase 'by catalogue ID' does not map cleanly to the required parameter named 'name', so an agent cannot cleanly distinguish this from siblings like danceflow_component, danceflow_get_workflow, or danceflow_capabilities.

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

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

No when-to-use guidance and no named alternatives, despite several plausible siblings (danceflow_search for discovery, danceflow_list_workflows, danceflow_component). The agent must infer that this is a fetch-by-known-ID tool rather than a discovery 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 establish readOnlyHint=true and openWorldHint=false, and the description adds genuinely new behavioral context: an empty query enumerates the full catalogue, results carry runtime requirements and follow-up calls, and — most importantly — discovery never executes a workflow. That last clause prevents a real misuse mode, though no rate limits or result-size behavior are mentioned.

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?

Roughly forty words across three sentences, front-loaded with the routing instruction "Start here" and the core verb. The clause listing result contents is dense but each item is informative, so little trimming is warranted.

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

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

An output schema exists, so return shape need not be spelled out, and the description still previews the useful contents (schemas, runtime requirements, follow-up calls, coverage). For a five-parameter read-only discovery tool, an agent has enough to select and call it correctly, with the only gap being the kind/component filter semantics.

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 must carry the parameters, and it only partly does: it explains that query is free text derived from a task and that an empty query browses all, and it implies limit/offset through "pagination." The kind enum is only loosely reflected (tools, workflows, skills, features), leaving component and reference undocumented in both schema and description.

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-plus-resource: find tools, workflows, skills and features by words from a task, and flags itself as the entry point with "Start here." That distinguishes it from siblings like danceflow_capabilities or danceflow_list_workflows without naming them explicitly, 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?

It gives clear usage context: search by task wording, and use an empty query to browse everything. What is missing is an exclusion rule — it never says when to skip this tool and go straight to danceflow_list_workflows or danceflow_get_workflow for a known item.

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 and openWorldHint=false, so the agent knows this is a local, non-mutating operation. The description adds the useful scope constraint that it neither captures nor uploads data, but says nothing about what 'validation' actually checks, whether failures are raised or returned, or whether validation is cheap or expensive.

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 with no filler; the verb and resource come first and the exclusion follows. It is efficient, though given the undocumented nested parameter the terseness comes at the cost of missing necessary detail.

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

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

An output schema exists, so return values need not be explained. But the sole parameter is an opaque nested object with no properties and no description, and the description does not compensate, so the definition is not sufficient for a correct invocation even though the tool itself is conceptually simple.

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?

There is a single required parameter, 'capture', typed only as a bare object with zero schema description coverage and no declared properties. The description does not clarify whether 'capture' is an inline payload, a path, a job/artifact identifier, or which fields a bounded capture must contain, leaving the caller unable to construct a valid call.

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 ('Validate') and a specific resource ('an existing bounded motion capture'), so an agent knows the operation without opening the schema. It also names the DanceMoves family, distinguishing it from the danceflow/stemlab siblings, though it does not contrast with the two closest siblings (dancemoves_validate_page_config, dancemoves_validate_timing_file) beyond the differing resource.

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

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

'no sensor capture or upload' is a genuine exclusion that rules out an acquisition use case, which is useful routing information. However, there is no positive when-to-use statement, no prerequisite (e.g. capture must already exist / be registered), and no explicit pointer to an alternative when the agent does need to capture or upload.

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 and openWorldHint=false, so safety framing is partly covered; the description adds that no browser is mounted, which meaningfully tells the agent this is a fast, side-effect-free check rather than a render. It says nothing about what happens on invalid config (throw vs. structured error list) or whether normalization mutates anything downstream.

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 with zero filler; the constraint clause is placed where it matters. It is arguably too terse for a tool whose sole argument is an opaque nested object, but nothing is wasted.

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?

Schema description coverage is 0% and `config` is an untyped nested object, so the description is the only place the required config shape could be conveyed — and it says nothing about which keys are expected (page? bpm? beats?). An output schema exists, so return values need not be explained, but the input side leaves a real gap for a non-trivial nested payload.

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, `arguments.config`, and the description does not describe its expected shape at all.

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 specific verbs (validate, normalize) and a specific resource (page/beat configuration), plus a scoping note that it talks to the installed DanceMoves API. It does not distinguish itself from the sibling validators (dancemoves_validate_motion_capture, dancemoves_validate_timing_file, react_timeline_sequence_validate_beat_clock), so an agent must infer the taxonomy.

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

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

"No browser mount" implies this is the headless/pre-flight path for checking a page or beat config, which hints at when to reach for it. However, there is no explicit statement of when to prefer it over the sibling validators or over the react_timeline_sequence_beat_grid/sample tools, and no prerequisites are given.

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 annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully reinforces that no URL is fetched and no file is written, ruling out hidden side effects, but says nothing about what rules are checked, how failures are reported, or whether validation is strict or advisory.

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 compact sentence with the core action front-loaded and the side-effect disclaimer trailing. Nothing is wasted, though the terseness comes at the cost of the parameter detail noted elsewhere.

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

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

An output schema exists so return values needn't be described, but for a validation tool with undocumented nested parameters the definition should still convey what is validated and what the kind/filename switches do. As written, an agent could call it correctly only by guessing at the parameter semantics.

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 parameters are nested under an 'arguments' object with three undocumented fields. The description mentions cue/lyric text but does not explain the 'kind' enum (cue vs lyric), the role of 'filename', or the 1 MB text ceiling, so it fails to compensate for the coverage 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?

States a specific verb (validate) and resource (cue/lyric text), and the 'no URL fetch or file write' clause distinguishes it from file- or capture-oriented siblings like dancemoves_validate_motion_capture. It does not explicitly name an alternative, but the resource is narrow enough that confusion is unlikely.

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 implied: pass in UTF-8 cue or lyric text and it will be validated. There is no explicit when-to-use framing, no statement of what validation gate this satisfies, and no pointer to related tools for validating other artifacts.

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?

readOnlyHint=true and openWorldHint=false already tell the agent this is a safe, closed-world read, so the description's burden is reduced. It adds a genuine scoping fact, that this reads native data without a motion-engine fallback, but that clause is cryptic and no further behaviour (pagination, filtering, failure modes) is disclosed. Adds some value beyond the annotations, not a lot.

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 short, front-loaded sentence with no filler. The semicolon clause is an odd fragment rather than a well-structured qualifier, but nothing is bloated or buried.

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?

Complexity is low and an output schema exists, so return values need not be explained. Even so, for a paged catalogue read the description supplies no usable parameter semantics, no guidance on when to prefer it over dancerudiments_sample, and no explanation of its "fallback" clause, leaving real gaps for an agent deciding how to call 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?

Schema description coverage is 0% and the single nested "arguments" object carries limit, offset and query with no descriptions anywhere. The description does not mention paging, result caps, or what query matches, so it clearly fails to compensate for the coverage gap; only the "catalogue" framing hints that listing/paging is involved.

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?

It uses a specific verb ("Read") on a specific-sounding resource ("native movement descriptors, periods and dimensions"), which tells an agent this is a reference/catalogue lookup. However, the terminology is domain jargon and the description never says plainly what the tool returns or how it differs from the closely named sibling dancerudiments_sample, and it has no title to lean on.

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 "no motion engine fallback" gestures at a constraint but never states when to call this versus dancerudiments_sample or stemlab_rudiments. There are no prerequisites, no exclusions, and no explicit statement of the selection rule an agent should apply.

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 and openWorldHint=false, so the safety profile is covered. The description does add genuine behavioral context, the 64-pips-per-beat quantization, which the schema never states. It does not say what happens with an unknown name, whether output is deterministic, or what volume of data 4096 pips implies.

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 with no filler. It is efficient, though the brevity contributes to the underspecification rather than being a virtue on its own.

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

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

An output schema exists so return values need not be explained, but for a tool with a nested required arguments object and an obscure domain noun, the definition omits the name source, valid-name enumeration, and whether the call errors on bad input. That leaves an agent unable to invoke it correctly without trial and error.

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 carries the burden, and it partially does so: it clarifies that pips are signed integers at 64 per beat, a unit the schema omits entirely. However it never explains where a valid "name" comes from or what the 1-4096 item limit on pips means, so the nested arguments object remains half-documented.

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?

"Sample a named native movement" gives a verb (sample) and an object (movement), but "native movement" is undefined terminology that an agent cannot resolve from the name or siblings. Nothing distinguishes it from dancerudiments_catalogue or react_timeline_sequence_sample_beat_clock beyond the pips unit.

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

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

The description gives no when-to-use guidance, no exclusions, and names no alternative among the many sibling sampling/catalogue tools. An agent must guess whether to call dancerudiments_catalogue first to obtain a valid name.

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 the tool returns a retained background job and must be polled via danceflow_job_status. It also identifies base effect flags as write and warns that inference/download effects are conditional. It does not describe failure handling or permission application details, but it adds substantive behavioral context.

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

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

The description is short, front-loaded, and free of filler. Its telegraphic phrasing such as 'Base effect flags: write' is efficient but slightly compressed, which keeps it just below the highest 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 description covers the asynchronous job workflow and conditional effect flags, which are important for this tool's complexity. It does not explain the required font argument, the nature of the generated demo project, or several configurable options, though the schema and output schema carry some of that burden.

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 some meaning by clarifying that the project goes into a new directory and by linking permissions to write, inference, and download effects. However, it does not explain important nested parameters such as font, width, height, effects, rangoli, spectrum, rudiments, or effect_preset, leaving clear gaps even with 50% schema description 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 verb and resource: 'Generate an explicit synthetic demo project in a new directory.' It does not explicitly distinguish this from siblings such as framerudiments_render, framerudiments_plan, or framerudiments_preflight, so it falls short of full sibling 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 gives procedural guidance to poll danceflow_job_status and inspect danceflow_component for conditional inference/download effects. It does not say when this tool should be used instead of alternatives like framerudiments_render or framerudiments_plan, nor does it state 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?

Annotations already declare a non-readonly, open-world, non-idempotent operation, and the description adds context beyond that: it is asynchronous, returns a retained background job, and carries write/download/network effect flags. It also warns that additional conditional inference/download effects may apply depending on the component, which is real behavioral disclosure. It stops short of saying whether re-running is safe or what happens to an existing installed runtime.

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 tight sentences, front-loaded with what is downloaded/built, followed by the async contract and the effect-flag caveat. Every clause carries information, though the final 'inspect danceflow_component' pointer could be folded more cleanly into the effect-flag sentence.

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 async job contract and permission-flag warning are the right things to surface, and an output schema exists so return values need not be described. What is missing is guidance on the engine choice and the directory/parallel arguments for a tool whose schema leaves half its nested fields undocumented, so an agent still has gaps before invoking it 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 50%, so the description needs to compensate. It names the base effect flags (write, download, network), which partially maps to the nested permissions object, but it says nothing about the meaning of 'engine' (butterchurn vs projectm), 'directory' (presumably the install target), 'parallel', or the allow_downloads gate. The added meaning is partial rather than compensating for the 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 uses a specific verb pair and resource: 'download/build one pinned canonical visualiser runtime'. The singular, pinned, canonical framing separates it from general render/preflight siblings in the framerudiments_* family. It does not name a specific sibling it replaces, 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?

The word 'Explicitly' signals an intentional opt-in step, and the description routes the agent to danceflow_job_status for polling and danceflow_component for conditional effects. However it never states when to prefer this over nearby setup/preflight tools such as framerudiments_preflight or framerudiments_visualisers, so usage is implied rather than spelled out.

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

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

Annotations already declare write, non-idempotent, non-destructive, closed-world. The description adds real value beyond them: the operation returns a retained background job rather than completing synchronously, it emits a file, and it carries a base write effect plus potentially conditional inference/download effects that must be inspected via danceflow_component. It does not disclose overwrite behavior when the ledger file already exists, nor what happens if validation fails.

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 front-loaded with the operative fact: what it does, what it returns, and which flags apply. No filler. The telegraphic register ('Base effect flags: write.') is efficient but borders on cryptic for an agent unfamiliar with the effect-flag vocabulary.

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

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

An output schema exists, so return values need not be described, and the async/poll behavior is correctly flagged. However, for a write tool with a nested permissions object and required project/output paths, the description omits how 'pinning' is established, whether the output file is created or overwritten, and how permission acknowledgement interacts with the conditional inference/download effects it mentions.

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 50%: the permissions object is documented, but project and output carry only regex/length constraints with no prose. The description partially compensates by implying output is the destination ledger file and that project refers to pinned inputs, but it never states expected format (name vs. path) or whether output may overwrite an existing file. Baseline 3 is appropriate given the mixed 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 pairs specific verbs with a specific resource: validate pinned project inputs and write a frame ledger JSON file. That distinguishes it from framerudiments_render and framerudiments_preflight at a glance. It stops short of 5 because 'frame ledger' and 'pinned project inputs' are project-specific jargon not elaborated, and the relationship to the closest sibling (fram erudiments_preflight) is never stated.

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 tells the agent what to do after invoking (poll danceflow_job_status) and where to look for conditional effects (danceflow_component), which is genuinely useful sequencing guidance. But it offers no when-to-use or when-not guidance relative to preflight or render, and no statement of prerequisites beyond the vague 'pinned' qualifier.

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 goes materially beyond the annotations by disclosing that each call creates a new evidence directory and returns a retained background job requiring polling — behavior consistent with idempotentHint=false but not derivable from it. It also warns that base flags are 'write' with conditional inference/download effects that must be inspected elsewhere, which is meaningful context for a mutation-flagged tool. It stops short of saying what gets destroyed or overwritten if the target exists.

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, front-loaded with the action and scope, then the async contract, then the permission caveat — no filler. The final sentence is slightly cryptic ('Inspect danceflow_component for conditional inference/download effects') but still earns its place by pointing at the permission decision.

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

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

An output schema exists, so return values need not be explained, and the async/polling contract is covered. What is missing is the semantic meaning of the required project and output arguments and any statement of what the preflight checks for or what constitutes success versus failure.

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 nested permissions object carries its own description, but project and output have none in either schema or description. The description adds real meaning for the effect flags ('base write', 'conditional inference/download'), which partially compensates for the gap, but the two required path-like arguments remain undocumented.

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

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

The description names a specific verb and resource ('Run the canonical renderer preflight') and states its scope ('in a new evidence directory'), which distinguishes it from siblings like framerudiments_render and framerudiments_plan. However, 'preflight' is domain jargon and the description never says what the preflight actually validates, so an agent gets the shape of the operation but not its substance.

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 useful follow-up routing ('poll danceflow_job_status') and points at danceflow_component for conditional effects, which is real when-to-use guidance. It does not say when an agent should choose this over framerudiments_plan or framerudiments_render, nor what prerequisites must be in place, so the choice among sibling renderer tools remains implied.

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

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

Adds real context beyond the annotations: the call returns a retained background job requiring polling, and the base effect surface is write/download/network, with inference/download effects conditional on component inspection. It does not say whether re-installation overwrites existing presets or what happens on partial failure.

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

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

Four short sentences, front-loaded with the action and precondition, then the async behavior and effect disclosure. Dense and mostly waste-free, though the effect-flag sentence is telegraphic enough to read like annotation restatement.

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 an output schema exists, return values need not be detailed, and the description still flags the async job model and effect surface. For a nested-schema, network-touching install operation it is adequately complete, with the only gap being the meaning of the per-argument fields.

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 description only indirectly explains parameters: 'explicit authorization' maps to allow_downloads, and the effect flags map to the permissions object's write/download/network keys. The arguments sub-properties (directory, packs, cache) receive no explanation 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?

States a specific verb plus resource: installing separately pinned upstream executable preset libraries. It is clearly a distinct action from read-oriented siblings like framerudiments_presets_profile or framerudiments_preflight, though it never explicitly contrasts itself with those 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?

Gives a clear precondition ('after explicit authorization') and routes the agent to follow-up tools: danceflow_job_status for polling and danceflow_component for conditional effects. It does not state when to avoid installing (e.g., if presets are already present) or name an alternative 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?

Beyond the annotations, the description discloses that this returns a retained background job and that callers must poll danceflow_job_status. It also flags base write effects and points to danceflow_component for conditional inference/download effects, though it does not elaborate on the destructive behavior indicated by the 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 short and front-loads the core operation before the follow-up job and effect details. Its telegraphic style is efficient, though a few phrases are cryptic enough to 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?

Given the complex nested schema and background-job behavior, the description covers the job lifecycle and permission/effect model reasonably well. It still leaves the required and optional arguments entirely unexplained, which is a meaningful gap for invoking 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?

The schema has many nested arguments, including required suite, catalogue, and output fields, but the description adds no meaning about any of them. With only the permissions field carrying schema description coverage, the description does not compensate for the undocumented argument 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 states the action as capturing a bounded selection of canonical preset responses, which gives some sense of the operation. However, the resource and outcome remain jargon-heavy, and it does not clearly distinguish this tool from nearby preset/profile or preset-install 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 provides useful procedural guidance by saying to run Prism analysis separately and to poll danceflow_job_status after the retained background job is created. It also points to danceflow_component for conditional effects, but it does not explain when to choose this tool over related preset or profiling 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?

Annotations already declare write (readOnlyHint=false), non-idempotent, non-destructive, and closed-world, and the description stays consistent with them. Beyond that, it discloses the async retained-job model and, importantly, that the base effect flag is write while inference/download effects are conditional and must be inspected via danceflow_component - context the annotations alone cannot convey. It stops short of saying whether re-rendering overwrites prior artifacts, which is the main remaining gap.

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 compact sentences, front-loaded with the action, then the job contract, then the effect flags - no filler. The density borders on jargon ("source-bound", "retained background job"), but nothing is wasted.

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

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

An output schema exists, so return shape need not be restated, and the async/polling and permissions guidance is present. For a mutation tool with a nested four-field argument object and multiple near-sibling tools, the missing parameter semantics and missing when-to-use contrast leave meaningful gaps.

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 schema description coverage at 50% and a nested arguments object holding project, output, crf, and preset, the description adds almost nothing: "source-bound project" loosely maps to project, but output, crf, and preset semantics go unexplained in both schema and prose. Only the permissions object carries its own schema description, so the burden the description should have carried is largely unmet.

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?

"Render a source-bound project with media and verification artifacts" gives a concrete verb plus resource and implies asynchronous production work rather than planning. It does not explicitly separate itself from close siblings such as framerudiments_plan or framerudiments_preflight, so an agent must infer the ordering.

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 supplies the post-call path clearly ("poll danceflow_job_status") and points to danceflow_component for conditional effect checks, which is useful routing. However, it never states when to choose render instead of framerudiments_plan, framerudiments_preflight, or framerudiments_demo, so preconditions for invoking it are left implicit.

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 context the annotations cannot: despite a 'list' verb, the call returns a retained background job, so the agent must poll danceflow_job_status. It also states that no base effect flags apply and that conditional inference/download effects must be confirmed via danceflow_component, which explains why readOnlyHint is false and why the permissions object exists. This is consistent with the annotations (readOnly=false, idempotent=false).

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

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

Four short sentences, front-loaded with the purpose, followed by the two operational caveats. Nothing is redundant. The phrasing 'Base effect flags: none' is terse to the point of being cryptic without the surrounding 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?

An output schema exists, so return values need no explanation, and the async job lifecycle plus the effects caveat are both covered. The remaining gap is sibling disambiguation against framerudiments_sprites and framerudiments_visualisers, which an agent needs in order to pick the right tool in this large family.

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 only substantive parameter is the permissions object, which already carries its own schema description. The line 'Base effect flags: none' usefully tells the agent not to request write/network/download flags at base, but the empty `arguments` object and the mechanism for acknowledging conditional effects are left implicit.

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: 'List installed renderer, sprite or pinned visualiser capabilities.' An agent knows it is an enumeration tool. However, folding 'sprite' and 'visualiser' into the scope muddies the boundary with the sibling tools framerudiments_sprites and framerudiments_visualisers, which likely own those resources.

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 follow-up instruction ('poll danceflow_job_status') and routes conditional effect questions to danceflow_component, which is genuine usage guidance. It never says when to pick this tool over framerudiments_sprites or framerudiments_visualisers, which is the main ambiguity for an agent at selection time.

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 annotations already set readOnly=false, idempotent=false, destructive=false, so the safety profile is known. The description adds real value by disclosing that the call retains a background job and must be polled, plus that base effect flags are none while inference/download effects may be conditional. It stops short of saying what the job does or whether repeated calls stack jobs.

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, front-loaded with the operation, then the follow-up action, then the effect caveat. No filler. Dense phrasing like 'pinned visualiser' costs some clarity but nothing is wasted.

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

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

An output schema exists so return shape needs no explanation, and the async job pattern is covered. What is missing for a tool in a dense family of ~14 framerudiments siblings is any statement of how it relates to renderers/visualisers, which an agent needs to choose 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 coverage is 50% and the permissions object already carries its own description. The description adds only the terse 'Base effect flags: none', which implies the permissions argument need not be populated for the base case. The empty arguments object is never addressed, so there is no detail 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 description says it lists installed renderer, sprite or pinned visualiser capabilities, which gives a verb and resource. But it never distinguishes itself from close siblings framerudiments_renderers and framerudiments_visualisers, and the meaning of 'pinned visualiser' or 'sprite capability' stays opaque to an agent reading only the definition.

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 does supply downstream routing: poll danceflow_job_status, and inspect danceflow_component for conditional inference/download effects. What it never says is when to pick this over framerudiments_renderers or framerudiments_visualisers, so selection among the three listing tools 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, it discloses the important async model ("Returns a retained background job") and the effect posture ("Base effect flags: none"), which explains why readOnlyHint is false despite a "list" verb. It still does not say what authorization the job creation needs, how long the retained job lives, or whether repeat calls are idempotent, so the disclosure is partial rather than complete.

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

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

Four short sentences, front-loaded with the core action before the operational follow-ups. The telegraphic "Base effect flags: none" is slightly cryptic out of context but every sentence carries information; nothing is padded.

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

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

For a two-parameter tool with an output schema and full annotations, this covers the essentials: what is listed, that a job is returned, how to poll it, and the effect-flag posture. The only real gap is the absence of any differentiation from the renderers/sprites siblings, which matters given the dense sibling namespace.

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 50% schema coverage and an empty `arguments` object, the description contributes by tying "Base effect flags: none" and the conditional inference/download effects to the `permissions` acknowledgment object, telling the agent it likely has nothing to declare by default. It adds no meaning for the required `arguments` parameter itself, which is undocumented in both places.

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 concrete verb and resource: "List installed renderer, sprite or pinned visualiser capabilities." That is more specific than the bare name, but it does not explain how this differs from the sibling tools framerudiments_renderers and framerudiments_sprites, whose subject matter it overlaps with in the same sentence.

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 real downstream routing — "poll danceflow_job_status" after calling and "Inspect danceflow_component for conditional inference/download effects" — which tells an agent what to do next. However, it never states when to choose this tool over framerudiments_renderers, framerudiments_sprites, or framerudiments_capabilities, so the selection decision against those siblings 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?

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description usefully reinforces the closed-world constraint with 'bounded', 'local', and 'without network collection'. However, 'reviewed evidence import' implies ingesting external data into some store, which sits in tension with readOnlyHint and is left unexplained — the description does not clarify whether the import persists anything.

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 compact sentence with no filler, which is good, but the compression has been taken too far — the key operational detail (which plugin/operation combinations exist) is absent rather than merely concise. Front-loading is fine; the problem is omission, not length.

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

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

An output schema exists, so return values need not be described. For a three-required-parameter dispatcher with 0% schema documentation, though, the description leaves the agent unable to invoke the tool correctly, and no sibling tool provides a fallback path since no other keywordmoves_* tools are listed.

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 there are four parameters, including three required ones (plugin, operation, inputs) plus an untyped options bag. The description supplies no valid values, no format hints, and no relationship between plugin and operation, so the agent has no way to construct a correct call from the definition 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 names two concrete capabilities (phrase extraction and reviewed evidence import) but frames them through an opaque generic dispatcher, so the agent still cannot tell what 'plugin' or 'operation' values actually select. 'Run' plus a compound resource phrase gives partial differentiation, but the tool's real scope is only half revealed.

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 'without network collection' implicitly excludes remote/online workflows, which is the only usage signal present. There is no statement of when to pick phrase extraction versus evidence import, no prerequisites, and no mention of what 'bounded' or 'reviewed' constrain in practice.

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=false and openWorldHint=true, and the description adds meaningful context beyond them: the call returns a retained background job rather than completing inline, and the base effects are write/download/network with conditional inference/download effects depending on the component. It stops short of saying what happens on a failed or partial download, but the async and effect disclosure is genuinely useful.

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, and the action is front-loaded ahead of the follow-up polling instruction and the effect disclosure. Nothing is redundant with 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?

An output schema exists, so return values need no prose, and the description still usefully flags the async job model. For a network-touching mutation with nested arguments, the remaining gap is failure/permission behavior and the unexplained 'name' 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?

Schema coverage is 50%: only allow_downloads carries a description, and 'name' has no textual explanation, only regex/length constraints. The description's word 'Explicitly' hints at the required opt-in download authorization, but it does not explain name format, uniqueness, or that allow_downloads is pinned to true, so it only marginally compensates for the coverage 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?

States a specific verb and resource: 'provision a named canonical plugin's model'. That is concrete enough to distinguish it from read-only siblings like likenessforge_models and likenessforge_plugins, though 'canonical plugin' is jargon the agent must infer, and the name's 'download' framing versus the description's 'provision' framing is a minor mismatch.

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

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

Gives the follow-up workflow explicitly ('poll danceflow_job_status') and points to danceflow_component for conditional effects, which is real usage guidance. It never says when to choose this over likenessforge_models or likenessforge_plugins, nor any precondition beyond the download authorization implied by 'Explicitly'.

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?

Goes well beyond the annotations: it discloses that the operation returns a retained background job, enumerates base effect flags (write, inference, download, network), and flags that inference/download effects are conditional and should be verified via danceflow_component. This meaningfully informs the agent about statefulness and side effects that readOnlyHint=false and openWorldHint=true 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?

Three compact sentences, front-loaded with the action, then follow-up routing, then effect flags. Little wasted wording, though the effect-flag sentence is terse and could be clearer about which flags are always versus conditionally active.

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 that an output schema exists (so return values needn't be explained), the description covers the essential background-job/polling model and effect disclosure. It is complete enough to invoke correctly, with only minor gaps around detector selection and input parameter meaning.

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?

At 50% schema coverage, the description adds some meaning by naming the 'selected canonical detector' concept, but it does not explain image vs. preview inputs or the detector selection logic that the schema leaves undocumented. It partially compensates but leaves gaps for the image/preview 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?

States a specific verb+resource ('Detect and index faces') plus the mechanism ('selected canonical detector'), which is enough to distinguish it from training-oriented siblings like likenessforge_train_lora. It does not explicitly contrast with sibling tools, keeping it 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?

Gives follow-up routing ('poll danceflow_job_status') and points to danceflow_component for conditional effects, which is useful context. However it never states when to choose this tool over alternative face/LoRA workflows or what preconditions (e.g. model availability) apply.

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 it discloses that no weights are downloaded, that a retained background job is returned, and which effect flags apply by default (write) versus conditionally (inference/download). This explains why readOnlyHint is false for an otherwise list-like operation, which the annotations alone would leave puzzling.

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, front-loaded with the operation and its key constraint, then the async return behavior, then the effect-flag caveat. No filler and no restatement of the 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?

For a tool with a nested permissions object, an output schema, and background-job semantics, the description covers purpose, async behavior, and follow-up sufficiently. Missing details like result ordering or what a "model-backed plugin" contains are tolerable given the output schema handles returns.

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

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

Schema coverage is only 50%, but the description compensates by telling the agent which permission flags this call should acknowledge (write as base, inference/download inspectable via danceflow_component). The empty, required "arguments" object remains unexplained, a minor 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?

"List model-backed plugins without downloading weights" gives a specific verb and resource, and the qualifier distinguishes it from the weight-fetching sibling (likenessforge_download_model). It stops short of naming likenessforge_plugins, so an agent must infer how this differs from the generic plugin listing.

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 follow-up routing (poll danceflow_job_status, inspect danceflow_component for conditional effects) which implies the intended workflow, but it never states when to choose this tool over likenessforge_plugins or danceflow_search, nor any prerequisites or exclusions.

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

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

Adds behavior the annotations cannot express: the call returns a retained background job rather than an inline list, so the agent must poll; the base write effect flag is required; and inference/download effects are conditional and must be checked via danceflow_component. This is consistent with readOnlyHint=false and idempotentHint=false and materially changes how an agent should sequence the call.

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

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

Four short sentences, front-loaded with what the tool lists, then the async consequence, then effect-flag guidance. Every sentence carries operational information; only the 'Base effect flags' phrasing is slightly terse/opaque.

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

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

An output schema exists so return shape needn't be explained, and the description covers the two things an agent would otherwise get wrong: that this is an async job needing polling, and that effects depend on permissions. Minor gap is that it doesn't clarify how installed plugins relate to the models listing 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 the permissions object carrying its own description ('Acknowledge only effects authorized for this operation'). The description contributes one useful piece of meaning, the base write flag, but says nothing about the network/download/training/inference/publication flags or the empty arguments object, so it only partially compensates for the coverage 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?

States a specific verb and resource: lists installed plugin metadata across four named plugin categories (detector, segmenter, modifier, trainer). That is enough to distinguish it from likenessforge_models (model catalogue) without opening schemas, though the description never explicitly names that sibling contrast.

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

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

Gives concrete post-call routing: poll danceflow_job_status for the returned job, and consult danceflow_component for conditional inference/download effects. However it gives no guidance on when to choose this tool versus likenessforge_models or likenessforge_capabilities, so the selection guidance is inferred rather than stated.

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 the call is asynchronous and returns a retained background job, and it enumerates the effect categories (write, inference, download, network) while pointing at danceflow_component for conditional effects and noting on-demand model weight downloads. This is meaningful disclosure for a non-idempotent, open-world operation. It stops short of saying what files land in the output path or whether an interrupted job leaves partial artifacts.

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

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

Three short sentences with the capability and its scope stated first, followed by the async contract and effect metadata. The effect-flag sentence is compressed to the point of being cryptic, but nothing is wasted or repeated.

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 output schema removes the need to describe return values, and the polling pointer covers the async lifecycle. However, for a tool with ten nested inputs and a permissions gate, an agent is left without any guidance on the format of images, output, or trigger, or on which permission flags must be acknowledged for this specific operation.

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 no meaning for any of the roughly ten nested arguments — face, images, output, trigger, background, detector, segmenter, and trainer all go unexplained, and the permissions object's flags are only gestured at via "Base effect flags". With the schema's prose coverage at 50% and concentrated on a single boolean, the description does not compensate for the gap.

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

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

The description names a specific verb and resource ("Prepare authorized segmented face crops") and draws an explicit boundary against a sibling operation by stating it does so "without training a LoRA", which separates it from likenessforge_train_lora. It does not clarify how it relates to the closely named likenessforge_faces, which likely produces the input crops.

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 context is only implied: the phrase "without training a LoRA" signals this is a preprocessing step, but the description never states when to choose it over likenessforge_train_lora, likenessforge_faces, or likenessforge_train_wizard. It does supply a concrete follow-up instruction (poll danceflow_job_status), which is genuine workflow 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?

Beyond the annotations (which only declare non-readonly, open-world, non-idempotent, non-destructive), the description discloses that the call returns a retained background job rather than a finished artifact and names the polling tool, which is essential behavioral context. It also enumerates the effect classes (write, inference, download, network) and flags that some are conditional and discoverable via danceflow_component, usefully extending the permissions schema. It stops short of saying what happens on failure, how long jobs are retained, or that the model weights may be fetched at runtime beyond the effect flag list.

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, front-loaded sentences with no filler: the action, the return/async contract, and the effect profile. The effect list partially restates the permissions enum already in the schema, but it is cheap and signals which flags must be acknowledged, so it mostly 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?

An output schema exists, so return-value documentation is not required, and the description correctly covers the asynchronous job contract and the effect model. For a tool with a nested arguments object of this size and a required permissions acknowledgement, however, it leaves too much unexplained — the bulk of tunable parameters and the mechanics of the permission gate remain undocumented.

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 50% and only one nested field (allow_downloads) carries an inline description, yet the description explains none of the roughly twenty sub-parameters (lora, seed, steps, guidance, feather, detector, segmenter, low_vram, references, crop_margin, etc.). It only hints at the face selector via "explicitly selected face", which is arguably in tension with that field's "largest" default, and says nothing about the required output or image paths.

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 pairs a specific verb ("Repair") with a bounded resource ("one explicitly selected face") and names the execution path ("the canonical workflow"), so an agent understands this is a targeted face-repair operation rather than a generic pipeline run. It does not, however, distinguish itself from the nearby sibling likenessforge_repair_wizard, leaving the agent to infer which of the two repair entry points is correct.

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 "one explicitly selected face" implies a precondition (a face must be chosen), and pointing at danceflow_component for conditional effects is genuine routing guidance. But there is no statement of when to prefer this over likenessforge_repair_wizard, no prerequisites, and no guidance on the required permissions acknowledgement beyond an oblique hint.

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 non-read-only, non-destructive, open-world, non-idempotent. The description adds material context beyond that: the call returns a retained background job rather than results, and the base effect flags are write, inference, download, and network. It stops short of explaining what a 'bounded repair comparison' actually writes or what the manifest contains, but the async and effect disclosure is substantive.

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

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

Four compact sentences with the purpose front-loaded and no filler. The effect-flag and component-routing sentences are terse but each carries operational meaning, though the flag list reads slightly like internal metadata dump.

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 presence of an output schema means return values need not be described, and the job lifecycle plus effect flags are covered. However, for a tool whose real complexity lives in an undocumented fourteen-field argument object, the description does not give the agent enough to populate a correct call beyond the required trio.

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's nested argument object holds roughly fourteen properties (image, output, face, preset, lora, prompt, references, low_vram, etc.) with virtually no per-field descriptions; only allow_downloads and permissions carry text. The macro description mentions no parameter at all, so nothing narrows what 'image', 'output', 'face', or 'preset' mean for this specific operation.

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

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

The description gives a concrete verb-plus-resource: 'Create a bounded canonical repair comparison and evidence manifest.' That is a specific, distinguishable artifact rather than a restatement of the name. It never contrasts with the sibling likenessforge_repair, so an agent must infer which repair path applies.

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 genuinely useful follow-up instruction ('poll danceflow_job_status') and routes the agent to danceflow_component for conditional effects, which is real when-to-do guidance. It does not state when to choose this wizard over likenessforge_repair or likenessforge_train_wizard, so the primary selection decision is left implicit.

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 only tell the agent this is a non-idempotent, open-world writer. The description adds real behavioral context beyond that: the call returns a retained background job that must be polled, the base effect set (write, inference, download, network, training), and that inference/download effects can vary by component. It still omits failure behavior and whether an existing output is overwritten.

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 tight sentences, front-loaded with purpose, then return behavior, then effect flags. The effect-flag enumeration is compact, though 'Inspect danceflow_component for conditional inference/download effects' reads as jargon that requires already knowing the sibling.

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

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

An output schema exists, so return values need no explanation, and the description correctly covers the async job lifecycle and the permission/effect model, which are the two things an agent could not learn from annotations alone. The gap is the many training hyperparameters, none of which are addressed despite the thin schema coverage.

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 50% and only the two authorization booleans plus the permissions object carry descriptions. The description adds nothing about rank, steps, learning_rate, trigger, images, output, face, trainer, segmenter, detector, low_vram, or background, which are the settings an agent actually has to choose. 'Bounded settings' does not substitute for explaining any of them.

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 ('Train one explicitly authorized identity LoRA') plus scope qualifiers ('bounded settings', 'explicitly authorized'). It implicitly contrasts with likenessforge_train_wizard through the 'explicitly authorized / bounded' framing, but never names that sibling, so an agent still has to infer which entry point 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?

Gives useful post-call routing ('poll danceflow_job_status') and a conditional-effects pointer ('inspect danceflow_component for conditional inference/download effects'). It does not say when to use this versus likenessforge_train_wizard or likenessforge_prepare_training, nor what prerequisites must be satisfied before training.

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

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

With readOnlyHint=false, openWorldHint=true and idempotentHint=false already declared, the description adds real value: it discloses that the call returns a retained background job (rather than blocking) and enumerates the effect flags (write, inference, download, network, training) the agent must acknowledge. It does not say whether repeated invocations create duplicate jobs or what gets written to disk, which keeps it short of a 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?

Three short sentences, front-loaded with the action and immediately followed by the async contract and effect disclosure; nothing is padding. It is somewhat jargon-dense ('bounded candidate LoRAs', 'fixed holdout repairs') without unpacking the terms.

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?

Because an output schema exists, return values needn't be described, and the async job + polling story is covered. Still missing for a multi-effect, non-idempotent training operation: the prerequisite relationship to likenessforge_prepare_training, the distinction from likenessforge_train_lora, and where artifacts land.

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 50% and most of the ~17 nested arguments (images, output, trigger, validation, preset, face, seed, trainer, detector, low_vram, segmenter, modifier, prompt) carry no description at all. The description explains none of these — notably the quick/balanced/thorough preset and the 'fixed holdout' validation input — so it fails to compensate for the coverage gap.

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

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

The description names a specific verb and resource: training bounded candidate LoRAs plus a fixed holdout comparison. That is clearly distinguishable from generic siblings such as danceflow_search, but it never states how this 'wizard' differs from likenessforge_train_lora or likenessforge_prepare_training, so sibling differentiation is only partial.

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 one concrete follow-up instruction ('poll danceflow_job_status') and one routing hint ('Inspect danceflow_component for conditional inference/download effects'), which is genuine usage guidance for the async flow. However, there is no statement of when to choose this over likenessforge_train_lora or the prepare/repair wizard siblings, nor any prerequisites such as needing a prepared dataset.

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 and openWorldHint=false, so safety and locality are covered. The description adds one genuinely useful trait beyond that: the service must already be running and is reached over loopback, meaning the tool will not start or provision anything. It does not say what happens when the service is unreachable, which is the main failure mode an agent would want to know.

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 the action and the prerequisite front-loaded and no filler. Nothing can be trimmed without losing 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?

With no parameters and an output schema that documents the returned version/model data, the description does not need to explain return values. It is nearly complete for such a simple probe; the only missing piece is expected behavior on a down or unreachable service.

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 the established baseline of 4 applies; there is nothing for the description to disambiguate. The description does not introduce any phantom inputs.

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

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

States a specific verb (read) and specific resources (version and model profiles) from a named service, which is more informative than a bare 'health' label. It does not explicitly contrast with the other PixelCue siblings (pixelcue_keywords, pixelcue_visual_analysis), so the agent must infer the boundary itself.

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 'already-running loopback PixelCue service' implies a prerequisite and hints this is a preflight/inspection call before real work, but it never states when to call it versus pixelcue_keywords or the doctor/info siblings like stemlab_doctor or thumbmoves_backend_info. Usage is implied rather than directed.

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 annotations declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is structured already. The description adds real value with "explicit opt-in permits inference/model caching," disclosing that inference and caching are gated behind allow_inference rather than automatic. However, it does not say where tags are written (file metadata vs sidecar) or what happens when inference is declined, which matters for a non-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?

A single front-loaded sentence with no filler and zero redundancy. Its brevity is arguably a liability, but nothing in it wastes 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?

An output schema exists, so return values need not be described, and annotations cover the safety signal. Still, for a mutating three-parameter tool with zero schema coverage, the definition leaves key operational questions open: tag destination, behavior when opt-in is false, and model selection tradeoffs.

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 no parameter has an enum, so the description carries the full burden. It maps loosely to all three: "explicit opt-in" gestures at allow_inference, "model caching" at model, and "one local media file" at path — but it never explains accepted model values, defaults, or the behavioral difference between allow_inference true and false. The hints are suggestive rather than instructive.

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

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

The description gives a specific verb+resource: "Tag one local media file through PixelCue," with an explicit scope of a single local file. This lets an agent distinguish it from batch or analysis siblings such as pixelcue_visual_analysis. It falls short of 5 because "tag" is never elaborated as keyword extraction, despite the tool name.

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 when-to-use, when-not-to-use, or alternative routing guidance against the many sibling tools (pixelcue_visual_analysis, pixelcue_health, keywordmoves_run). The "one local media file" phrasing implies single-file local input only, but this is inference rather than stated 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 declare readOnlyHint=true and openWorldHint=false, so the safety and network profile is partially covered. The description does add real value beyond that by stating "no downloads" and that model inference is cached and opt-in, which tells the agent it will not fetch remote assets. It still omits what happens when inference is skipped or what the analysis output contains, so the addition is useful but partial.

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 semicolon-delimited sentence that front-loads the core action and keeps the constraints compact with zero filler. It is arguably over-compressed, but every clause conveys distinct information.

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

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

An output schema and annotations exist, so return values and safety need not be restated. Still, for a tool with three undocumented parameters and no sibling differentiation, the description leaves the agent guessing about what "measure" yields and when this beats pixelcue_keywords.

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% across three parameters, so the description carries the full burden. It clarifies that the path targets one image and that inference (allow_inference) is opt-in, but the "models" array is never explained and there is no hint about accepted path formats or model identifiers, leaving a meaningful gap for a 0%-coverage 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?

"Measure one image through PixelCue" gives a verb and a resource and pins the scope to a single image, which distinguishes it from batch-style siblings. However, "measure" is vague about what is actually produced (metrics? keywords? embeddings?), and nothing distinguishes it from pixelcue_keywords or pixelcue_health beyond the singular image scope.

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 never states when to use this tool versus pixelcue_keywords or pixelcue_health, nor what input conditions are required (local file, supported formats). The only conditional guidance is "optional cached model inference requires opt-in," which describes a parameter gate rather than tool selection.

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 destructive, non-idempotent, open-world behavior, but the description adds genuinely new facts: the operation is asynchronous and returns a retained job handle, that write is the base effect flag, and that inference/download effects are conditional and gated by what danceflow_component reports. That async-and-gated model is exactly what an agent needs before invoking a destructive tool, though it does not say what gets overwritten or what permissions must be acknowledged.

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 zero filler, and the crucial lifecycle fact (returns a job; poll danceflow_job_status) is placed early. Density is high, though a couple of compressed phrases edge toward opaque shorthand.

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 output schema exists, so return values need not be described, and the description covers the effect-gating model and async pattern that are the main hazards. Against a tool with many nested, undocumented parameters and several near-neighbor preset tools, it still leaves the agent guessing about required inputs and sibling selection.

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 only 50% schema description coverage and a deeply nested arguments object (captures, output, budget, models, semantic_edge, allow_download, keyword_models, device, paths), the description supplies no parameter meaning at all — it never explains that captures/output are required inputs or what budget bounds. The only faint signal is 'conditional inference/download effects', which gestures at allow_download and the permissions object without clarifying either.

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 verb and resource ('Describe captured presets') plus the analytical basis ('temporal evidence and a bounded semantic budget'), so the general purpose is inferable. However, 'temporal evidence' and 'bounded semantic budget' are internal jargon, and nothing distinguishes this from siblings prismmoves_preset_reindex or prismmoves_preset_legacy, which an agent would plausibly confuse it with.

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 useful lifecycle guidance — the call returns a retained background job and the agent must poll danceflow_job_status — and directs the agent to danceflow_component to check conditional inference/download effects. It gives no when-to-use/when-not guidance relative to the other preset tools, so selection among siblings 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?

Adds real context beyond the annotations: the call is asynchronous and returns a background job handle, and the base effect is a write with inference/download effects being conditional on component inspection. This is exactly the kind of effect disclosure a caller needs, and it is consistent with readOnlyHint=false and destructiveHint=false.

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, front-loaded with purpose before mechanics. The telegraphic 'Base effect flags: write' phrasing is slightly clipped but every sentence carries information.

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

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

An output schema exists, so return shape needn't be described, and the async/job-handle behavior is covered. However, for a tool with two required nested arguments and a permissions object, the description omits what the primary inputs mean and what the replay produces.

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 description never explains 'reports', 'output', or 'budget'. It does add meaning to the permissions sub-flags by identifying write as the base effect and inference/download as conditional, which partially compensates but leaves the core arguments opaque.

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: replaying retained legacy preset reports without new model inference. The 'legacy' and 'retained' qualifiers implicitly separate it from prismmoves_preset_analyse and prismmoves_preset_reindex, though no sibling is named 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?

Gives post-call guidance (poll danceflow_job_status, inspect danceflow_component for conditional effects) but never states when to choose this over the sibling preset tools. Usage is implied by the 'legacy retained reports' framing rather than declared.

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 non-idempotency; the description adds that a retained background job is returned, that polling is required, and that inference/download effects may be conditionally triggered. It still does not warn what the rebuild destroys in the existing index, which is the key risk for a destructive 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?

Three tight sentences with the action front-loaded, followed by async behavior, then effect flags. No wasted prose, though 'Base effect flags: write' is terse to the point of being cryptic outside this tool family.

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

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

An output schema exists, so return values need not be spelled out, and the description still covers the async job contract and conditional permission effects. For a destructive background tool with nested permissions, the main missing piece is the scope of what gets overwritten.

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 phrase 'for an existing report directory' gives the required `output` argument meaning it otherwise lacks, and the effect-flag sentence maps to the write/inference/download entries in the permissions object. The flag semantics remain largely deferred to danceflow_component rather than explained 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?

States a specific verb and resource: 'Rebuild the canonical gallery index for an existing report directory.' This is clearly distinct from prismmoves_preset_analyse and prismmoves_preset_legacy by naming the index rebuild action, though it never explicitly routes the agent away from those 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?

'For an existing report directory' implies the prerequisite, and it names the follow-up tool (danceflow_job_status) plus a conditional dependency check (danceflow_component). It does not state when to choose this over the sibling preset tools, so the guidance is workflow-oriented rather than selection-oriented.

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 the tool writes reports, returns a retained background job, and requires polling danceflow_job_status. It also clarifies base write effects and points to danceflow_component for conditional inference/download effects, though it does not elaborate on output retention or authorization details.

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 short and front-loads the main purpose, report formats, and background-job behavior. The effect-flag sentences are terse but each contributes useful operational context.

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?

It covers the core workflow, async polling, and effect inspection, which is important for this complex tool. Still, for a nested schema with many configuration parameters, it omits substantial call-shaping information even though the annotations and output schema reduce some of the burden.

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 only clearly maps to images and output, leaving role, device, models, lineage, max_edge, background, models_dir, pixelcue_url, allow_download, pixelcue_models, and permissions unexplained. With schema description coverage at 50% and a large nested arguments object, this does not compensate for the missing parameter 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 states a specific verb and resource: profile bounded local images and write evidence-labelled reports in named formats. It is clear but does not distinguish this tool from nearby image-analysis siblings such as pixelcue_visual_analysis or rastermoves_* tools.

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

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

It gives post-call workflow guidance by saying to poll danceflow_job_status and to inspect danceflow_component for conditional inference/download effects. However, it does not state when to choose this tool over other image-profiling or visual-analysis siblings, nor does it give when-not-to-use 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?

The annotations declare a non-read-only, non-idempotent operation, and the description adds meaningful context by stating that it returns a retained background job and that callers should poll danceflow_job_status. It also explains that base effects are none while conditional inference/download effects are described in danceflow_component, which goes beyond the 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 short, front-loaded, and free of filler. The sentences are terse and somewhat fragmented, but every sentence contributes operational 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?

Given an output schema and annotations, the description covers the main behavior an agent needs: what is inspected, that a retained job is returned, and how to poll it. It is slightly incomplete on sibling selection and concrete permission handling, but broadly adequate for this diagnostic tool.

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

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

The schema has only two top-level parameters and 50% description coverage; the permissions object is already documented in the schema. The description adds conceptual help about effect flags and conditional effects, but it does not explain the empty arguments object or give concrete permission-usage guidance.

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: inspecting installed runtime versions and available devices. It is clear enough to distinguish a diagnostic tool from model/download/render siblings, though it does not explicitly name how it differs from nearby tools such as rastermoves_info.

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 useful follow-up guidance: the call returns a retained background job and should be polled via danceflow_job_status. However, it does not say when to choose rastermoves_doctor instead of sibling diagnostics like rastermoves_info, stemlab_doctor, or pixelcue_health.

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 destructive, open-world, non-idempotent behavior, but the description adds real value on top: it names the base effect flags (write, download, network) and warns that inference/download effects may be conditional and should be checked via danceflow_component. It also discloses the asynchronous job contract, which annotations cannot express. It omits what a bad or partial download does to the cache and whether strict_checksums failures roll back.

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 compact sentences, front-loaded with the action, then the return contract, then effect flags, then a conditional caveat. Each sentence carries distinct information and nothing is repeated. The telegraphic 'Base effect flags:' phrasing is slightly terse but not wasteful.

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 destructive, asynchronous download tool with an output schema available, the description covers the action, the async follow-up, and the effect/permission model. The main gaps are cache-location defaults and failure behavior, which matter for a destructive write to disk. It is otherwise sufficient to invoke 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 only 50%, and the description only implicitly maps to the inputs by mentioning 'selected model' and 'configured cache'. Required arguments like allow_downloads (a const true authorization gate after licence review) and strict_checksums are not explained in the description, though the schema itself carries a description for allow_downloads. Naming the effect flags gives partial help with the permissions object, so this lands at baseline rather than below it.

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: 'Explicitly download one selected model's weights to the configured cache.' That is far more precise than the name alone and tells the agent this is a single-model fetch rather than a bulk sync. It does not, however, distinguish itself from the close sibling rastermoves_download_refiner, leaving the agent to guess which download tool applies.

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

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

Gives clear downstream context: the call returns a retained background job and the agent should poll danceflow_job_status. The adverb 'Explicitly' and the mention of inspecting danceflow_component imply a review step before invoking. It stops short of stating exclusions, such as when to prefer rastermoves_sync or rastermoves_download_refiner 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?

Goes beyond the annotations by naming the concrete effect flags (write, download, network) an agent must acknowledge, disclosing that the call spawns a retained background job rather than returning a result, and flagging that inference/download effects are conditional and must be inspected. The destructiveHint=true annotation is not directly explained, but the disclosure of write/download effects is consistent with it rather than contradicting it.

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

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

Four short, front-loaded sentences with no filler; the core action leads and the operational follow-ups trail. The 'Base effect flags' line is telegraphic in a way that is dense but still parseable for an agent.

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 returns a job handle, and an output schema plus the explicit 'poll danceflow_job_status' instruction make the return path clear. Given annotations already convey the safety profile, the main remaining gap is guidance on when this prefetch is preferable to rastermoves_download.

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 50%; only allow_downloads is documented in-schema. The word 'Explicitly' and the pinned-refiner phrasing hint at consent for downloads and at immutable pinned revisions, but cache_dir and strict_checksums receive no meaning from the description, and the two enum refiner values (sd15-tile, sdxl-tile) are never explained.

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: 'Explicitly prefetch one canonical pinned refiner,' which tells an agent this is a single-refiner prefetch rather than a general model download. It does not explicitly distinguish itself from the sibling rastermoves_download or rastermoves_sync, so the boundary is inferable rather than stated.

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

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

Gives useful downstream guidance ('poll danceflow_job_status') and a diagnostic path ('Inspect danceflow_component for conditional inference/download effects'), which covers the after-call flow. However, it never says when to choose this over rastermoves_download or rastermoves_refiners, so selection between sibling tools 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?

Goes well beyond the annotations by disclosing that this is asynchronous ("Returns a retained background job") and must be polled, and that effects are not fixed but conditional on inference/download per danceflow_component. It also names the base effect flag ("write"), which matches readOnlyHint=false and destructiveHint=true. The remaining gap is that destructiveHint=true is never explained — what the write/destructive component actually touches is left to the component check.

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

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

Four short, front-loaded clauses with no filler; the async-return warning and the sibling pointers come before any effect detail. The telegraphic phrasing ("Base effect flags: write", bare "poll danceflow_job_status") is dense but readable, costing a little 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?

An output schema exists, so return-value detail is not required, and the async/polling contract is covered. But this is a nested-object tool with a permissions gate and a destructive hint, and the description never explains the authorization relationship between permissions.write and the "write" effect flag, nor what cache_dir changes — material gaps for a destructive-classified 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?

With 50% schema coverage, the description does add one important constraint: the model must already be known locally, i.e. no implicit fetch occurs. However, cache_dir is never mentioned despite carrying an 8192-char bound, and the permissions object (whose schema text warns flags are "not independent authority") is only obliquely referenced via "Base effect flags: write", so the agent must infer that permissions.write must be acknowledged.

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?

Names a specific verb+resource ("Inspect one locally known model") and immediately scopes it against the catalogue family by stating it does so "without fetching catalogue or weights", which an agent can contrast with rastermoves_models/rastermoves_download. It stops short of naming the sibling to use for catalogue lookups, so the differentiation is implied rather than 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?

Implies the use case (pre-flight inspection of an already-present model) and gives two forward pointers: poll danceflow_job_status for the returned job, and check danceflow_component for conditional effects. It never states when *not* to use it (e.g. when the model is not local, or when rastermoves_models/rastermoves_doctor is the correct call), so selection guidance remains inferential.

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 annotations already declare a non-read-only, destructive operation, and the description adds useful behavioral context: it returns a retained background job, requires polling, has a base write effect flag, and may have conditional inference/download effects. It does not detail what is destroyed or list permission prerequisites, but it adds substantive information beyond the 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 three compact sentences and front-loads the primary purpose before operational details. There is little waste, though the phrase 'retain licence metadata' could be clearer about whether metadata is stored, returned, or both.

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 async job model, polling target, and effect flags, which are important for this destructive background operation. It remains incomplete regarding how to choose between this and sibling model tools, and it does not explain most of the nested argument parameters, though the output schema reduces the need to describe return values.

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

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

Schema coverage is 50%, and the nested arguments fields (tag, query, scale, cache_dir, architecture) have no descriptions. The description only maps loosely to the permissions effect flags by mentioning base write and conditional inference/download effects, leaving most parameter meaning unexplained 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 description states a specific verb and resource: search locally available model manifests and retain licence metadata. It is clearer than a tautology, but it does not explicitly differentiate this tool from nearby model-related siblings such as rastermoves_plan_all_models or stemlab_models.

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 procedural usage guidance after invocation by saying to poll danceflow_job_status and inspect danceflow_component for conditional effects. However, it does not state when this tool should be chosen over sibling search, planning, or download tools, so the usage guidance is implied rather than explicit.

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

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

Adds real context beyond the annotations: the call returns a retained background job rather than a synchronous payload, and the 'Base effect flags: write' line reconciles why readOnlyHint=false and destructiveHint=true on what is nominally a print/plan operation. It also tells the agent that conditional inference/download effects exist and must be checked. Not a contradiction – it is an explanation of the annotation profile.

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?

Front-loaded with purpose first, then async behavior, then effect flags, then follow-up tools. Dense and telegraphic but every sentence carries information; the 'Base effect flags: write' fragment is terse to the point of being cryptic.

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?

Return values are covered by the output schema and the async job pattern plus effect flags are well disclosed. However, for a two-parameter tool whose whole job is planning around input/output paths, the meaning and constraints of those arguments are left entirely unaddressed.

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 50%, and the undocumented half is the important part: input, output and cache_dir carry no descriptions in the schema, and the description says nothing about what these paths mean or how they shape the plan. Only the permissions object is self-documented, so the description fails to compensate for the 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?

States a specific verb and resource ('Print the canonical all-model output plan') and immediately scopes it as a dry-run that does not download or run models. That negative scope separates it from siblings like rastermoves_download, rastermoves_upscale and rastermoves_plan_refinement, though no sibling is named 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?

Makes the use case clear (generate the plan before committing to model effects) and routes the agent forward: 'poll danceflow_job_status' and 'Inspect danceflow_component for conditional inference/download effects.' Lacks an explicit contrast against rastermoves_plan_refinement, so it is strong but not exhaustive.

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?

It adds real behavior beyond annotations: no images are written, a retained background job is returned and must be polled, and base effect flags are "none" with conditional inference/download effects deferred to danceflow_component. That is useful, but describing the operation as effect-free while annotations set destructiveHint=true leaves the agent guessing about the actual destructive surface, and the state-mutating nature of spawning a retained job is not explained.

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

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

Four short, front-loaded fragments with no filler; the key constraint (no image writes) leads. The telegraphic style ("Base effect flags: none") is terse to the point of being cryptic, 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?

An output schema exists so return values need not be described, but for a tool with ~30 nested arguments, a permissions gate, and a destructive annotation, this four-line description is far too thin. It omits the relationship between permissions flags and the conditional effects it alludes to, which is the single most important thing an agent needs to call it safely.

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 says nothing about the parameters — not the required input/output, not the refiner/tile/steps/guidance/strength knobs, and not the permissions object whose flags directly determine whether conditional effects fire. With a large nested arguments object and only 50% schema coverage, the description does not compensate for the undocumented 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?

"Print the validated canonical refinement plan" does convey this is a planning/dry-run tool rather than an image-writing one, which separates it from rastermoves_refine. But "validated canonical refinement plan" is jargon — the description never says what is being planned over (input/output/refiner settings) or what the plan contains, so the agent must infer purpose from the tool name and schema.

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

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

It implies a preview/plan step and gives explicit follow-up routing ("poll danceflow_job_status") plus a pointer to danceflow_component for conditional effects. However it never states when to choose this over rastermoves_refine or rastermoves_plan_all_models, and gives no prerequisites or exclusion 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?

Beyond the annotations, the description discloses that this is an asynchronous operation returning a retained background job and that the agent must poll danceflow_job_status, which is not derivable from the hints. It also declares the effect profile (write, inference) and points to danceflow_component for conditional inference/download effects, adding real context on permissions. It does not explain the destructiveHint=true consequence (e.g., overwriting an existing output file), which is the remaining gap.

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, front-loaded sentences with no filler: purpose, then return/polling behavior, then permission flags. Dense terminology ('retained baselines', 'retained background job') is slightly opaque but each sentence carries distinct information.

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

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

An output schema exists, so return-value explanation is unnecessary, and the async/polling model plus effect flags are covered. For a destructive, async tool with a large nested parameter surface, though, it omits overwrite semantics and prerequisites such as having the refiner weights cached or downloaded (rastermoves_download_refiner). Adequate but with clear gaps.

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 nested 'arguments' object contains roughly 28 properties with essentially no schema descriptions, and the description explains none of them — no meaning for strength, tile, overlap, refiner, resume, or max_output_mp. Terms like 'cached weights' and 'retained baselines' gesture at cache_dir/resume behavior but do not define them. With 50% schema coverage and a large undocumented parameter surface, the description fails to compensate.

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 ('Refine images') plus a scoping constraint ('at unchanged dimensions') that implicitly separates it from rastermoves_upscale in the sibling list. It also names the follow-up tool (danceflow_job_status) and the introspection tool (danceflow_component), so the agent can place the tool in a workflow. It stops short of naming rastermoves_upscale or rastermoves_plan_refinement explicitly as the 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 'poll danceflow_job_status' sentence gives a concrete post-invocation step, and 'unchanged dimensions' hints at when this is preferred over upscaling. However, there is no explicit when-to-use/when-not guidance against the many sibling tools (rastermoves_upscale, rastermoves_plan_refinement, rastermoves_refiners), so selection still relies on 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?

The annotations declare readOnlyHint=false on a tool that sounds like a list operation, and the description explains why: it "Returns a retained background job" that must be polled, so the non-read-only hint is accounted for. It also discloses the effect posture ("Base effect flags: none") and where conditional effects live, which is context annotations cannot carry.

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

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

Four short sentences, front-loaded with the action and scope before the follow-up routing. The telegraphic "Base effect flags: none" is terse but earns its place; nothing is padded.

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

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

An output schema exists so return values need no prose, and the description covers the non-obvious lifecycle (retained job, poll danceflow_job_status) plus the effect/permission posture. For a two-parameter listing tool that spawns a job, an agent has what it needs to call it and follow up correctly.

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