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

Annotations already flag destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description earns credit for disclosing what actually gets terminated (the spawned browser/ffmpeg process) and what survives (files already written), which is real context an agent cannot read off the annotations. It stops short of saying whether the job lands in a cancelled state or how cancelling a completed job behaves.

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

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

Two short sentences with zero filler; the destructive effect is front-loaded and the side-effect caveat follows. Nothing could be removed 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 one fully documented parameter and an output schema present, the description needs only to explain the action and its side effects, which it does. The minor gap is terminal state and error behavior for an already-finished or unknown job_id.

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

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

Schema coverage is 100% and the single job_id parameter is documented in the schema as coming from a makersmcp tool return. The description adds no further meaning about the identifier, so the baseline 3 applies.

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

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

States a specific verb and resource ("Stops a running job") and adds the concrete effect ("the browser or ffmpeg it started"), which is far more informative than the title's restatement. The verb alone separates it from list_jobs and wait_for_job, so an agent can pick it without opening the 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?

Usage is only implied: the note that already-saved files persist hints at a trade-off, but there is no explicit when-to-use vs. wait_for_job, no statement about cancelling a job that already finished, and no preconditions. An agent can infer the purpose but gets no routing guidance.

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

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

The annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior. The description adds useful behavioral context beyond that: it lists exactly what gets inspected (kits, versions, Chrome, ffmpeg, and file save location), which tells an agent this is a passive diagnostic that probes the local environment.

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 two sentences with no waste. The first sentence front-loads the information the tool returns, and the second gives the trigger condition.

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

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

For a zero-parameter diagnostic, the description names the categories of information it returns. However, there is no output schema, so the description must cover return behavior, and it does not say how the results are presented (such as a status summary or a report) or whether failures are surfaced as errors. It is adequate, but it leaves some ambiguity about the shape of the response.

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

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

The tool takes no parameters, so there is nothing for the description to clarify about argument meaning. The baseline score for a zero-parameter tool applies.

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

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

The description uses the specific verb 'Shows' with a concrete inventory: available kits and their versions, Chrome/ffmpeg detection, and the save location for files. That is clearly distinguishable from sibling tools like list_jobs or make_brand_kit, which handle job state and creation rather than environment diagnostics.

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

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

The description gives an explicit trigger: 'Use it when a tool is missing or a kit fails to start.' This is good diagnostic guidance, but it does not mention alternatives or exclusion cases, such as when waiting on an existing job would be the better first move rather than re-checking setup.

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

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

Annotations declare readOnlyHint=false and destructiveHint=false, consistent with a tool that writes files. The description adds valuable behavioral detail beyond annotations: it specifies the exact output files (CHECK.md, check.json, sheet.png, wave.png) and clarifies that a failed check is a normal outcome, not an error. It does not describe overwrite behavior or rate limits, but the core side effects are disclosed.

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

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

The description is front-loaded with the core action and measurements, then lists outputs and usage guidance. It is dense but well-organized; the parenthetical version/machine note is minor and does not distract. Every sentence contributes useful 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 the presence of an output schema and 100% schema description coverage, the description need not explain return values. It covers what the tool measures, what files it writes, and how to interpret failures, which is sufficient for an agent to invoke it correctly. The only minor gap is explicit guidance on when to run it relative to the render step.

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

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

Schema description coverage is 100%, so the input schema already explains every parameter in detail. The description adds little semantic meaning beyond what the schema provides, aside from implicitly linking the 'cues' parameter to the beat-checking behavior. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('Checks') and resource ('any rendered video') and enumerates the exact measurements it performs: size, frame rate, length, black/still/silent stretches, loudness, peaks, and beat-cut alignment. This clearly distinguishes it from siblings like render_launch_film or plan_launch_film.

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 context that this is for rendered videos and that a failed check is a normal result, directing the agent to read CHECK.md for fixes. However, it does not explicitly name when to use this versus alternatives (e.g., after render_launch_film), leaving that to inference from the tool name and sibling set.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that this is launch-film 0.2.0 data local to this machine. It does not add behavioral detail such as result shape or the job_id fallback, though those are partly covered by schema fields and 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?

The definition is a single front-loaded sentence with no filler. Parenthetical clauses carry the topic distinctions efficiently. The version and machine note is compact, though slightly incidental to tool selection.

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 only two parameters, full schema coverage, rich annotations, and an output schema, the description supplies enough context to select and call the tool. The wait_seconds/job_id behavior is left to the schema, which is reasonable. A minor gap is the absence of explicit guidance on result shape or when a job_id is returned.

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

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

Schema coverage is 100%, so the schema already documents both parameters. The description nonetheless adds meaning to the topic enum by explaining that 'looks' returns looks with suitable topics and 'types' returns scene types with their fields. That is useful semantic detail beyond the terse enum values.

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 and resource: it lists launch-film's looks and what each suits, or its scene types and their fields. The two topic branches are clearly distinguished. It does not explicitly differentiate itself from sibling pipeline tools like plan_launch_film or make_launch_film, but the reference-data nature is evident.

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 contexts: picking a look or editing film.json. That tells the agent when this tool is relevant. It stops short of naming alternatives or stating when not to use it, so it is not fully explicit about routing versus sibling 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 readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description usefully adds the completeness of the result set (everything since launch, including ended jobs) and that folders are attached. It does not disclose ordering, result size, or whether the listing is truncated, which matters for an unbounded history 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?

A single front-loaded sentence with no filler; the scope qualifiers (since launch, running or ended) and payload note (with folders) each carry information. Nothing is repeated from the title.

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

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

For a simple, parameterless read tool with full annotation coverage and no output schema, the description is nearly sufficient — it says what is enumerated and what comes back. The only gap is that it does not describe the shape of a job entry or how to handle a large history.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate beyond what the schema shows. Baseline for a no-parameter tool applies.

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

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

States a specific verb and resource ("Lists the jobs") and adds scope: jobs started since launch, whether running or ended, plus their folders. That is enough to distinguish it from the sibling job tools (wait_for_job, cancel_job), though those alternatives are never named.

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

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

Usage is only implied: an agent can infer this is the discovery/status-overview call before drilling into a specific job with wait_for_job or cancel_job. There is no explicit when-to-use or when-not-to-use statement, and no guidance on using the returned job identifiers with the sibling 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 declare it is a non-read-only, open-world, non-idempotent but non-destructive write operation. The description adds valuable behavioral detail beyond the annotations: it uses a headless browser, writes files into a folder, produces specific file formats and manifests, and includes optional app-store capture when the site links to apps. It does not discuss permissions, rate limits, or failure modes in depth, but the core behavior is well disclosed.

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 dense but front-loaded, opening with the core read-and-save behavior before listing outputs. It is longer than typical, but most sentences earn their place by naming concrete artifacts and file consumers. Minor repetition exists around the generated files, but it remains readable and purposeful.

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 complex tool with six parameters and an output schema, the description covers the main artifacts, output files, optional facts behavior, and the recommended reading order. It does not need to explain return values because an output schema exists, but it could say more about long-running job behavior and failure handling. Overall it is complete enough 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 coverage is 100%, so the schema already documents all six parameters thoroughly, including defaults and limits. The description reinforces what facts adds (claims with pages in FACTS.md) and what stores controls, but does not add much parameter meaning beyond the schema. A baseline 3 is appropriate when the schema does the heavy lifting.

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: it reads a website in a headless browser and saves its brand assets into one folder. The long artifact list (logos, colors, fonts, first screen, brand card, app store assets) makes clear this is a brand-kit extraction tool, not a launch-film or job tool.

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

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

It gives clear context for when to use the output (e.g., read BRAND.md before designing anything for that product) and explains the optional facts behavior. It does not explicitly name when to choose this over a sibling tool or when not to use it, but the purpose is narrow enough that the usage context is largely 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?

Beyond the annotations (readOnly=false, openWorld=true, idempotent=false, destructive=false), the description discloses the runtime stack (Chrome and ffmpeg on this machine), the latency ('rendering takes a few minutes'), that output is a non-AI factual rendering of the site, and that film.json is an editable intermediate plan. That is materially useful behavior an agent cannot get from the annotation block.

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 the outcome, then flows into mechanics, the film.json/render_launch_film follow-up, and latency. It is a single dense paragraph rather than a list, and the parenthetical build/version tag at the end is low-value, but no sentence is filler.

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

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

For a 12-parameter, long-running generative-ish job tool with an output schema, the description covers the artifact, its composition, the plan file, and expected runtime. It leaves the job_id/wait behavior to the wait_seconds schema entry, which is acceptable given coverage is complete and an output schema exists.

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

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

Schema description coverage is 100%, so every parameter (look, seconds, aspect, music, sfx, jobs, wait_seconds, brand, words) is already documented. The description adds only incidental context — the 20–40 second window and the musical/sfx layer — without explaining defaults or interactions between them; baseline 3 is appropriate when the schema carries the load.

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 artifact ('Makes a 20 to 40 second launch film from a product's own site') and enumerates what the film contains, so it is immediately distinguishable from render_launch_film (render only) and plan_launch_film (plan only). The scope — read the brand/page, plan, render film.mp4 — is concrete enough that an agent knows exactly what it produces.

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 routes the agent to a sibling explicitly: 'film.json is the plan; edit it and call render_launch_film to render again,' and points at launch_film_guide (via the look param) for look selection. What is missing is a direct statement of when to choose make_launch_film over calling plan_launch_film first to review the plan, or when to use make_launch_stills instead.

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

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

Annotations already declare openWorldHint=true and non-idempotent, and the description adds meaningful behavior beyond them: opaque PNG output, files written to stills/ and indexed in STILLS.md, and the side effect that supplying a site triggers film planning first. It does not discuss permissions or failure modes, but the added context is substantial.

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

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

Front-loaded with the core action and platform list, then the input-mode rule. Dense but every clause carries information; the version/machine parenthetical is the only low-value fragment.

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, yet the description still notes the job_id/wait behavior and where artifacts land. For a 4-parameter tool with full schema coverage, this is close to complete.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by decoding the enum values (ph = Product Hunt, og = link previews, x, play, chrome) and clarifying that source may be a website or an existing film.json. That is genuine meaning 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 and resource ('Makes the pictures a launch needs') and enumerates the exact platforms and output artifacts (stills/, STILLS.md), which clearly separates it from make_launch_film and render_launch_film.

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?

Explains the two input modes ('Give a site and it plans a film first, or give a film.json so the pictures match the film'), which is real usage guidance. It stops short of explicitly saying when to prefer this over make_launch_film or plan_launch_film.

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-readonly, non-idempotent, open-world, non-destructive, so the bar is lower. The description still adds real value: it discloses that the tool writes a film.json artifact and stops short of rendering, and it names the version/runtime ('launch-film 0.2.0, on this machine'), which signals local execution.

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, followed by the next-step instruction. The trailing parenthetical version/environment note is marginally useful context rather than filler, though it slightly dilutes the ending.

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

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

With an output schema present, return values need no explanation, and the description covers the write-then-render lifecycle plus the guide pointer for editing the artifact. The only gap relative to tool complexity is not clarifying the relationship to make_launch_film.

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

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

Schema description coverage is 100% and each of the 10 parameters carries its own description (defaults, enums, bounds, wait_seconds rationale), so the schema does the heavy lifting. The description adds no parameter-level meaning beyond pointing at film.json and launch_film_guide; baseline 3 is appropriate.

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

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

Uses specific verbs and resources: 'Reads a product's brand and page and writes film.json, the plan of a launch film, without rendering it.' The explicit 'without rendering it' cleanly separates it from render_launch_film and make_launch_film, so an agent can pick it without opening a schema.

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

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

Gives a concrete workflow: run this, edit film.json (consult launch_film_guide for scene types and fields), then call render_launch_film. It does not, however, say when to prefer this two-step path over the sibling make_launch_film, which is the main remaining routing ambiguity.

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

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

Beyond the annotations (which only mark it non-read-only, non-destructive, non-idempotent), the description discloses that rendering happens locally via Chrome and ffmpeg, writes output adjacent to the input, and takes a few minutes. The duration warning is the key behavioral signal an agent needs to avoid an impatient retry.

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 and outcome before the sequencing advice and the duration warning. The '(launch-film 0.2.0, on this machine.)' trailer repeats locality already stated and is minor filler.

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

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

An output schema exists, so return values including job_id need no explanation here. Inputs, prerequisites, runtime cost, and locality are all covered; only the interaction between wait_seconds timeout and job_id polling is left to the schema.

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

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

Schema description coverage is 100%, with jobs, keep, and wait_seconds all documented in-schema, so baseline is 3. The description only adds the output-location detail ('next to it') for the film parameter and nothing further about jobs or keep.

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 both endpoints: it renders a film.json into a film.mp4 placed next to it, using Chrome and ffmpeg locally. That distinguishes it from the sibling authoring tools (plan_launch_film, make_launch_film) that produce the input rather than the finished video.

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 says to use it after plan_launch_film or after editing the film.json from make_launch_film, which gives a clear prerequisite sequence. It does not name alternatives such as wait_for_job/cancel_job, but the wait_seconds schema text covers the follow-up path for long renders.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered; the description adds the non-obvious polling contract and the duplicate-job hazard. It does not spell out what happens when the job fails or is cancelled, but that gap is modest given the annotated idempotency and the existing 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?

Two short sentences, front-loaded with purpose, then the retry rule and the anti-pattern. Every clause carries actionable information with no filler.

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

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

For an async polling tool the description covers purpose, retry behavior, and the main misuse risk, while the schema documents both parameters and an output schema exists for the return value. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 100%, so job_id and wait_seconds are already fully documented in the schema. The description reinforces job_id's reuse semantics across calls but adds nothing about wait_seconds, so baseline 3 applies.

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

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

"Waits for a job a makersmcp tool started and returns its result once it ends" gives a specific verb (waits) and resource (job started by a makersmcp tool), plus the outcome. The explicit warning not to re-run the originating tool separates it from the make_*/render_* siblings that an agent might otherwise 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 states the exact usage loop ("If it is still running, call this again with the same job_id") and an explicit when-not ("Never start the original tool again to check on a job: that starts a second one"). The agent needs no inference to know how to poll.

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