AffiliateSpy

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

Even though annotations already flag destructiveHint=true, the description adds crucial behavior: it sends a reply, reveals metered contacts, and launches a campaign, requires a two-step token approval, and shows the exact error/return shape. No contradiction with 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?

Three sentences pack a clear operation, effects, guardrails, and error flow with no filler. Key behavior is front-loaded before details.

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 destructive but gated tool, the description explains the authorization loop, metering consequence, guardrails, and where action_id comes from via the schema. No output schema exists, but the error shape and orchestration are disclosed; an agent can invoke it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds value by defining approval_token as the token from a prior approval_required response and explaining the call sequence. This is more than parameter listing, but not by a huge margin because the schema descriptions are already good.

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 names the exact operation — approve a queued autopilot action and execute it — and spells out concrete consequences (draft sent, proposal reveals contacts and launches). This clearly distinguishes approve_autopilot_action from siblings like get_autopilot or reject_autopilot_action.

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 provides clear context for how the approval flow works: call without the token to get an approval_required error plus token and summary, then call again with the token. It does not explicitly name when-not-to-use or alternatives, but the two-step flow and 'same gated paths as dashboard approve' are sufficient for selection.

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?

The description adds meaningful behavioral context beyond the annotations: it emphasizes that this tool only creates a draft, cannot perform downstream actions, and uses a default 4-step sequence. This helps an agent avoid expecting side effects like sending or launching. No contradiction with 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 sentences, front-loaded with the core action and scope, with no filler. Every sentence adds value, including the explicit draft-only warning and the follow-up dashboard link.

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 create-draft tool with five parameters and no output schema, the description covers the essential behavior, the default sequence, and the next step. It does not specify behavior when both creator_ids and use_saved are provided, but this is a minor 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 coverage is high at 80%, so the schema already documents most parameters. The description adds a helpful link between creator_ids and the saved-list workflow, but does not materially explain parameter semantics beyond what the schema already provides.

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 clear verb and resource: 'Create a DRAFT outreach campaign' from creator ids or a saved list. It also distinguishes itself from launch_campaign by explicitly saying it cannot launch, enroll, or send.

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 clearly communicates when to use this tool ('DRAFT ONLY') and what it cannot do (launch, enroll, send). It points the user to the dashboard for launching, but does not explicitly name launch_campaign as the alternative tool, so the guidance is strong but not fully explicit.

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 indicate read-only and idempotent behavior, and the description adds valuable non-obvious details: the paid feature/subscription gate and the email privacy rule ('Emails appear ONLY for creators you have revealed'). These are behaviorally significant and not inferable from the annotations. No contradiction 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 sentences, each carrying distinct information: output format and filter equivalence, subscription gating, and email redaction. It is front-loaded with the core purpose and avoids filler.

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 an export tool with no required parameters and a high-coverage schema, the description covers the important non-schema aspects: subscription requirement and data visibility restrictions. The main gap is that it does not describe how the CSV is delivered (e.g., file download vs URL), and there is no output schema to fill that in, but this is not critical for selecting and invoking the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 86%, so individual parameters are already documented. The description's main added semantic is 'same filters as list_creators', which helps conceptually but does not explain any individual parameter. It clarifies that 'has_contact' values are hidden until revealed, but that is behavioral rather than semantic detail. Baseline 3 is appropriate.

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

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

The description states the deliverable clearly: 'CSV of your creator list', which distinguishes it from list_creators by output format. It also references the sibling list_creators to clarify that the same filtering applies caeteris. The operation is slightly implicit, relying on the title for the 'Export' verb, but the purpose is 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?

The description says 'same filters as list_creators', connecting it to a known sibling and making the output format the key differentiating factor. It also provides important selection context: 'requires an active subscription, same gate as the dashboard export'. It lacks an explicit 'when not to use' statement, but the context is clear enough.

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 mark it readOnly, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: it specifies the return content (plan name, caps, contact reveal usage with UTC reset on the 1st, tracked app usage vs cap). This tells the agent exactly what to expect without any side effects. No contradictions.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the purpose ('Your AffiliateSpy plan and usage') and packs in all relevant details without redundancy. Every clause earns its place, and it is immediately scannable.

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 parameterless read-only tool with no output schema, the description fully covers what the agent needs: it enumerates the returned fields and even notes the reset schedule. There is no missing information that would hinder correct invocation or interpretation of the response.

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 has zero parameters, so the baseline is 4 per the rubric. There is nothing to explain beyond the schema, which is already empty. The description doesn't need to add parameter meaning, and it doesn't. This is appropriate.

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

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

The description clearly states the resource (AffiliateSpy account) and the specific data returned: plan name, caps, contact reveal usage with reset schedule, and tracked app usage. This distinguishes it from sibling get_* tools, which all target different resources (campaign, creator, thread, etc.). No ambiguity.

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?

While no explicit 'use when' guidance is provided, the description makes it self-evident that this is the tool to check plan limits and quota usage. It names the exact metrics (contact reveals used/left, tracked apps used vs cap), which implies it should be consulted before quota-consuming operations. It doesn't state exclusions or alternatives, but there is no competing sibling for account-level info, so this is adequate.

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 (readOnlyHint, idempotentHint, destructiveHint false), so the description need not restate it, yet it adds 'Read-only' anyway. It goes beyond annotations by enumerating the exact state components returned, giving the agent a concrete expectation of what the operation exposes without any 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?

A single sentence front-loads the subject ('The Discovery Autopilot's state'), then uses a colon-delimited list to pack five distinct pieces of information into a compact, scannable format. Every word earns its place; no filler or repetition.

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 — zero parameters, no output schema, and annotations already establishing safety — the description fully covers what an agent needs: it describes every category of state that will be returned (current on/off, offer, send counts, approval queue, recent activity). Nothing critical is left for the agent to infer.

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 accepts zero parameters, so there is no schema detail for the description to supplement. Per the baseline for 0-parameter tools, this dimension is satisfied: nothing is left ambiguous about inputs.

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 ('Get autopilot state') and then names every constituent of that state: on/off, commission offer, send count vs cap, approval queue, and recent activity. It clearly differentiates from siblings such as set_autopilot, approve_autopilot_action, and reject_autopilot_action by framing this as a read-only observation 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?

The description provides clear context that this is for inspecting the autopilot's current state, listing exactly what information can be learned from it. It does not explicitly name alternatives or state 'when not to use', but the read-only framing and the sibling tool names make the appropriate use case obvious without additional 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by specifying the exact content of the response, which goes beyond the annotations. It does not mention auth requirements or rate limits, but these are not critical for a read-only get.

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, efficient sentence that lists the key data components. It is front-loaded with the resource type and immediately states what is included. No filler or redundancy.

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 read-only get with one parameter and no output schema, the description adequately conveys what is returned. The annotations cover safety, and the listed components give a clear picture of the response. It could optionally describe error cases or format, but that is not essential for correct 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 0%, so the description must compensate. However, the description does not mention campaign_id at all. While the parameter name and tool name make its purpose obvious, the description adds no meaning beyond the schema. It only describes the output, not the 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 description clearly states the resource ('One campaign') and enumerates the specific data returned: settings, sequence templates, enrollment rows, and latest reply previews. This distinguishes it from list_campaigns (which lists many) and other get_* tools like get_creator or get_thread.

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 context is clear: use this when you have a campaign_id and need detailed information about that single campaign. It does not explicitly mention alternatives or exclusions, but the sibling list makes the distinction obvious. No exclusions are needed for a straightforward get operation.

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 show readOnlyHint=false, but the description goes beyond by explaining the side effect (proration, settings URL returned instead), the payment webhook dependency, and the requirement to call get_account afterward. This adds important behavioral context not present in annotations, such as the fact that access is granted asynchronously.

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 yet dense, front-loading the core purpose (checkout URL) and immediately providing essential pricing details. Every sentence adds value—no fluff, and it efficiently covers usage, safety, and post-call actions in a compact form.

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?

The description is complete for a tool with only two optional parameters and no output schema. It covers the return value, the alternate behavior, the dependency on a webhook, and the follow-up action, leaving nothing an agent needs to know to call 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% and enums define valid values, so the schema already documents the parameters. The description adds the pricing tiers and the yearly discount, which enriches the meaning, but the baseline is 3 because the schema already does the heavy lifting; no additional syntax or format details are 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?

The description clearly states it returns a Stripe Checkout URL for a plan, with explicit pricing and interval details. It distinguishes itself from other tools by focusing on the checkout link generation, while also noting the alternate behavior for active subscriptions, which differentiates it from a simple billing 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 explicitly tells the agent when to use it (when a user needs to pay or switch plans), and when not to (never enter payment details, and call get_account after webhook confirms access). It also implies the alternative path for existing subscriptions, providing clear decision 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 already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds meaningful behavioral nuance by stating that contact value stays hidden unless already revealed, which is a non-obvious access-control behavior an agent needs to know.

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 one tight sentence that front-loads the main purpose, uses a colon to introduce the content categories, and ends with the contact-visibility caveat. Every clause earns its place and there is no redundant wording.

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?

Even without an output schema, the description names the major response categories and the one conditional behavior that affects returned data. For a simple read-only detail tool with a single required parameter, this is enough for an agent to select and 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?

The only parameter, creator_id, is fully documented in the schema with a description pointing to list_creators as the source. The tool description adds no further parameter-level meaning, so the schema already carries this burden.

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 opens with 'Full detail for one creator' and then enumerates the specific data categories returned, making the tool's purpose explicit. It is clearly distinguishable from list_creators and other sibling tools because it targets a single creator's full record rather than a collection or action.

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 clearly implies this is the detail-fetch tool for one creator, and the schema's parameter description ('An id from list_creators') reinforces the expected workflow of listing creators first. It does not explicitly name alternative tools 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 already mark it read-only and idempotent. The description adds critical behavioral details: long-polling server-side up to 45 seconds, waiting for done/failed status, returning masked handles (no real handles/contacts), and the hint format. This goes well beyond the annotations and provides meaningful operational context.

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 with no filler. It front-loads the purpose and content, then explains the long-poll behavior and usage. Every clause earns its place.

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

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

For a tool with no output schema, the description sufficiently describes the return content (progress, locked preview rows, fields) and the long-poll semantics. It also gives the usage sequence and retry guidance, making it fully actionable for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with run_id and wait_seconds fully described including defaults and sources. The description adds no parameter-specific meaning beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description states a specific verb and resource ('get quick scan preview'), enumerates the content (progress and locked preview rows with platform, followers, hint, masked handle), and explicitly distinguishes its purpose from status polling by mentioning the paid-plan unlock use case. It clearly separates from get_scan_status and start_quick_scan.

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 gives explicit when-to-use guidance: 'Use it to show the user what a paid plan unlocks, then get_checkout_link.' It also explains the long-poll behavior and advises calling again while status is queued or running. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent to select it correctly.

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 that the tool returns stages, status, and creators found, which is useful context beyond the annotations. It does not mention any edge cases like empty results or permission requirements, but given annotation coverage, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with zero waste. The first sentence states exactly what the tool returns, and the second provides actionable sibling context. The core purpose is front-loaded and every clause earns its place.

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

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

For a simple read-only status tool with one optional parameter, the description is complete. It explains the return values (stages, status, creators found) and even points to the tools used to start scans, giving agents enough context to call it correctly without needing an output schema.

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% with the app_id parameter described ('Omit to use your most recently added app.'). The description adds no additional parameter-level semantics beyond what the schema already provides, so the baseline 3 applies.

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 a specific action and resource: it retrieves the latest scan run for an app, including stages, status, and creators found. It implicitly distinguishes itself from sibling tools like start_scan and start_quick_scan, which are for initiating scans, and get_quick_scan_preview, which implies preview functionality.

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 direct pointers to sibling tools for starting scans (start_quick_scan, start_scan) with conditions (free preview vs. guarded/plan required), but it does not explicitly state when to use this tool versus alternatives like get_quick_scan_preview. The purpose is clear enough to infer usage, and the alternatives are named, so it earns a 4 rather than 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 cover read-only and idempotent safety, so the bar is lower. The description adds that the thread includes full message bodies and that no tool can send email, which is useful context. It does not add details about pagination or return format, but these are minor for a single-thread fetch.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no filler. The primary purpose is front-loaded, and the exclusionary note is concise. Every word 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?

For a simple read-only get operation with one parameter, the description is adequate. It covers purpose, source of the ID, and the alternative for replies. The absence of an output schema is acceptable given the nature of the tool and the explicit mention of full message bodies.

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% and the parameter is described as 'An enrollment_id from list_inbox_threads.' The description reinforces the source of the ID, which is helpful for correct invocation. It adds value beyond the schema's basic type/format declaration.

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 ('get') and resource ('one inbox thread') with a key qualifier ('full message bodies'), clearly distinguishing it from sibling list_inbox_threads. It is concise and 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?

It explicitly states when not to use the tool (for replying) and directs the agent to the dashboard inbox, an alternative. It does not explicitly contrast with list_inbox_threads, but the 'full message bodies' phrasing implies the selection context. Clear guidance overall.

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?

The description goes beyond the annotations by explaining the two-step approval flow, the exclusion of creators without revealed emails, and the fact that the engine handles scheduling, window, and daily cap. The destructiveHint annotation is consistent with the description's statement that the campaign is set active, and the description adds valuable context about the approval token mechanism and guardrails.

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 compact and information-dense, with each sentence serving a purpose: defining the action, explaining the approval flow, and clarifying guardrails. It is well-structured, front-loading the core behavior before the conditional approval logic.

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?

The description covers the essential behavioral aspects: what happens to creators without revealed emails, the approval token flow, and the engine's scheduling behavior. It does not detail the exact response format beyond the approval_required case, but given the absence of an output schema, the description provides sufficient context for an agent to invoke the tool correctly and handle the main edge case.

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 schema describes campaign_id with format and pattern, and approval_token with a description. The description adds meaning by explaining that approval_token comes from a previous approval_required response and is needed to confirm the launch. With 50% schema coverage, the description compensates for the approval_token parameter's role, though campaign_id semantics are already clear from 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?

The description clearly states the tool's function: launching a DRAFT campaign, enrolling only creators with revealed emails, and setting it active. It distinguishes itself from sibling tools like pause_campaign, resume_campaign, and create_campaign_draft by specifying the draft-to-active transition and the email-reveal filtering behavior.

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 explicitly explains when to use this tool (to launch a draft campaign) and provides a critical usage condition: without an approval_token, it returns an approval_required response requiring user confirmation, and the tool must be called again with the token. It also clarifies that dashboard guardrails apply, which helps an agent understand the tool's scope relative to user actions.

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 useful context about the response contents (creator counts, latest scan status) and the app_id usage, but does not disclose pagination, ordering, or whether the list is limited. With annotations covering the main behavioral traits, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The first sentence states what the tool returns, and the second gives the practical takeaway for the agent. Information is front-loaded and 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?

For a zero-parameter, read-only list tool with annotations covering safety, the description is nearly complete. It explains the output contents and the app_id convention. The only minor gap is not mentioning pagination or result limits, but this is not critical for a simple list 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?

The tool has zero parameters, so the schema provides no parameter semantics. The description adds value by explaining that the returned app id should be used as app_id in other tools, which is the key semantic information an agent needs. Baseline 4 for zero params is appropriate.

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

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

The description states a specific verb ('List') and resource ('tracked apps'), and adds what the response includes (creator counts, latest scan status). It is clear enough to distinguish from siblings like list_campaigns or list_creators, though it does not explicitly name a sibling alternative.

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 gives clear context: this lists apps you track and provides the app id for use in other tools. It implies when to use it (when you need app ids or app-level status), but it does not explicitly state when not to use it or name 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 readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable context beyond annotations: the v1 draft-only limitation and the specific stats returned, which help the agent set expectations without redundancy.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core purpose and immediately followed by a critical limitation. Every word earns its place; no filler or redundancy.

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 parameters and no output schema, the description fully conveys the tool's function and its limitations. The stats fields are named, and the dashboard redirect for actions is given, so nothing essential is missing for correct 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?

The tool has zero parameters, so the schema trivially covers 100%. No parameter explanation is needed, and the description correctly adds none. Baseline 4 applies for a no-parameter tool.

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 it lists outreach campaigns with specific stats (sent, replies, queued, signed), and immediately differentiates from sibling tools that create or modify campaigns by noting v1 tools can only create drafts. This is a specific verb+resource with clear scope.

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?

Provides explicit when-not-to-use guidance by stating launching, pausing, and sending happen in the dashboard, which tells the agent not to expect those actions here. However, it does not explicitly mention alternatives like get_campaign for single-campaign retrieval, so it lacks a full alternative list.

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 communicate readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds business logic about what counts are included, but it does not disclose additional behavioral constraints such as auth requirements, rate limits, or data freshness. No contradiction 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?

The description is a single sentence that front-loads 'Your competitors with roster counts' and then enumerates the three counting categories. There is no filler or redundant content.

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-parameter, read-only listing tool, the description conveys the main payload semantics well. Without an output schema, it leaves the exact response shape slightly implicit, but that is a minor 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?

The tool has zero parameters and the schema description coverage is 100%, so there is no parameter burden for the description to carry. The no-parameter baseline of 4 applies.

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 title supplies the verb 'List' and the description specifies the resource—competitors—and the exact output semantics: proven paid-partner counts, mention counts, and multi-brand promoters in the niche. This makes it easy to distinguish from sibling tools like list_creators or list_deals.

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 implies the use case (inspecting competitor roster counts and finding creators promoting multiple brands), but it gives no explicit when-to-use guidance, no exclusions, and no pointers to alternative tools. It is adequate but relies on 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?

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint), the description discloses sanitization behavior, inclusion of already-revealed emails, default sort order, pagination semantics, and response total after filters. This is substantial behavioral context with no contradictions.

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 compact sentences front-load the core purpose and add only high-value behavioral details. There is no redundancy or filler.

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 10-parameter tool with no output schema and 80% schema coverage, the description covers the non-obvious behaviors: sanitized contacts, reveal-tool interaction, sorting default, pagination, and total. Remaining filter semantics are already in the schema.

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 80%, and the description adds meaning beyond it by stating the default score-descending order, pagination mechanics via limit/offset, and the presence of a total-after-filters field. It does not enumerate every parameter, but the schema already documents those.

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 identifies the tool as listing graded creators for an app, with contact sanitization, and references the sibling reveal_contact for revealing hidden values. It is easily distinguished from get_creator, export_creators_csv, and list_apps.

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 provides clear context on when the tool is relevant—listing scored creators for an app—and mentions reveal_contact as the path for hidden contact values. It stops short of explicitly contrasting with single-creator retrieval or CSV export, but the context is sufficient for correct selection.

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, covering the safety profile. The description adds meaningful content about what the listing includes (stages and un-pipelined replied creators), which goes beyond annotations and clarifies the result scope. It does not contradict any annotation.

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, well-structured sentence that front-loads the key concept ('Your pipeline') and immediately specifies the stage ordering and additional inclusion. Every word earns its place with no redundancy.

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-parameter, read-only listing tool with annotations covering safety, the description sufficiently communicates what the output will contain (deals by stage and replied creators not in pipeline). It does not detail pagination, ordering, or output field structure, but with no output schema and a simple listing purpose, this is acceptable. Minor gap in not stating if the list is full details or summaries.

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 has zero parameters, so there is nothing for the description to elaborate on. Per the rubric, 0 params earns a baseline of 4. The description confirms the tool takes no input and simply lists the pipeline, which is consistent.

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 (list) and resource (deals in pipeline), and defines the exact scope: deals by stage plus replied creators not yet in pipeline. This clearly distinguishes it from siblings like list_creators or list_campaigns, so an agent can immediately understand what it returns.

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 implies when to use it ('Your pipeline') but does not explicitly name alternatives or exclusions. However, given the tool's zero parameters and read-only nature, the intended use is fairly obvious from context. It lacks explicit 'use this instead of X' guidance but still gives a clear functional context.

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 read-only/idempotent/non-destructive; the description adds that it returns only metadata + last activity and points to get_thread for bodies. It also discloses a system limitation (no email sending), which is useful context beyond the schema.

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 short sentences, front-loaded with action/resource and immediately useful routing information. Every phrase contributes to selection or invocation, with no wasted words.

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?

Rich annotations plus the description's response-scope note and get_thread routing make this simple two-param tool safely callable. An explicit mention of pagination or what 'metadata' includes would add value, but nothing critical is missing for 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?

Two optional params; the schema describes limit's range/default, and unread_only is self-evident from the name, but the description adds no parameter-level meaning. At 50% schema coverage, this is adequate but does not exceed what the schema already provides.

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 action ('List') on a specific resource ('Outreach conversation threads') and defines scope as metadata + last activity, not bodies. It distinguishes itself from sibling get_thread by directing message-body access elsewhere.

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?

Names get_thread as the route for message bodies and explicitly says replying is not available through tools, so an agent knows not to reach for this tool for replies. Caveat: with send_reply present as a sibling, the absolute 'no tool can send email' is confusing and may mislead an agent.

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, covering the safety profile. The description adds that results include per-keyword roundup coverage (counts and whether a competitor or the user's app is featured), which is useful context. However, it does not disclose pagination, result ordering, or any limitations, so it adds moderate value 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, concise sentence that front-loads the main purpose (search keywords) and then adds the specific data points included. Every word earns its place, with no redundancy or filler.

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 no parameters, no output schema, and annotations covering safety, the description is mostly sufficient. However, the phrase 'whether any feature you' is awkward and ambiguous – likely meaning 'whether any feature your app' – which could confuse an agent. It also does not clarify if all keywords are returned or if there is a limit. These small gaps keep it from being fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, so the schema trivially has 100% coverage. The description adds nothing about parameters because there are none, and the baseline for 0 parameters is 4. No additional parameter semantics are 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?

The description clearly states the tool searches tracked keywords for the app and adds specific details about roundup coverage. It is distinct from sibling list tools (list_competitors, list_creators, list_apps) by focusing on keywords, 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?

The description gives no guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It does not mention scenarios where a different list tool would be more appropriate, leaving the agent to infer from the name alone.

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 valuable context about the output contents (SERP position, competitors, your app feature status), which goes beyond what annotations provide. However, it does not disclose pagination or response format details, so a 4 is appropriate.

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 sentence that front-loads the core purpose and key output details with zero waste. It is concise and well-structured.

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 there is no output schema, the description covers the key return elements (SERP position, competitors featured, your app status). It is adequate for a read-only list tool with all optional parameters. Minor gaps like pagination or sorting are not critical for correctness.

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 all parameters are documented in the schema. The description contextualizes the 'keyword' parameter (for your keywords) but does not add meaning beyond what the schema already provides. Baseline 3 is correct.

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 lists roundup articles and videos for keywords, including SERP position, competitors featured, and whether the user's app is featured. This is a specific verb+resource that distinguishes it from other list tools like list_creators or list_campaigns.

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 implies usage (when you need to see roundup placements for your keywords) but does not explicitly state when to use this tool vs alternatives or mention any exclusions. There is no alternative referenced, so guidance is only implied.

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 indicate this is a non-read-only mutation, and the description adds no extra behavioral context such as whether prior stage history is kept, whether backward moves are allowed, or whether the call overwrites the current stage. There is no contradiction with the annotations, but also no added 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 a single, front-loaded sentence with no filler or repetition. It earns its place and leaves no wasted words.

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 mutation with no output schema, the description gives the basic operation but is thin on consequences and transition rules. An agent could call it correctly, but it would not know what to expect on success or whether the move can go to any enum stage regardless of the current one.

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 description adds no parameter-level meaning. The schema already documents deal_id as coming from list_deals and gives the stage enum, so the only uncovered semantics are the meaning/ordering of the stage values, which the description does not address.

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 clear verb ('Move'), a specific resource ('a pipeline deal'), and the target ('to a new stage'). It distinguishes this tool from the sibling tools, none of which perform deal-stage changes.

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 intended use is implied by the description: use it when a deal's stage should change. However, it gives no explicit guidance on prerequisites, such as obtaining a valid deal_id via list_deals, and no when-not-to-use or alternative tool 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 indicate mutation (readOnlyHint=false) and non-destructive nature (destructiveHint=false). The description adds the approval token requirement, the exact error format for approval_required, and the reassurance that nothing is deleted. This goes beyond annotations and is helpful, though it does not cover edge cases like idempotency or existing state.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff. The purpose is front-loaded, followed by the critical approval flow and a safety note. Every word 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?

Given the lack of an output schema, the description covers the key behavioral aspects: the approval error response, the safety guarantee, and the dashboard equivalence. It does not describe the success response or behavior on an already-paused campaign, but for a simple pause action this is minor and not critical for correct 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 50% (approval_token has a description, campaign_id does not). The tool description explains the campaign_id as the target and the approval_token's role in the guarded flow, effectively compensating for the missing schema detail and adding context beyond the raw 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 verb ('Pause'), a specific resource ('an active campaign'), and the effect ('stops future sends; nothing is deleted'). This clearly distinguishes it from siblings like resume_campaign and launch_campaign without needing to inspect them.

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 explains the two-step approval flow and that it's equivalent to a dashboard action, providing clear context for when to use it. However, it does not explicitly name alternatives or conditions like 'use resume_campaign to undo', so it lacks explicit 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?

The annotations show no hints (readOnly=false, destructive=false), but the description proactively discloses the guarded approval flow and how rejection feeds into the drafter's prompt. It also clarifies that this is equivalent to user actions in the dashboard, setting expectations about permissions. This goes beyond schema and annotations, providing useful behavioral context. No contradiction with 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 concise, starting with the core behavior, then the feedback loop, then the guarded flow. Each sentence adds value and there is no fluff. It is well-structured for quick scanning.

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 moderate complexity (3 params, no output schema), the description covers the main aspects: what it does, the guarded flow, and safety equivalence. It doesn't describe return values, but since there's no output schema, that's a minor gap. Overall, it provides enough for an agent to call 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?

The input schema documents all parameters with descriptions (coverage 100%), so the baseline is 3. The description adds minimal extra parameter info; it mentions 'reason' is fed back but doesn't add format or syntax details beyond the schema. Thus, the description doesn't significantly enhance parameter understanding, and the schema already handles it well.

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 action: rejecting a queued autopilot action with a reason. It also conveys the impact of the reason on future drafts, which is meaningful context. While it doesn't explicitly name sibling approve_autopilot_action, the contrast with that sibling is implicit in the description's focus on rejection, so it effectively differentiates the purpose.

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 explains the guarded flow with approval_token, telling the user to call again with the token after confirmation. It also notes that dashboard guardrails apply, implying a safety context. However, it doesn't explicitly say when to use this over approve_autopilot_action or other alternatives, but the overall behavior is clear enough for an agent to know when to invoke 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?

Goes well beyond the annotations (which are minimal) by explaining the approval_token flow (first call returns approval_required, second call with token proceeds), the effect on the campaign (sends continue under window/caps), and the safety guarantee that it is equivalent to a dashboard user action. This fully discloses the behavioral contract.

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 sentences, each earning its place: purpose, approval flow, safety guarantee. No filler, front-loaded with the core action, and the critical approval mechanism is explained immediately.

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 an approval gate, the description covers the required call pattern, error response, and safety scope. Without an output schema, it still tells the agent what to expect on failure and how to proceed. Nothing essential 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?

The description explains the approval_token's role and lifecycle, which is critical and not obvious from the schema alone. The campaign_id is a standard uuid and self-evident from the tool name, so the 50% schema coverage is adequately compensated.

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 the exact action (resume a paused campaign) with a specific verb and resource, and adds clarifying detail about the engine's window and caps. The purpose is unmistakable and clearly distinct from siblings like pause_campaign and launch_campaign.

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 implies the correct usage context—resuming a paused campaign—and clarifies that it mirrors a dashboard user's action, ensuring no escalation of privileges. It doesn't explicitly name alternatives or exclusion conditions, but the purpose is clear enough that an agent will know when to invoke 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?

The description adds valuable behavior beyond the annotations: it explains the quota cost ('Spend ONE monthly reveal'), clarifies idempotence ('without spending again'), and enumerates possible errors ('no_subscription, cap_reached, no_contact'). This is consistent with the destructiveHint and idempotentHint annotations, so there is no 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?

Three concise sentences cover the purpose, cost, idempotence, and error cases with zero filler. The primary action is front-loaded, and each sentence contributes distinct 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?

The tool has one well-documented parameter, and the description explains the cost, the returned value type, idempotence, and possible error states. Even without an output schema, an agent has enough information to invoke it correctly and interpret the expected result.

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 schema already fully describes the only parameter, creator_id, including a UUID pattern and the note 'An id from list_creators.' The description does not add parameter-specific semantics beyond a generic reference to 'creator', so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb and resource: 'Spend ONE monthly reveal to get a creator's contact value (email / IG handle / bio link)'. It also states the cost and idempotence, making the operation unmistakable and distinguishing it from sibling tools like get_creator, which would not necessarily reveal contact data.

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 implies the tool should be used when a caller wants a creator's contact value and is willing to spend a monthly reveal, but it does not explicitly name alternatives or state when not to use it. The cost and idempotence hints provide context, but there is no direct comparison with sibling tools.

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 carry the core safety signals: readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds useful context that the saved list is the pool campaigns draw from, but it doesn't describe effects like duplicate handling, persistence details, or return behavior. There is no contradiction with 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?

One sentence with no filler; the core action and the larger purpose (campaign shortlists) are both included. It is appropriately front-loaded and compact.

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 one-parameter, idempotent mutation with no output schema, the description covers what the tool does and why the saved list matters. It doesn't state the return value, but annotations covering idempotence and non-destructiveness make that a minor omission.

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 description doesn't explicitly explain creator_id's format or meaning beyond the schema, and schema description coverage is 0%. However, with a single obvious parameter named creator_id and the description saying 'Add a creator', the mapping is clear enough to be minimally viable, though the description adds little beyond 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?

The description uses a specific verb ('Add') plus a resource ('a creator to your saved list') and adds context that the saved list is the source for campaign shortlists. This makes the tool's function explicit and distinguishes it from siblings like unsave_creator.

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 clearly indicates when to use the tool: when a creator should be placed on the saved list that campaigns draw from. It doesn't explicitly mention alternatives or exclusions, such as using unsave_creator for removal, so it provides clear context without full 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?

The description goes well beyond the annotations, disclosing that subscription limits, daily send caps, Gmail connection state, and OUTREACH_TEST_MODE redirect are all enforced inside the function. It also specifies the exact guarded behavior when approval_token is missing, including the returned error shape and the need to call again with the token. This is rich, non-obvious behavioral context.

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 moderately sized but every sentence carries relevant operational information: purpose, gated path, approval behavior, and safety equivalence to the dashboard. There is minor redundancy between 'SAME gated path' and 'Every dashboard guardrail still applies,' but overall it is well-structured and front-loaded.

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 tool with no output schema, the description covers the most critical conditional return (approval_required), the enforced guardrails, and the token retry flow. It does not describe the success response shape, but the rich input schema and behavioral disclosure make the tool callable and understandable without it.

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 already 3. The description adds meaningful parameter semantics by explaining that approval_token comes from a previous approval_required response and that the function should be called again with it after user confirmation. It does not add much beyond the schema for body or enrollment_id, but the approval flow is genuinely useful.

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 uses a specific verb and resource: 'Send an email reply in an inbox thread.' It also clarifies the scope by tying behavior to the dashboard composer, making it clear this is the user-action path rather than an automated or campaign-level send. This is enough to distinguish it from every sibling tool, none of which target sending an inbox reply.

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 gives clear usage context: this is the user-equivalent dashboard send path, and it explains the approval-token flow—call first without a token, then call again with the token after confirmation. It does not explicitly name alternatives or say when not to use it, but the context is concrete enough for an agent to apply it correctly.

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?

The description goes well beyond the annotations by disclosing the hourly proposal loop, emphasizing that nothing sends without approval, and explaining the approval_token round-trip behavior. It also clarifies that dashboard guardrails apply, giving the agent a clear safety model.

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?

Every sentence earns its place: the first states the primary action, the second discloses the side effect and approval guarantee, and the third explains the guarded two-step protocol. It is front-loaded and compact despite covering complex behavior.

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 tool with no output schema, the description covers the essential invocation flow, error shape, approval mechanism, and safety equivalence to dashboard actions. An agent has enough information to call it correctly and to know what to expect when confirmation is required.

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 schema already documents all three parameters with 100% coverage, so a baseline of 3 is appropriate. The description adds cross-parameter meaning by explaining how approval_token interacts with the rest of the call and when it is required, which goes beyond individual schema descriptions.

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 opens with a concrete verb and resource pair: 'Turn the Discovery Autopilot on or off, and/or set the commission offer.' This clearly states the action and scope, and it is distinguishable from sibling tools like get_autopilot or approve_autopilot_action.

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 guarded-flow instructions are explicit: call without approval_token to get an approval_required response, then call again with the token. This gives clear procedural context, though it does not explicitly contrast the tool with siblings such as approve_autopilot_action or state when not 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?

Annotations already mark idempotentHint=true and destructiveHint=false. The description adds value on top by specifying 'attach or replace' semantics, the private scope, the max length, and especially the special behavior that an empty string clears the note. No contradiction with annotations 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?

A single compact sentence delivers the core action, scope, length limit, and clearing behavior without any filler. The key information is front-loaded and every clause earns its place.

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

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

For a two-parameter, no-output-schema setter, the description sufficiently covers the operation, scope, length limit, and empty-string clearing. It does not describe return values or errors, but the tool's low complexity makes that omission minor.

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 some compensation burden. It adds meaning for 'note' by describing it as a private note and explains the empty-string clearing behavior, but it does not elaborate on creator_id beyond what the schema's UUID pattern already provides.

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 action ('Attach or replace') and the resource ('your private note on a creator'), with a concrete length constraint. This makes the tool's purpose immediately understandable and distinguishes it from creator save/unsave or list operations in the sibling set.

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 conveys clear context: use this tool when you need to create, update, or clear a private note on a creator. It does not explicitly name alternatives or when-not-to-use conditions, but no sibling tool has an overlapping purpose, so the usage context is sufficient.

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 annotations (which only indicate not read-only, not idempotent, not destructive), the description reveals the mutation semantics ('creates the tracked app'), preview limitations ('masked handles, no contacts'), rate/quota constraints ('one quick-scan app per unpaid account, 6 an hour'), and asynchronous behavior ('Takes 20 to 60 seconds to return... intake runs first'). This gives the agent essential operational knowledge that annotations alone do not provide.

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?

Every sentence earns its place: the first states the core function, the second covers plan/quota constraints, the third preview limits, the fourth the alternative tool, and the fifth the expected latency and next step. The description is dense but not bloated, front-loads the essential purpose, and avoids vague filler.

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 there is no output schema, the description compensates by explaining the full workflow: it creates an app, queues a scan, takes 20–60 seconds due to intake, and directs the agent to call get_quick_scan_preview to retrieve results. It also covers user-tier distinctions and rate limits. An agent can confidently invoke this tool and know what to expect and do next.

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 input schema already describes all three parameters with 100% coverage, so the baseline is 3. The description adds no new parameter-level nuances beyond restating that the URL can be an App Store, Google Play, or website URL, which the schema already covers. It does not elaborate on how kind or market interact with the scan, leaving the schema as the primary source for those details.

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 immediately states the tool's verb and resource: 'Free quick scan of an App Store, Google Play or website URL: creates the tracked app and queues the scan.' This clearly distinguishes it from the sibling start_scan, which is explicitly referenced as the full-scan alternative for paying accounts. The scope and output (tracked app plus queued scan) are 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?

The description gives explicit when-to-use and when-not-to-use guidance: 'No plan needed' and 'Accounts WITH a plan should use start_scan for the full scan instead.' It also instructs the correct follow-up action—'then call get_quick_scan_preview'—so an agent knows the full workflow. This is far beyond a bare statement of purpose.

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 destructiveHint=true, and the description adds meaningful behavioral context: it spends credits, follows the same gates as the dashboard, refuses concurrent scans with scan_in_progress, and describes the guarded approval flow. It also explicitly states this is exactly what a dashboard user could do, no more, which adds safety 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?

The description is dense but well-structured. It front-loads the core purpose, then explains gates and the approval flow, and ends with a clear guarantee. No wasted words, though it could be slightly more compact. It is appropriately sized for the complexity.

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 destructive, non-idempotent tool with no output schema, the description covers the essential behavior: cost, prerequisites, failure conditions, and the two-step approval process. It does not state what a successful call returns, but given the approval flow and the fact that the user is mimicking a dashboard action, the missing success response is a minor gap. Overall, the description is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so all parameters are documented in the schema. The description adds value by explaining the approval_token flow ('call again with the token') and the overall process, which complements the schema's bare parameter descriptions. It does not introduce new parameter semantics beyond what the schema provides, but the flow context is useful.

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 action: 'Start a creator scan for an app' with the side effect of spending scan credits. It is specific about the resource and verb, but does not explicitly differentiate from the sibling start_quick_scan, though the 'type' parameter suggests a distinction. Still, the purpose is 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?

The description explains the approval flow and dashboard gates, but gives no guidance on when to use this tool versus the sibling start_quick_scan. It mentions the general conditions (subscription, no concurrent scan) but does not point to alternatives or exclude cases. There is no 'when not to use' 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 already cover idempotency and non-destructive behavior, so the burden is lower. The description adds the 'saved list' context but does not disclose whether removal is reversible, whether authentication is required, or what happens if the creator is not currently saved. No contradiction with 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?

One short, front-loaded sentence with no filler. Every word contributes directly to the core 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?

For a simple one-parameter mutation with annotations covering idempotency and destructiveness, the description is minimally adequate. However, with 0% schema description coverage and no output schema, a brief clarification of creator_id and the idempotent behavior would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not mention creator_id at all. The parameter's meaning is left entirely to its property name and UUID schema, so the description does not compensate for the low coverage.

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 uses a specific verb ('Remove') and a specific resource ('creator from your saved list'), making the operation unambiguous. It clearly distinguishes itself from the sibling save_creator by stating the inverse action.

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 intended use is implied: call this when a creator should be removed from the saved list. However, it does not explicitly state when not to use it or contrast it with save_creator or other alternatives.

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