Go Rocket

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

Goes well beyond the annotations: credits are spent immediately (including comp credits), the job is cancellable with a full refund for 60 seconds, rendering takes ~15 minutes, and a repeated call without an idempotency key can double-charge. This is exactly the kind of cost, latency and reversibility context 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?

Dense but front-loaded: the capability and cost land in the first two sentences, then conditional paths. Every sentence is actionable, though the description is long enough that a reader must hold several branch conditions (auth, credits, no-URL, polling) at once.

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 still explains the immediate return (video_id plus a message that may carry plan_url) and how to obtain share_url later. Combined with the credit, timing and cancellation details, an agent has everything needed to invoke 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 parameters are already documented; the description still adds workflow meaning — what belongs in brief (tone and audience), the cinema↔30-second coupling, and why idempotency_key matters on retries. Marginal but genuine value on top of 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 — start a finished 9:16 AI UGC video ad from a website — plus the concrete output (photoreal presenter, captions, brand colours). It is clearly distinguishable from siblings like get_video_sample and get_sample_status, which retrieve samples rather than create a rendered ad.

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 routing for multiple situations: signed out → sign_in then retry in the same chat; insufficient credits → read plan_url; business name without URL → find and confirm the official site first; after creation → poll get_video / status_tool for share_url. It also names the retry discipline (idempotency_key) and the cancellation window.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds real context beyond that: "Nothing is charged by this tool" addresses billing concerns. The sentence "The sampled site stays attached as the first video" is ambiguous about whether any state change occurs, which sits uncomfortably beside readOnlyHint=true but does not clearly assert a mutation, so it is not scored as a contradiction.

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 paragraph is long and run-on, mixing return value, account routing, a literal sentence to speak to the user, a state note about the sample, billing, and a follow-up sign-in. Only the first sentence is front-loaded; the remaining clauses are unordered and some appear to conflict, so sentences do not cleanly 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?

With one optional parameter, no output schema, and annotations covering safety, the description covers enough to call the tool in the happy path. It falls short on the claim_token contract and on clarifying whether the sample attachment is an effect of this call, which are the two things an agent would most likely get wrong.

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 parameter, claim_token, with 0% property-level schema coverage, so the description must carry the meaning — and it never mentions claim_token or when a caller must supply it. The object-level schema note ("required when signed out") does the work instead, leaving the description adding nothing on the only input.

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 first sentence states a specific verb and return value ("Returns plan_url, the Go Rocket plan page on go-rocket.ai"), which is genuinely useful. However, the rest of the paragraph blurs what the tool actually does — it discusses sample readiness, sample attachment, and post-hoc sign-in, making it unclear whether this is a pure link getter or participates in a claim flow. Sibling differentiation is partial: it names sign_in and create_video, but not get_sample_status or get_video_sample, which the "once the sample is ready" clause implicitly requires.

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 branch by situation: "Existing account? Call sign_in, then create_video" versus new account "call this once the sample is ready." That is real routing guidance. But the ordering is confusing ("Afterwards, sign in through this connector" appears to reverse the earlier branch), and it never plainly states the precondition that this is only for signed-out/new-account contexts even though the schema hints claim_token is for signed-out use.

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, non-destructive, and closed-world behavior. The description adds meaningful state-machine details: 'reading', 'ready', 'failed', and 'purchased', including the follow-up action for 'purchased.' It does not mention auth or polling limits, but it adds substantial behavioral context beyond 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 a single compact sentence with the action front-loaded and the return states clearly enumerated. There is no wasted text.

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 polling tool with no output schema, the description supplies the key return states and the follow-up action for the 'purchased' case. The main gap is claim_token semantics, but the overall usage context is otherwise sufficient given the annotations.

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, claim_token, and schema description coverage is 0%, so the schema provides no semantic help. The description never explains what claim_token is, where it comes from, or its format; 'started by get_video_sample' only loosely implies the source.

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: 'Poll a sample started by get_video_sample.' It also enumerates the possible return states, which makes it clearly distinguishable from get_video_sample (start) and sign_in (purchased path).

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 precondition that the sample was started by get_video_sample, and it names sign_in as the alternative when state is 'purchased.' It does not specify polling cadence or stop conditions, but the when-to-use context is clear.

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.