Quelta Video Ad Analyzer

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

Beyond the annotations (which only flag openWorld/non-idempotent/non-destructive), the description discloses quota consumption ('one of the account's 5 free preliminary checks per day'), expected latency (~1 minute), the ~40-second async threshold with status 'processing', and the shape of the result including a 20-point-wide preliminary score range and a link to the full report. That is exactly the operational context an agent needs to set user expectations and handle the async path.

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 purpose and required input are front-loaded in the first clause, followed by usage, then return/async/quota details in a logical order. It is a dense block rather than a scannable list, and the return-value enumeration could be trimmed, 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?

With no output schema, the description carries the full burden and does: it enumerates what comes back (20-point score range, 3-second hook checks, weak areas, measured problems like subtitles/loudness/safe zones, report link). It also covers the async fallback, quota, and latency, so an agent can call it and handle every outcome 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 100%, with enums and defaults documented inline (platform guessing, ISO country fallback to US, audience age bands, report language). The description only restates that scoring uses the given platform, market and audience age and that platform is inferred from the link, adding no syntax or fallback detail beyond the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource — starting a preliminary check of a short vertical video ad from a public link — and bounds the scope (up to 3 minutes, enumerated platforms, sized for a given platform/market/audience). It also differentiates itself from the sibling get_analysis by explaining that an unfinished run returns status 'processing' plus an analysis_id for that 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 explicit trigger conditions: 'Use it when the user shares a link to a video ad and asks to watch, analyze, review, score or improve it.' It also points at get_analysis for continuation, but never explicitly says when to prefer upgrade_to_full_review over this preliminary check, nor states exclusions (e.g. non-video or horizontal ads).

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 readOnlyIdempotent/non-destructive, so safety is covered. The description adds genuinely useful context beyond them: the free-check quota is 5 per day and is shared with quelta.ai, which explains cross-product consumption behavior an agent could not infer elsewhere.

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 naming the resource first, then the fields, with a compact parenthetical that carries real information (the 5/day shared quota). 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 zero-parameter read with no output schema, the description covers the key returned fields and the quota rule. Minor gaps remain about the units/meaning of 'full checks on the balance', but the core is 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?

The tool takes no parameters, so per the baseline there is nothing for the description to disambiguate; the description sensibly spends its words on returned data instead.

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 (Show) and resource (the connected Quelta account) and enumerates exactly what is returned: email, free preliminary checks left today, and full checks on the balance. The resource is clearly distinct from the sibling tools (analyses, video ads, upgrades), 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?

Usage is only implied: an agent can infer this is the tool for checking account status and remaining quota balances. There is no explicit when-to-use statement and no guidance on when another sibling (e.g. upgrade_to_full_review) is the better call after seeing the balance.

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 readOnly/idempotent/non-destructive, and the description adds meaningful behavior beyond that: the call blocks up to ~40 seconds, degrades to status 'processing' with progress if unfinished, and returns structurally different payloads for preliminary vs full checks. Those are exactly the operational facts an agent needs to plan around a potentially blocking 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?

Three sentences, front-loaded with purpose, then waiting behavior, then return shapes. Every clause carries information the caller needs; nothing is restated from the title 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?

There is no output schema, so the description must describe returns — and it does, distinguishing the preliminary result (score range, hook checks) from the full result (exact score, category scores, issues with timecodes and fixes). Combined with the ID sourcing and blocking behavior, an agent has everything needed to call and interpret this 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 100%, so the baseline is 3. The description adds value by enumerating all three sources of analysis_id (the schema mentions only two) and by explaining the wait semantics in terms of observable outcome ('waits up to ~40 seconds... if it is still running, returns status processing'), not just the parameter's name.

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

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

States a specific verb+resource ('Get the status or result of a Quelta analysis') and narrows scope by keying on analysis_id. It also names the sibling tools that produce that ID (analyze_video_ad, list_my_analyses, upgrade_to_full_review), so an agent can place it precisely in the workflow rather than confusing it with the analysis-starting 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?

Clear context: call this after starting an analysis, using an ID obtained from analyze_video_ad, upgrade_to_full_review, or list_my_analyses. It does not spell out an explicit when-not condition (e.g. don't poll repeatedly when a webhook/callback exists), so it stops short of full alternative routing.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the two-source scope and the returned field set, but says nothing about ordering, pagination, or how 'recent' is determined.

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 sentences, no filler, with the purpose and scope front-loaded before the return-field enumeration. Every clause 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?

With no output schema, the description usefully enumerates the returned fields (analysis_id, date, platform, market, product, score/score range, depth, report link), which compensates well. Minor gaps remain around ordering and default result window ('recent').

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%: the single 'limit' parameter is documented with a range and default, so the schema carries the meaning. The description adds no semantics beyond what the schema says, which is the correct baseline 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 ('List recent analyses') plus the account scope and both data sources (AI assistants and quelta.ai website). It implicitly separates itself from get_analysis (single) and analyze_video_ad (create), though it never names a sibling 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?

Usage is implied by the scope 'recent analyses in the user's Quelta account', but there is no explicit when-to-use vs alternatives guidance and no exclusions, e.g. no pointer to get_analysis for a single result or to search/filter behavior.

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 destructiveHint=true and readOnlyHint=false, and the description explains exactly why: it consumes one full check from the account balance (first one free). It also discloses the 1–3 minute runtime, the ~40-second 'processing' cutoff, and the fact that a repeat call for the same analysis is free — all behavior beyond what annotations state.

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 and output contents, then credit cost, then timing — a sensible order. It is dense and multi-clause but nearly every clause carries operational information; only the lengthy enumeration of the six categories could be tightened.

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

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

With no output schema, the description fully carries the return burden: it lists the score, six category scores, issues with severity and timecodes, prioritized fixes and strengths, plus the 'processing' status and where to retrieve the eventual result. Nothing an agent needs to call it correctly or interpret the response 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?

Only one parameter, and schema coverage is 100% with the schema already saying it must be "the analysis_id of a finished preliminary check." The description restates that same constraint ("finished preliminary check") with no added syntax or format detail, so the schema is doing the work. 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?

States a specific verb+resource ("Run the full check on a finished preliminary check") and immediately enumerates what the check yields: a 0–100 score, six named category scores, issues with severity/timecodes, fixes and strengths. The phrase "finished preliminary check" cleanly separates it from the sibling that produces the preliminary result, so an agent can tell the full-check tool from the preliminary-analysis tool 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 clear precondition ("on a finished preliminary check"), an idempotency rule ("calling it again for the same analysis does not use another one"), and routing for the async case ("get_analysis returns the result"). It does not explicitly name analyze_video_ad or state when to prefer a preliminary run instead, so exclusion guidance is implied rather than stated.

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