Go Rocket

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

Annotations cover safety/idempotency hints, and the description adds substantial non-obvious behavior: credit costs and comp-credit usage, immediate start, a 60-second full-refund cancellation window, ~15-minute async completion, idempotency semantics for retries, and auth requirements. This is far beyond what the annotations 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?

Front-loaded with the core purpose, then flows through cost, auth, idempotency, and follow-up steps in a logical order. It is dense and mostly earns its place, though the long single paragraph packs slightly more than necessary for a first read.

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 covers the return contract (a video_id returned right away, poll get_video, fetch share_url via status_tool once ready), plus timing, cost, and error/auth paths. Nothing an agent needs to call 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?

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning: it maps length to credit cost, explains brief should carry tone/audience, and clarifies idempotency_key is for retry safety. It stops short of documenting language/presenter enum sources beyond pointing to get_account.

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 (create a 9:16 AI UGC video ad for a website) with concrete output details (photoreal presenter, captions, brand colours), making it trivially distinguishable from siblings like get_video_sample and sign_in. An agent knows exactly what this 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?

Explicitly covers when-to-use and gating conditions: checkout only when credits are insufficient, sign_in then retry when signed out, find-and-confirm URL for a business name with no URL, and poll get_video after. It names the sibling (sign_in) and the follow-up tool, leaving little 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 cover the safety profile (readOnly, idempotent, non-destructive), and the description adds genuinely new behavioral context: no money is charged here, payment only occurs after opening the checkout and confirming, and post-payment sign-in is required. It stops short of describing link expiry or reuse behavior.

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-loads the purpose and then walks through the account-specific flows in short, purpose-driven sentences. The final sentence about signing in after payment is slightly tangential but still earns its place by closing the loop.

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 no-output-schema, single-parameter link generator, the description covers purpose, timing, and the surrounding account flow well. The notable omission is claim_token semantics, which leaves the only input underspecified.

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 claim_token is described only in the schema's top-level note ('required for a signed-out sample checkout'); the tool description never mentions it at all and offers no guidance on when it is needed versus omitted. With 0% property-level schema coverage and one undocumented parameter, 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 concrete verb+resource ('Returns a checkout link') and scopes it to two cases (monthly plan or one-time top-up). It differentiates itself from workflow siblings by naming sign_in and create_video, though it never explicitly contrasts with get_sample_status or get_video_sample.

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 routes the agent: existing accounts should call sign_in then create_video to consume credits first; new accounts should call this once the sample is ready. It states both the when and the when-not, with named alternatives.

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

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

Annotations already declare this a safe, idempotent read, so the safety profile is covered. The description adds real behavioral value by enumerating the full state machine ('reading', 'ready', 'failed', 'purchased') and clarifying what each means, including that 'failed' means nothing to buy. It stops short of describing retry cadence or rate limits, but that's a smaller gap against existing 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?

Two tightly packed sentences: purpose and origin first, then the return states. No filler, no repetition of the title, and nothing that fails to earn 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?

For a polling tool with no output schema, the description carries the essential return-value information and links back to the initiating tool. The remaining gaps (obtaining claim_token, polling cadence) are minor given annotations already cover the read-only/idempotent traits.

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 claim_token has 0% schema description coverage, so the description must compensate and only partially does. "A sample started by get_video_sample" implies the token's provenance but never says explicitly that claim_token is the value returned by that call or what format it takes.

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 ("Poll") and resource ("a sample started by get_video_sample"), and explicitly anchors the tool to the sibling that creates the sample. An agent can distinguish it from get_video_sample and get_checkout_link without opening any 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?

The phrasing "Poll a sample started by get_video_sample" implies the tool is used after starting a sample, and "Poll" hints at repeated invocation. However, it never states when to stop polling, which states warrant a retry, or how it relates to get_checkout_link once the sample is ready.

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 give readOnlyHint=false and idempotentHint=false; the description adds substantial context beyond that: it returns a claim token, nothing is generated or charged, the page check is bounded to two seconds, and the tool blocks up to wait_seconds before falling back to 'reading'. This is exactly the behavioral detail annotations cannot 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?

Front-loads what the sample is, then the polling flow, then the no-charge assurance. Dense with semicolons and clause stacking, but every sentence carries load; only mild tightening is possible.

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 compensates by describing the return values (claim token, state 'reading'/'ready') and the async completion path via get_sample_status. An agent has everything needed to call and follow up 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 baseline is 3, but the description adds real meaning: it explains that wait_seconds governs the bounded page check and the fall-back to 'reading', and that the sample_page_url supplies brand colours while the direct clip is untinted. Slightly above baseline.

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 a sample video ad') and characterizes the artifact precisely as 'a stored, blurred library montage.' It explicitly separates this from the real deliverable ('Your real video is made after you start it'), distinguishing it from the sibling create_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?

Gives explicit when-to-use and follow-up routing: if state is 'reading', 'call get_sample_status with the claim token every few seconds until it is ready.' The role of wait_seconds versus polling is spelled out concretely.

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

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

Annotations already declare this read-only, idempotent, and non-destructive, but the description adds real behavioral context the annotations don't: it opens an OAuth flow, may not visibly open, has a reconnect fallback, and preserves existing credits. It stops short of stating what state changes on success or how failure surfaces.

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 prerequisite, and the Claude Code steps and fallback earn their place. The embedded verbatim user-facing quote ('Say: ...') is slightly awkward but is genuinely actionable, so only minor waste.

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 no-param, no-output-schema auth tool, the description covers the trigger, the interactive steps, the failure fallback, and the next action. Minor gap: it does not clarify how the agent should detect that sign-in succeeded before retrying create_video.

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, which is the baseline-4 case; there is nothing for the description to disambiguate. Description adds no param detail, but none is needed.

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 ('Connect your existing Go Rocket account', 'open the connector's OAuth sign-in') and explicitly scopes it as a prerequisite that must happen before create_video. It is easy to distinguish from the video/checkout/sample 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?

Explicit when-to-use ('before making a video'), an alternative path for Claude Code (/mcp > Authenticate), and a fallback when no sign-in opens. It also directs the agent back to create_video afterward, so the sequencing is unambiguous.

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