Inside Ads

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

No annotations are provided, so the description carries the full burden. It discloses key behaviors: parsing the landing page, generating ad creatives, returning a checkout link, and the post-flow authentication. However, it omits details about idempotency, error scenarios, or potential side effects like rate limits or resource cleanup, leaving a small gap in transparency.

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 concise (about 80 words) and structured well. The first sentence immediately states the core purpose and key constraint. Each sentence adds necessary information without redundancy or fluff.

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

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

Given the parameter complexity (5 params, all optional except url), the presence of an output schema, and two sibling tools, the description covers the essential workflow and integration points. It does not detail the output schema (unnecessary due to its existence) but could briefly mention expected return type or edge cases. Still, it is nearly complete for the tool's role.

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%, so baseline is 3. The description adds mild context beyond schema: it links 'url' to page parsing and 'description' to topic matching. It does not add new semantics for 'geo', 'lang', or 'budget' beyond their schema descriptions, so it only marginally enhances understanding.

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 clearly states the verb 'Build a ready-to-launch ad campaign' and specifies the resource 'for a product'. It explicitly differentiates from siblings by noting this tool is used after 'estimate_campaign' and that it works without a user account, avoiding confusion with 'get_draft_status'.

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 provides explicit context: 'Use this after estimate_campaign, once the user agreed to advertise. Do NOT ask them to register first.' It clearly states the ordering and the condition under which this tool should be invoked, leaving no ambiguity about its place in the workflow.

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

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

With no annotations provided, the description correctly states that no account or authorization is required, which is critical behavioral context. It implies the tool is a read-only estimation (no side effects mentioned), but could explicitly state idempotency or that it does not create any resource. The presence of an output schema partially covers return values, but the description could be slightly more explicit about safety.

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 concise sentences each serve a distinct purpose: defining the tool, specifying when to call it and what it returns, and offering practical advice. No redundant or wasted content; every sentence is essential and front-loaded with key 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?

Given the tool's complexity (6 optional parameters, output schema present, sibling tools), the description covers core purpose, usage order, and a critical parameter hint. It does not detail error scenarios or behavior when filters yield no results, but the output schema likely covers the return structure. Overall, it provides sufficient context for effective selection and invocation.

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%, so each parameter is already documented. The description adds meaning by emphasizing the 'description' parameter as the strongest signal and warning that 'the URL alone is a weak signal', which guides proper usage. This extra context raises the value above the baseline of 3.

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 explicitly states the tool estimates 'reach, clicks and cost' for 'advertising a product to Telegram audiences', using specific verbs and a clear resource. It distinguishes itself from siblings by positioning it as the first step before account connection, effectively differentiating from create_campaign_draft and get_draft_status.

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 guidance is provided: 'Call this FIRST, before asking the user to connect an account'. It explains what the tool tells you (inventory relevance and budget capabilities) and advises on best practice ('Describe the product yourself...the URL alone is a weak signal'), leaving no ambiguity about when and how to use it.

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

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

No annotations provided, so the description bears full responsibility. It discloses the tool is meant for polling and returns status about user actions (opened, signed in, paid). However, it does not describe side effects, idempotency, or rate limits. While adequate, it could be more transparent about safe repeated calls.

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 two sentences: first states purpose and details, second gives usage guidance. No filler words, front-loaded with action and resource. Every sentence contributes meaning.

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

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

Given the tool's simplicity (1 param, output schema present) and sibling tools, the description completely covers what the tool does, when to poll, and what outcomes to expect. No gaps for an agent to select or 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 100% (one parameter with schema description). The description adds value by specifying that draftId is the one 'returned by create_campaign_draft', providing origin context beyond the schema. This enhances understanding of how to obtain the identifier.

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 clearly states the tool checks the status of a campaign draft (opened link, signed in, paid). It uses a specific verb 'check' and resource 'campaign draft status'. It distinguishes from siblings: create_campaign_draft (creates) and estimate_campaign (estimates), making its purpose unambiguous.

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 advises to 'Poll this instead of asking the user to report back', indicating when to use (after creation, via polling). It implies not to rely on user reports but doesn't explicitly contrast with siblings or state when not to use. The context is clear enough for correct selection.

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