Idea Launch

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

Annotations cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), but the description adds genuinely useful context beyond them: applying costs no Ad Run credit and consumes no AI turn. It does not say whether an existing hero image is replaced, which is the main remaining behavioral unknown.

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 action in the first sentence, followed by tight argument definitions and a one-line return shape. No filler; the Args list is warranted given the empty schema descriptions.

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 mutation tool with no output schema, the description supplies the return shape ({ ideaId, imageUrl, applied }) and cost behavior, which is what an agent needs to call it confidently. It omits the response_format parameter and overwrite semantics, minor but real gaps.

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?

With schema description coverage at 0%, the description carries the burden and does so well, documenting all three required params and cross-referencing selectedResultId's origin in idealaunch_get_image_job. The fourth parameter, response_format, is left 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?

A specific verb ('Set ... as the idea's hero image') plus the exact resource being mutated. It is clearly distinguishable from the sibling idealaunch_generate_hero_image, which creates the image rather than applying one.

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 establishes a prerequisite chain: jobId must be 'a succeeded image job' and selectedResultId is 'the variant id from idealaunch_get_image_job', routing the agent to the correct upstream tool. It does not state what happens if no image job exists yet or how this interacts with the generate sibling, so it falls short of full when/when-not 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?

Annotations only cover the generic safety profile (not read-only, not destructive, not idempotent). The description adds genuinely new behavior: nothing is created on an ad platform and nothing is spent, and moderation-flagged content still creates the idea but holds it from public surfaces with heldForReview reported.

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 core action, then usage, then args, then returns, then the moderation caveat. Each block earns its place; the args list adds semantic detail the schema lacks rather than restating types.

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 explicit returns object (id, name, summary, publicSlug, heldForReview, workbenchUrl, nextStep) is valuable, and the moderation/spend behavior is covered. Minor gaps remain: no mention of permissions, rate limits, or the response_format parameter.

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 0%, so the description carries the burden and does so for the three meaningful params — name, summary (what it is/who it's for/problem solved), and websiteUrl (live URL for ad traffic). response_format is left undocumented, though its enum makes it largely self-evident.

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 with scope: 'Create a new idea in the signed-in user's workspace.' It further distinguishes two creation modes (validation test vs. ads for something already shipped), making it clearly distinct from the get_/list_/update_ 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?

Gives explicit when-to-use guidance and a branching condition: start a validation test, or pass websiteUrl to set up ads for an already-shipped product. It does not name an alternative tool or state when-not to use it, so it stops short of a 5.

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 say readOnlyHint=false and idempotentHint=false; the description goes further by disclosing that nothing is saved, that a generation turn is consumed (so repeat calls are not free), and that no Ad Run credit is spent. These are exactly the side-effect and quota facts an agent needs to plan a call sequence.

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?

Purpose is front-loaded, the non-persistence warning is bolded, and the description is compact. The explicit Returns block is justified because no output schema exists, though the nested shape is slightly verbose for a small payload.

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, describing the return value is necessary and done; quota and persistence behavior are covered. Only the meaning of response_format and ideaId usage is left unaddressed, a minor omission for two largely self-evident 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% and the description never explains either parameter. The listed suggestion fields describe the return payload, not ideaId or the markdown/json response_format enum, so the description fails to compensate for the schema 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?

States a specific verb and resource ('Generate suggested brief fields for an idea') and enumerates the generated fields, making the output scope concrete. It is clearly distinguishable from the sibling that persists the result, idealaunch_update_idea_brief.

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 workflow guidance: show suggestions to the founder, then save chosen ones with idealaunch_update_idea_brief. It also states cost conditions (one AI generation turn, no Ad Run credit), which tells the agent when invoking is cheap versus expensive.

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 declare readOnly=false/idempotent=false; the description adds the high-value context the annotations lack: save defaults to false so the founder reviews first, the call consumes one AI generation turn, it costs no Ad Run credit, and it deliberately does not write the conversion-critical sign-up fields. These are concrete side-effect and cost disclosures.

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 purpose sentence, then prerequisites, args, returns, boundary note, and cost note in labeled blocks. Every sentence carries actionable information with no padding.

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?

No formal output schema exists, but the description documents the return shape, the prerequisites, the mutation semantics, and the cost implications. For a generative, credit-consuming mutation tool, this covers everything an agent needs to invoke it 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 0%, so the description must carry the load. It fully explains save (write behavior and default), but ideaId is only implied and response_format (a schema enum) is undocumented in prose. It compensates well for one parameter but not all three.

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 ('Generate the ad creative for an idea') and enumerates the exact artifacts produced (tagline, primary/secondary ad text, image prompt, sign-up page copy). The agent can distinguish it from siblings like generate_hero_image or draft_brief 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?

Explicitly names the prerequisite path ('call idealaunch_draft_brief and idealaunch_update_idea_brief first if it is not [a complete brief]') and defines the boundary against idealaunch_update_idea_brief for sign-up headline/description/CTA. Both when-to-use and when-not-to-use are stated.

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 declare the safety profile (non-read-only, non-idempotent); the description goes beyond them by disclosing that generation runs in the background, that it consumes an AI generation turn, and that it does not draw an Ad Run credit. These are non-obvious operational and quota behaviors an agent would otherwise have to guess.

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 purpose in the first sentence, then uses compact Args/Returns/workflow blocks. Every sentence is actionable and none is redundant.

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 supplies the return shape (job id/status/prompt/variantCount/results, note) and the full next-step sequence, so an agent can call this correctly and act on the result without further inference.

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%, so the description carries the burden; it documents ideaId and explains that prompt is optional with a concrete default (the idea's saved image prompt). The third parameter, response_format (enum), is left undocumented in both places, so it does not fully 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 specific verb+resource ('Start generating hero image variants for an idea's ad') with the scope of the operation (image variants for an ad). It is clearly distinguishable from siblings like idealaunch_get_image_job (polling) and idealaunch_apply_hero_image (selection).

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 sequences the workflow: start here, poll idealaunch_get_image_job until status 'succeeded', then apply with idealaunch_apply_hero_image. It also frames the cost model ('consumes one AI generation turn', 'costs no Ad Run credit'), giving the agent everything needed to decide when to call this.

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), so the bar is lower, yet the description still adds real scope boundaries: it reports credits and published list price only and 'never reports what a campaign costs to run.' That negative boundary is genuinely useful context beyond the 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?

Four short sentences, front-loaded with purpose, then usage, then return shape, then a clarifying boundary. Each sentence earns its place and nothing is redundant.

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 burden of explaining returns and does so by listing the exact fields (email, availableAdRunCredits, requiredAdRunTokens, canStartAdRun, buyUrl), plus usage context and scope limits. An agent has everything needed to call and interpret it 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 0% and the description never mentions the single optional response_format parameter. However, it is a self-explanatory optional enum (markdown/json) with no required params, so the omission is minor and the baseline of 3 is appropriate rather than a harsher score.

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 ('Show the signed-in user's Ad Run credit balance') and adds the decision-relevant scope ('whether they can start a new Ad Run'). It is clearly distinguishable from siblings like get_capabilities or list_ad_runs.

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 when to reach for it ('Use this before suggesting a launch, so you know whether the user needs to buy a credit first'), giving a concrete trigger condition. It does not name a specific alternative tool or a when-not case, so it falls just short of a 5.

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 read-only, idempotent, non-destructive behavior. The description adds non-obvious behavioral context: the tool does not merely return one run, it aggregates lineage including derived boosts and a combined cross-lineage readout. It does not mention auth or rate-limit constraints, so it is not a 5.

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 the core purpose before the usage cue, and the Returns block is compact. The inline Returns object is dense but earns its place given there is no output schema; nothing is redundant.

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 supplies the return shape (run, lineage with rootRunId, bestCompletedRunId, overallReadout, runs, activeBoostRunId), which an agent needs. Annotations cover the safety profile. The remaining gap is unaddressed parameter meaning, preventing a 5.

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 all three params (ideaId, runId, response_format) are undocumented in schema. The description says 'one Ad Run' and 'the original run,' weakly implying runId, but never explains ideaId's role, the relationship between ideaId and runId, or the markdown/json response_format enum. 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?

States a specific verb (Get) and resource (one Ad Run) and scopes it precisely to 'full lineage — the original run, any boosts derived from it, and the combined readout.' This clearly differentiates it from siblings like idealaunch_list_ad_runs (plural listing) and idealaunch_get_run_events (events).

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 states when to use it: 'when the user wants the detail behind a single experiment, including how boosts compare to the original.' The 'one Ad Run / single experiment' framing implicitly distinguishes it from the list tool, but no alternative is named as an exclusion, so it falls short of a 5.

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 readOnly/idempotent/non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new context: it requires no account (auth-free) and it discloses the shape of the payload, which 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?

Three tight sentences, front-loaded with the 'what it does' clause, then usage, then return contents. No filler and 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?

There is no output schema, so the description correctly carries the burden by enumerating the return contents. For a zero-argument, read-only orientation tool the description 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 0% and the single parameter (response_format) is never mentioned in the description. The enum values markdown/json are largely self-explanatory, so the gap is mild rather than damaging, but the description does not compensate for the missing schema documentation.

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 ('What Idea Launch does... what a market read contains, and what it costs') and enumerates exactly what comes back: product summary, the two jobs, the four steps, the market read report, pricing. Against siblings like get_market_read or list_ideas, it is unmistakably the orientation/overview 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 a clear directive ('Use this first when you do not yet know what Idea Launch is, or when the user asks what they can do with it') plus the precondition that no account is required. It does not name a sibling alternative or a when-not condition, so it stops just short of a 5.

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 the read-only, idempotent, non-destructive profile, so the description's added value is the ownership scoping rule ('returns an error if the idea id does not belong to the signed-in user') and the readiness/fix behavior. That is genuine context beyond the annotations, though rate limits and pagination are unaddressed.

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 tightly-packed sentences: purpose first, then usage context, then return shape and the error case. No filler, everything is front-loaded and 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 steps in by sketching the return object (idea, readiness, readyToLaunch, activeRuns, recentRuns) and the error condition, which is nearly enough to call it confidently. The unaddressed response_format parameter is the one remaining gap.

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% for two parameters. The description only implicitly identifies ideaId as an idea identifier owned by the user; response_format (markdown vs json) is never mentioned, so the description does not compensate for the undocumented 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+resource ('Get one idea in detail') and enumerates exactly what the detail contains: setup progress, readiness checklist, active runs, recent runs. This clearly distinguishes it from siblings like list_ideas and get_ad_run.

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 explicit usage context ('Use this to answer "is this idea ready to test?"'), which tells the agent when to reach for it. It does not name alternatives or exclusions, so it falls short of a 5.

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 read-only, idempotent, non-destructive behavior, and the description adds real context on top: the full status lifecycle (queued, running, succeeded, failed, cancelled) and an 'error' field for failed jobs. It does not discuss polling cadence or rate limits, so it is not exhaustive.

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, then compactly documents the return shape and the follow-up routing. The dense inline return signature is information-rich but slightly hard to scan compared with prose; still, every sentence 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 supplies the response shape (job id, status, prompt, variantCount, error, results) and the status enum, which is exactly what an agent needs to interpret results. The remaining gap is the undocumented input 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% and the description never explains jobId, ideaId, or what response_format does — it only refers obliquely to 'a result id.' With three undocumented parameters, the description fails to compensate for the schema 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?

States a specific verb and resource ('Check the status of a hero image generation job') plus the secondary behavior of listing finished variants. This clearly separates it from idealaunch_generate_hero_image and idealaunch_apply_hero_image, which are named in the text.

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 explicit next-step rule: 'Once succeeded, pass a result id to idealaunch_apply_hero_image,' which routes the agent to the correct sibling. It implies poll-until-complete usage but never states when not to use it or how often to poll, so it stops short of a full 5.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real interpretive behavior beyond that: report results as evidence not proof, and disclose provisional readouts, which shapes how the agent should present the data.

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 capabilities, usage trigger, return shape, and caveats in scannable paragraphs. The inline return block is justified by the absence of an output schema; only minor redundancy between "decision readout" and the Returns list keeps it from a 5.

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 sketches the return shape and adds interpretation guardrails, which covers most of what an agent needs. The unexplained parameters and no sibling differentiation leave a small gap.

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%, so the description carries full responsibility for the three parameters (runId, ideaId, response_format). It never mentions or explains any of them, nor the meaning of runId vs ideaId, leaving the semantic burden unmet.

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 (get) and resource (decision readout for one Ad Run) and enumerates the payload: validation score and band, confidence, signals, and recommended next move. This lets an agent distinguish it from siblings like idealaunch_get_ad_run or idealaunch_get_run_events 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?

"Use it when the user asks how a test went, or what they should do next" gives clear triggering context, and "flagship result tool" signals priority. It stops short of naming alternatives or when-not-to-use conditions versus the sibling run/event tools, so it does not reach a 5.

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 it read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that by explaining what a pending_review hold means (no charge, nothing sent to the ad platform), which is not in the 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?

Front-loads the core purpose, follows with the diagnostic use case, and ends with the return shape in three tight blocks. Every sentence carries weight and nothing is redundant.

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 explicit return structure is a valuable addition, and the diagnostic framing plus pending_review semantics round out behavior. The only gap is that the input parameters are entirely undocumented, which is a real omission for a five-parameter 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 there are five parameters (ideaId, runId, limit, offset, response_format), yet the description explains none of them — not even which identifiers are required. It only describes the return shape, leaving every input undocumented.

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 ('Get') and resource ('chronological event log for an Ad Run') and enumerates the event types it contains (provisioning steps, status changes, review holds, errors). An agent can distinguish the timeline-oriented purpose clearly, though it does not explicitly contrast itself with siblings like get_ad_run or list_ad_runs.

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 diagnostic use case ('why is my run not live yet?') that tells the agent when this tool is the right one. It does not, however, name an alternative tool or state when NOT to use this, so the routing is contextual rather than exhaustive.

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, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that by disclosing the return envelope (total/count/offset/items/has_more/next_offset), which reveals pagination behavior, plus the promise that figures match the Idea Launch app. It says nothing about rate limits or ordering, keeping this below a 5.

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?

Purpose and the run-id use case are front-loaded in the first two short paragraphs, and the return shape is compact. The final sentence restates CTR and signups already listed in the opening line, a small redundancy that keeps it from a 5.

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 supplies the return envelope, which covers the main complexity for an agent. However, the pagination and format parameters remain unexplained, so an agent has no guidance on how to page through results or which response_format to request.

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% for all four parameters, so the description carries the full burden, and it explains none of them. ideaId, limit, offset, and the markdown/json enum are never mentioned; the return-shape listing only hints that offset/limit exist. This is a clear gap against the low-coverage rule.

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 every Ad Run for an idea') and enumerates the fields surfaced (status, platform, market read, CTR, signups). It clearly reads as a collection endpoint, distinguishable from the sibling get_ad_run, though it never names that sibling to sharpen the contrast.

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?

'Use this to see the history of experiments on an idea, or to find a run id' gives concrete use cases. It stops short of exclusions or alternatives (e.g. use get_ad_run when you already have a run id), so it is clear context without 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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds beyond that: the empty-case behavior ("no results if the user has not created an idea yet") and the returned field set, which is meaningful since no output schema exists.

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, then usage, then return shape and edge case. The return-shape dump is somewhat verbose but earns its place since no output schema is present; no filler sentences.

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, describing the return object and the empty-result case is exactly the needed compensation, and the id-finding guidance rounds it out. The only gap is parameter documentation, which is not addressed anywhere.

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 none of the three parameters (limit, offset, response_format) are explained in the description. The return shape mentions offset/has_more/next_offset, implicitly hinting at pagination, but the meaning of limit, offset bounds, and the markdown/json switch is left entirely undocumented.

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 (List) and resource (ideas) scoped to the signed-in user's workspace, and enumerates the returned fields (setup progress, run counts, signup counts, market read). This clearly distinguishes it from get_idea and the list_ad_runs/list_signups 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?

"Use this to find an idea id before calling any other idea tool" gives a concrete when-to-use condition, which is valuable given many siblings require an idea id. No explicit when-not or named alternative (e.g., get_idea) is provided, keeping it below a 5.

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 readOnly, idempotent, non-destructive, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: emails are withheld by default and replaced by domain, and there is a stated consent condition for revealing addresses. Good added context, though nothing about pagination or limits on large result sets.

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 purpose sentence followed by the privacy rule, then compact Args and Returns sections. Every element is doing work given the empty schema descriptions, though the Args list partly restates parameter names the schema already carries.

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 inline Returns block (total, count, items with their fields) is a meaningful addition. Combined with the email-privacy rule, an agent has enough to call and interpret this tool; only response_format behavior and any pagination/numbering limits go unaddressed.

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%, so the description carries the full burden — and it documents ideaId, runId, and includeEmails including its default of false, which is not in the schema. It omits response_format, one of the four parameters, so it does not fully 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?

Specific verb (List) plus resource (signups for an idea) with an explicit scoping qualifier ('optionally narrowed to one Ad Run'). An agent can distinguish it from sibling tools like idealaunch_get_idea or idealaunch_list_ad_runs 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?

Tells the agent when to use runId (only signups attributed to that Ad Run) and gives a real conditional rule for includeEmails ('do that only when the founder has asked for them'). No sibling tool lists signups, so there is no alternative to disambiguate against — clear context but no explicit exclusions.

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 readOnly/idempotent/no-destructive annotations, the description discloses behavior that annotations cannot: nothing is created or spent, paid inference is consumed only when a credit exists, plan/audience are omitted without credit, and readiness checks are always returned. This is exactly the kind of cost and side-effect disclosure that matters for a preview tool.

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 bolded no-create/no-spend statement is front-loaded where it matters most, followed by the gate/credit behavior and a compact returns listing. It is slightly long for two parameters, but every section 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 supplies the return shape (ideaId, readiness entries with key/label/ready/fix, readyToLaunch, credits, canStartAdRun, plan, launchUrl, note) and the conditional logic governing plan availability. An agent has everything needed to interpret the result without guessing.

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% for two parameters. The description never explains ideaId or the markdown/json response_format enum; the 'Returns:' block describes output shape, not parameter meaning. Not enough to compensate for a fully undocumented 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?

The description states a specific dual verb+resource: check readiness for an idea and preview what would run. It clearly separates this from siblings like idealaunch_get_ad_run (started runs) and idealaunch_get_idea (raw idea data), and the title reinforces the dry-run nature.

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 establishes the pre-launch context ('ready to test', 'preview what would run') and explicitly routes the actual start action elsewhere ('Starting the run is confirmed in the Idea Launch app'). It does not, however, explicitly say when to prefer this over idealaunch_get_idea or idealaunch_get_capabilities, so an agent must infer the ordering.

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 genuinely new behavior: the two mode branches and the exact response shape { ideaId, mode, url, copy, note }, which is valuable since no output schema exists.

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 short sentences with the core 'where traffic lands + copy' purpose front-loaded, followed by mode branches and a compact return shape. No filler; the explicit 'Returns:' line is slightly redundant with the prose but earns its place given the absent output schema.

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 two-parameter read tool with no output schema, the description supplies the return fields and the mode-dependent URL semantics, which is what an agent most needs. The gap is parameter documentation, particularly response_format, which is left entirely to the schema name.

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%, so the description carries the burden and largely does not meet it. ideaId is only implicitly referenced ('For an idea...'), and the response_format parameter (with its markdown/json enum) is never mentioned at all.

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 ('Show') plus the resource ('where ad traffic will land, and the copy on that page') and explains the two behavioral modes (generated waitlist sign-up page vs. founder's own site). It is immediately distinguishable from read tools like get_idea or list_ideas, though it never names a sibling to contrast against.

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 mode-dependent behavior implies this is the 'see what the ad will point at' step, but there is no explicit when-to-use statement and no reference to alternatives such as prepare_ad_run or generate_ad_assets. Usage context is inferable rather than stated.

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 it as a non-read-only, non-destructive, non-idempotent write, and the description stays consistent with that while adding genuine value: the partial-update/preserve-untouched-fields contract and the returned shape { ideaId, updatedFields, setup, briefReady }. It does not mention auth or what happens to invalid enum values, so it stops short of full disclosure.

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?

Well front-loaded: mutation semantics first, sequencing second, then Args, constraints, and Returns. The argument list is long but each item is necessary given the 0% schema coverage; the only waste is that listing bare field names adds little for the ambiguous ones.

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 16-parameter mutation with no output schema and no annotation nuance beyond the hints, the definition covers the return shape, the partial-update contract, the enum domains, and the upstream dependency. It lacks a description of what several fields mean, which is the remaining gap.

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 16 parameters, so the description carries the burden, and it does contribute the enum constraints (primaryMarket in US/CA/GB/AU/GL; conversionMode in waitlist/external_url) plus the at-least-one-required rule. However, it only enumerates the other 14 field names without explaining what any of them mean, and it omits response_format entirely, so the compensation is partial.

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 precise verb+resource ('Save one or more brief fields on an idea') and immediately qualifies the semantics with 'Only the fields you pass are changed; the rest are preserved.' This distinguishes it cleanly from idealaunch_create_idea and idealaunch_draft_brief without requiring the schema to be opened.

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 sequences the tool: 'Use this after idealaunch_draft_brief, once the founder has approved the wording.' It names the upstream sibling and the human-approval precondition, so an agent knows both ordering and gating.

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