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

No annotations are provided, so the description must carry the behavioral load. It discloses that the result concerns the currently configured license and that quota-style counters (used/remaining) are returned, but says nothing about whether the call is a safe read, requires credentials, or how often the counters refresh.

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 that front-loads the purpose and then lists the returned values, with no filler. Every clause adds information.

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

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

For a zero-parameter read tool with an output schema, the return values need not be explained further, and the description adequately covers what the tool reports. The only gap is the absence of any usage or freshness context, which is minor at this complexity level.

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 and the schema is empty, so there is nothing for the description to disambiguate. Baseline of 4 applies for a parameterless tool.

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

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

The description gives a specific verb ('Check') and resource ('the configured license') and enumerates the returned facets (licensee, checks used, checks remaining), which clearly separates it from the pricing, spend, render, and event siblings. It does not explicitly name or contrast a sibling tool, so it stops 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?

There is no statement of when to call this tool versus alternatives such as stg_pricing or stg_spend_report, and no prerequisites or exclusions are mentioned. The agent must infer usage from the tool name alone.

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?

No annotations are provided, so the description carries the full behavioral burden. It mentions the output and a cost-like note ('Uses 1 check'), but does not disclose read-only status, permissions, rate limits, error handling, or whether the operation consumes credits in a specific way.

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?

Very short and front-loads the output description, but the first clause is a fragment and 'Uses 1 check' is unclear. It avoids bloat, yet some sentences are too cryptic to fully earn their place.

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

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

The presence of an output schema means return values need not be explained, but for a single-input tool with no annotations and 0% schema description coverage, the description is missing key context: parameter format, invocation guidance, and behavioral constraints.

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 one required parameter, video_path, and schema description coverage is 0%. The description does not mention the parameter at all, so it adds no meaning beyond the schema's type and title, such as whether the path is a local file or URL.

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 the output (frames and times of impacts, flashes and cuts) and the use case (placing sound effects in an editor), which is specific enough to distinguish it from unrelated siblings like stg_account and stg_pricing. The trailing 'Uses 1 check' is vague, but the core purpose is clear.

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 an intended application ('for placing sound effects in an editor') but no explicit when-to-use, when-not-to-use, or alternative tools. It does not say what kind of video input is required or whether other tools should be used first.

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 no annotations, the description carries the behavioral burden and discloses important constraints: local path, max 32 MB / 60 s / 1080p, 'Uses 1 check', and that it returns a JSON report plus review frames. It does not discuss permissions, side effects, or rate limits, but the key operational traits are present.

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 purpose, constraints, and measured metrics, then closes with return behavior and next step. It is dense but each clause earns its place, though the metric list is long.

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 no output schema, the description explains the return type and how to use the returned frames. For a five-parameter tool with no annotations, it covers workflow and limits well, but it should do more to explain the optional parameters.

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 five parameters. The description adds meaning for the required 'path' (local file limits) and for 'reference_image' (colour/lighting drift comparison), but it leaves 'sensitivity', 'ignore_issues', and 'review_frames' unexplained beyond their bare titles.

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 ('Measure') and resource ('rendered image or video'), then enumerates the exact quality dimensions it checks. It also names the follow-up tool stg_qa_gate, making the tool's role unmistakable.

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 workflow context: inspect the returned review frames for anatomy/identity defects, then call stg_qa_gate. It does not state when not to use the tool or name alternatives such as stg_detect_events, but the intended usage is well 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose one useful trait - no license is required to call it - but says nothing about side effects, whether it is read-only, or whether it implies any checkout/authorization action, which is a notable gap given the checkout-links wording.

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 terse sentence, front-loaded with the useful content and free of filler. The phrasing is slightly telegraphic ('Plans, prices and checkout links') 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?

With an output schema present, return values need not be described, and with zero parameters the schema burden is nil. What remains is an adequate but thin definition: the auth note is covered, yet the nature of the operation and its role among the stg_* siblings is left implicit.

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 baseline of 4 applies; the schema has nothing for the description to elaborate on. No parameter-level meaning is missing.

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 lists what the tool surfaces (plans, prices, checkout links) which gives a reasonable sense of the resource, but offers no verb and never states the operation, so the agent must infer that this is a lookup/model-retrieval tool. No sibling overlap is apparent, but there is no explicit differentiation either.

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 guidance, no mention of when another sibling (e.g. stg_account or stg_spend_report) would be the better choice, and no task context. The only usable hint is 'No license needed', which is a precondition rather than usage direction.

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 no annotations, the description carries the full burden, and it does disclose two meaningful traits: it records the attempt and its cost in a local project ledger (a side effect), and it is 'Free (needs a license, uses no checks)' (cost/auth profile). It stops short of describing what each disposition triggers downstream or whether the ledger write is idempotent, so the behavioral picture is 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?

The disposition set and the required inputs are front-loaded, and the remaining sentences each carry distinct information (fix suggestions, param sourcing, ledger side effect, cost). It is dense but not padded, though the mid-paragraph param notes make it slightly run-on.

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 no-annotation, 11-parameter, mutation-and-ledger tool, the description leaves most parameter meanings and the consequences of each decision branch unstated, so it is only adequately 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 description coverage is 0% across 11 parameters, so the description must compensate. It explains only two of them (technical_issues and semantic_defects, including the 'other' + notes convention), leaving project, shot_id, model, render_cost_usd, stage, fallback_model, visually_reviewed, notes, and project_budget_usd 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 gives a specific verb and resource ('Decide what to do with a render') and enumerates the exact disposition set (PASS / NEEDS_VISUAL_REVIEW / RETRY_SAME_MODEL / SWITCH_TO_FALLBACK / HALT / HALT_BUDGET), which an agent can act on. It also ties itself to a sibling by naming stg_inspect_render as the source of `technical_issues`. Sibling differentiation against the other tools (stg_account, stg_pricing, stg_spend_report) is only implicit.

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 through the data-flow references ('the issues array from stg_inspect_render', 'what you saw in the review frames'), which suggests this runs after inspection and review. However, it never states explicitly when to invoke this gate versus the siblings, nor when not to use it, leaving the sequencing 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?

No annotations are provided, so the description carries the full behavioral burden. 'Local only' is a useful hint that no network/external call is made, but it does not state read-only vs mutating nature, cost, permissions, or output shape, leaving the operation's behavior largely opaque.

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 phrases, front-loaded with the metric list and tailed with the locality constraint. Nothing is padded, though the final 'Local only.' fragment is slightly abrupt.

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 metric enumeration covers the report's contents. However, with a required parameter that is entirely undocumented and no usage routing, the definition is only minimally adequate for a single-parameter report 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 description coverage is 0% and the single 'project' parameter is undocumented in both schema and description. The description adds no information about what the parameter accepts (ID, name, path?) or its format, 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 the specific metrics reported (render spend, attempts per shot, first-try pass rate, failed renders), which is concrete and distinguishes it from a generic spend tool. It stops short of explicitly contrasting with siblings like stg_pricing or stg_qa_gate, but the content scope is clear.

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 guidance on when to reach for this versus stg_pricing, stg_inspect_render, or stg_qa_gate, and no preconditions or context are given. The agent must infer usage entirely from the metric list.

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