AfterLaunch

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

Annotations already indicate non-destructive and non-read-only. Description adds idempotency (beyond annotations), scope requirement, and clarifies effect on Feed. 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?

Two sentences, no redundancy, efficient delivery of all key information (purpose, comparison, scope, idempotency).

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 single parameter, no output schema, and annotations present, the description covers purpose, behavior, idempotency, and authentication requirements completely.

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 100% with move_id description referencing list_feed. Main description does not add additional parameter context beyond schema, meeting baseline for high 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?

Clearly states the verb 'archive', the resource 'growth move', and distinguishes from sibling 'skip_move' by describing it as a lighter dismissal. Provides precise scope and effect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly compares to skip_move, indicating when to use archive instead. Mentions scope requirement ('act') and that it is free. Lacks explicit when-not-to-use scenarios but gives clear 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?

The description adds significant behavioral context beyond annotations: it confirms the tool is not read-only (creates a checkout) and not destructive, explains the automatic upgrade process, specifies the required 'act' scope, and states the enrollment binding. This fully compensates for the lack of annotation details.

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 comprehensive, with a logical flow: purpose, behavior, scope, and constraint. Every sentence adds value without 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?

Given no parameters and no output schema, the description fully covers the tool's purpose, behavior, return value, and constraints. It is complete for an agent to understand when and how to invoke 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?

With zero parameters, the description does not need to explain them. Baseline 4 is appropriate as no additional parameter information is required.

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 creates a Founder-tier checkout link for the user's product run, using specific verbs and resource identification. It distinguishes from sibling tools by specifying its unique role in unlocking Founder controls.

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 explains when to use the tool (to unlock Founder features) and provides context about being reachable on a free trial. It does not explicitly list alternatives 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?

Discloses that the tool creates a checkout link, returns checkout_url, and that credits are added automatically after payment. Notes binding to own enrollment (cannot credit other accounts). Mentions scope requirement. Annotations (readOnlyHint=false, destructiveHint=false) align with description, and description adds substantial 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?

Compact single paragraph that front-loads the main action, then covers parameter, return value, requirements, and alternative. Every sentence adds value. No fluff.

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

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

Despite lacking output schema, the description explains the return value (checkout_url) and post-payment behavior. Covers scope, plan requirements, and alternative for free trial. For a simple tool with one parameter, this is 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?

Schema has 1 parameter with enum and description. The description adds that the founder sees price on checkout page and that pack_id is a refill pack. Since schema coverage is 100%, baseline is 3, but the description provides good additional context about payment flow, so a 4 is warranted.

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?

Clearly states the tool creates a credit top-up checkout link for the current enrollment to refill credits. Uses specific verb 'create' and resource 'top-up checkout link'. Distinguishes from sibling create_checkout by noting different use cases (existing founder plan vs. free trial upgrade).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use (when balance runs out) and when not (on free trial, use create_checkout instead). Names the alternative create_checkout. Lists requirements: 'act' scope and Founder plan. Provides clear context for decision.

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. Description adds valuable context: content types (drafts, ships, etc.), ordering (newest first), and cost (free). This exceeds what annotations provide, though it could mention rate limits or idempotency. 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?

Two sentences, front-loaded with purpose and usage. No filler words; every sentence serves a purpose. Excellent structure.

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 single parameter, no output schema, and annotation coverage, the description provides purpose, usage timing, content overview, ordering, and safety information. An agent can confidently decide to invoke this tool based on the description alone.

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?

Only parameter 'limit' is documented in schema with min, max, default. Description does not add further meaning. With 100% schema coverage, baseline is 3; no extra value contributed.

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?

Description clearly states it retrieves product timeline of growth agent and founder actions, distinguishing it from other get/list tools by specifying content (drafts, ships, skips, etc.) and purpose (avoid redoing or contradicting). Verb 'get' and resource 'activity' are well-defined.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to read before acting to avoid redoing or contradicting recent work, providing strong usage context. However, it does not explicitly mention alternatives or when not to use, hence not a perfect 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it is 'Read-only, free' and includes 'founder's own edits.' No contradiction. Provides additional behavioral context beyond annotations.

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

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

Description is concise (three sentences). Front-loaded with main purpose. Minor redundancy ('measured stat battery') but overall efficient and informative.

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

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

No output schema, but description lists what data is returned (scores, domain info, presence, content freshness). Adequate for a read-only tool with no parameters. Agent can select and invoke correctly.

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

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

No parameters exist, so schema already covers everything. Baseline score of 4 for zero parameters. Description does not need to add parameter information.

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?

Clearly states it retrieves a competitor roster with specific metrics like performance, SEO, accessibility, Core Web Vitals, etc. Differentiates from sibling tools like 'get_seo' or 'get_snapshot' by focusing on competitive analysis. Includes usage context: 'Read before any competitor or outreach work.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Read before any competitor or outreach work' indicating when to use. Does not explicitly mention when not to use or alternatives, but the context is clear enough for an AI agent to infer its primary use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by disclosing that the 'credits' field is conditionally present only when credit metering is live, which is key behavioral context beyond annotations.

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

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

The description is a single, information-dense sentence that front-loads the core purpose and lists fields clearly. It could be slightly improved with more structured formatting, but it is efficient and earns its place.

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

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

Given no parameters and no output schema, the description adequately covers the return fields and behavior (conditional credits). It provides sufficient context for the agent to understand what the tool returns.

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?

No parameters exist, and schema coverage is 100%. Per guidelines, a baseline of 4 is appropriate since there is no need for parameter explanation.

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 specifies that the tool returns 'The product run summary for this AfterLaunch growth engine' and lists the exact fields (product_url, tier, trial_ends_at, timezone, etc.), providing a specific verb+resource and distinguishing it from sibling tools.

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 tool is used to get the enrollment summary, but does not explicitly state when to use it vs. alternatives or provide exclusions. The context is sufficient for typical usage.

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. Description adds context: 'the shared memory the growth marketing engine drafts from', explaining the data's role. 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?

Two efficient sentences: first defines action and output, second provides slug source and examples. No unnecessary words, 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?

With one required parameter and no output schema, description fully covers purpose, input source, and read-only nature. No gaps.

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

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

Schema coverage is 100% with description for 'slug'. Description adds value by explaining that slugs come from 'list_kb_pages' and gives concrete examples, enhancing understanding beyond 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?

Clearly states the verb 'get', resource 'Knowledge Base page', and what it returns ('full markdown body'). Distinguishes from sibling 'list_kb_pages' which lists pages, while this retrieves one by slug.

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 source of slug input from 'list_kb_pages' and lists example slugs. Does not explicitly state when not to use it, but 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 declare readOnlyHint=true, and the description adds transparency by detailing the returned data structures and the logic of two loop sets. No contradictory behavior is mentioned, but it could further describe side effects or authorization needs.

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 concise and front-loaded, but the second sentence is dense with technical details (provisioned vs runnable). Every sentence adds value, though it could be slightly more streamlined.

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 complexity of the loop system and no output schema, the description covers the returned fields (GEO, competitor tracking, channel distribution, autonomy level, runnable_loop_types) and explains the relationship between provisioned and runnable loops. It lacks mention of pagination or limits, but 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?

The schema has 100% coverage with a basic description, but the tool description significantly enriches parameter meaning: it explains that omitting loop_type returns all loops, passing it returns a specific one, and that runnable_loop_types are accepted by run_loop. This adds substantial semantic value.

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 returns provisioned loops and runnable loop types for the product, with specific fields like GEO, competitor tracking, and autonomy level. It distinguishes the tool's purpose from siblings by focusing on loop status, not activity or competitors.

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 when to pass loop_type (single loop) vs omit (all loops) and clarifies the difference between provisioned and runnable loops. However, it does not explicitly compare this tool with sibling tools 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 declare readOnlyHint=true and destructiveHint=false. The description reinforces with 'Read-only, free,' adding behavioral clarity about cost and non-destructive access with 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?

Two sentences with no waste. Front-loaded with the core value proposition, then a usage prompt. 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?

Despite no output schema, the description fully explains return types (clicks, counters, scoreboard, connectivity). For a read-only, zero-parameter tool, this is complete and actionable.

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?

Zero parameters in the input schema, and description does not need to add parameter details. The baseline for 0 params is 4; description implies no configuration 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's purpose: to retrieve outcomes from shipped growth moves, listing specific metrics (tracked-link clicks, counters, scoreboard, GA4/Search Console connectivity). It uses a specific verb ('get') and resource ('outcomes'), and distinguishes from siblings by positioning it as a post-ship_move check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises to call 'after ship_move' to assess move attention, providing clear usage context. Does not explicitly list alternatives or when not to use, but the sibling tool set (e.g., get_activity, get_visibility) implies differentiation.

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 and destructiveHint; description adds 'Read-only' and 'full content body' but does not exceed annotation coverage sufficiently.

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, front-loaded with purpose.

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 single-parameter get tool with no output schema, description adequately explains what it returns and how to obtain IDs.

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 covers 100% of parameters; description adds no extra meaning beyond the schema's 'The output id (uuid).'

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 retrieves one drafted marketing output by id with full content body, distinguishing it from sibling tools like list_outputs.

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 advises using list_outputs to get IDs first, and explicitly marks as read-only, guiding appropriate use among 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?

Adds value beyond annotations by describing the read-only and free nature, and detailing the output composition. Aligns with annotations (readOnlyHint=true, destructiveHint=false) and expands on what data is included.

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?

Concise, front-loaded with key information in three sentences. Every sentence adds value, 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?

Despite no output schema, the description enumerates what the tool returns (issue groups, severity, pages, score trend, CWV, links, domain authority, ranks). Provides sufficient context for a read-only data retrieval 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 100% with a single boolean parameter. The description explains the parameter's effect ('Pass include_pages for the per-page audit detail'), adding context beyond the schema description.

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

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

Clearly states it retrieves a comprehensive site-wide SEO audit, listing specific data categories (issue groups, score trend, Core Web Vitals, etc.). Distinguishes itself from sibling tools like get_competitors or get_visibility by focusing on internal SEO audit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly advises reading this before any SEO work, and notes that seo_fix moves derive from these findings. Provides clear context but no direct comparison to alternatives or when not to use.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by stating it's free, has no arguments, returns the same text as a public URL, and suggests writing it into the repo.

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 concise three-sentence paragraph, front-loading the key purpose and adding necessary details without redundancy. Every sentence serves a purpose.

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, zero-parameter, read-only tool, the description is complete. It explains what the tool returns, its safety profile, and how to use it (write into repo), fully satisfying the needs of an AI 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?

With zero parameters and 100% schema coverage, the baseline is 4. The description adds meaning by explaining no arguments are needed and that the tool is read-only, fully compensating for the lack of parameters.

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 paste-able markdown section for teaching agents about AfterLaunch. It specifies that it's free, read-only, and has no arguments. This distinctly differentiates it from sibling tools, as it's a setup snippet.

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 advises to 'write it into the repo rather than asking the founder to copy it,' providing a clear usage context. While it doesn't explicitly list alternatives or when not to use, it implies this is for initial agent setup.

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 readOnlyHint=true and destructiveHint=false. The description adds context that this is a 'stable business context read' (static snapshot) and declares 'Read-only, free,' reinforcing the safe, non-destructive nature.

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 somewhat verbose and lists many components in a run-on sentence. It could be more structured, e.g., bullet points or clearer separation of what the tool returns.

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, annotations, and no output schema, the description adequately describes the tool's purpose and content. It could mention expected output format or any prerequisites, but it is mostly complete for a simple read 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?

Input schema has 0 parameters, so no parameter documentation is needed. Baseline for 0 params is 4.

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 retrieving a 'Growth Snapshot' with specific components (positioning, discoverability score, etc.) and distinguishes it from siblings like get_visibility and get_seo. However, the phrasing is somewhat convoluted and could be more concise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use alternatives: 'for live signal data use get_visibility and get_seo.' This provides clear guidance on when not to use this tool, aiding 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 and destructiveHint. The description adds valuable context about when to call and what data is returned, without 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?

The description is fairly lengthy but front-loaded with key outputs. Every sentence adds value; no filler. Could be slightly more compact but still effective.

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 output schema, the description fully details the return data. It also covers workflow and parameter usage, making it complete for a read-only tool with one optional parameter.

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

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

Schema coverage is 100% for the single optional parameter. The description adds guidance on when to use prompt_id ('where your plan includes it') and where to get it (prompts list), beyond the schema description.

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

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

The description explicitly lists the data returned: AI visibility metrics (share of voice, per-engine coverage, etc.) and off-site signals. This distinguishes it from siblings like get_competitors and get_seo, making the purpose very clear.

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 clear ordering: call after refresh_scan and before any GEO work. States read-only and free. Though no explicit alternative, the workflow 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds significant behavioral context that goes beyond annotations: it explains what the feed contains, that it returns live moves by default, that include_resolved changes this behavior, and that total_live counts the backlog. 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 a single, well-structured paragraph. It front-loads the most critical information (what the tool returns) and then efficiently covers default behavior, parameter usage, and read-only nature. Every sentence earns its place; there is no redundancy or fluff.

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

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

Given the absence of an output schema, the description adequately summarizes the return fields and behavior. It mentions the count total_live and the effect of include_resolved. However, it does not specify whether pagination or limits apply, which would be useful for a tool that lists items. Still, it is largely complete for the tool's moderate complexity.

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% for the single parameter include_resolved, which already has a description. The tool description adds additional context by restating the parameter's effect ('Default false: live moves only') and explaining the distinction between live and resolved moves, thereby enriching the semantic understanding beyond the schema alone.

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 ('list') with a clear resource ('the ranked backlog of growth marketing moves'). It enumerates the fields returned (title, why it matters, area, status, rank, draft_content body) and distinguishes itself from sibling mutation tools like archive_move or ship_move by being a read-only listing operation.

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 states when to use this tool: 'Read this before improvising any growth, marketing, SEO or launch work of your own.' It also explains the default behavior (live moves only) and how to include resolved moves via the include_resolved parameter, providing clear context. However, it does not explicitly mention when not to use it or name alternative tools for related tasks.

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?

Adds behavioral context beyond annotations: 'Returns summaries with a size hint', 'Read-only, free'. Annotations already indicate readOnlyHint and destructiveHint; description confirms and adds detail about return format and cost (free). 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?

Description is informative but slightly verbose with a parenthetical list. Front-loaded with purpose. Could be more concise, but still 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 no parameters and no output schema, description fully covers purpose, return type (summaries with size hint), relationship to get_kb_page, and safety (read-only, free). Completely adequate.

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?

No parameters; baseline 4 applies. Description does not need to add parameter info. Schema coverage is 100% (none).

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?

Clearly states it lists KB pages, describes the content (shared memory, business basics, etc.), and distinguishes from sibling tool get_kb_page by mentioning it returns summaries and that get_kb_page fetches a single page body.

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 context for when to use this tool (to list KB pages) and when to use get_kb_page (to fetch one page body). Lacks explicit exclusions or alternative tools beyond that, but enough guidance for a simple tool.

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 readOnlyHint=true and destructiveHint=false, so the description's mention of 'Read-only' is consistent but adds minimal value. It lists returned fields but no additional behavioral details like pagination or limits.

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 with two sentences, front-loads the purpose, and provides actionable guidance without 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?

Given no parameters and no output schema, the description covers ordering (newest first), listed fields, and follow-up actions. It is adequate for a simple list tool, though it could mention if results are paginated or limited.

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, and schema coverage is 100%. The baseline is 4, and the description does not need to add parameter semantics.

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 that it lists drafted marketing and distribution content, newest first, and specifies the fields returned. It also distinguishes itself by directing to get_output for full body and approve_output for dispatching, making its purpose distinct from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly tells when to use this tool (to list outputs) and directs to alternatives (get_output for full body, approve_output to dispatch), providing clear guidance on tool 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 indicate non-read-only and non-destructive. Description adds context: free, scope/tier requirements, and that history is preserved. 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 efficient sentences with no wasted words. First sentence fronts the action, subsequent sentences add constraints and behavior. Excellent structure.

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?

Covers manual replacement vs AI, scope/tier, history preservation. For a mutation tool without output schema, this is sufficient. Could briefly mention post-replacement flow (e.g., ready to ship) but not necessary.

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 baseline 3. Description adds value by linking output_id to list_outputs and confirming draft limits, enriching the schema definitions.

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?

Description uses specific verb ('Replace') and resource ('drafted marketing output's body'), clearly distinguishing from sibling tools like update_draft and the AI-driven redraft that stays in the app.

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?

States when to use: before shipping, manual replacement, requires 'act' scope and Founder tier. Contrasts with AI redraft. Could be improved by explicitly specifying when NOT to use, but context is clear.

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

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

Description goes well beyond annotations by revealing that the tool spends money, is bounded by credit balance, and has per-day/tenant spending caps. This is critical behavioral context that annotations do not cover, as both readOnlyHint and destructiveHint are false.

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?

While the description is somewhat lengthy, every sentence adds value (spending, prerequisites, idempotency, daily limits). The opening warning 'SPENDS MONEY' is effectively front-loaded. Minor redundancy could be trimmed but overall efficient.

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 fully explains what happens (scan runs, result replayed if duplicate), prerequisites, cost boundaries, and idempotency. It is complete and leaves no major gaps for an AI agent to invoke correctly.

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

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

Schema coverage is 100%, and description adds meaning to both parameters: the 'scan' parameter is limited to 'ai_visibility' today, and 'idempotency_key' is described as client-minted (1-200 chars) for contract stability, with replay behavior on repeats. This adds value 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 clearly states it runs an on-demand AI visibility scan ('ai_visibility') for measuring how AI answer engines represent the product. It distinguishes this scan from other potential operations by specifying the exact scan type and 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?

It explicitly states requirements: write scope, paid plan/active trial, idempotency key. It also explains that one scan per type per product per day is allowed, with repeats replaying the original result. However, it does not mention when NOT to use this tool or provide direct alternatives from siblings.

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?

Description goes well beyond annotations by warning of financial cost ('SPENDS MONEY'), credit balance limits, rate limits, and idempotency behavior. Annotations only indicate not read-only and not destructive, so description adds critical 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?

Description is a single paragraph that efficiently packs crucial information. The opening 'SPENDS MONEY' is attention-getting but valuable. Every sentence adds meaning, though it could be slightly tighter.

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

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

With no output schema, the description doesn't detail return values, but it explains idempotency replay. Given the tool's trigger nature and one parameter, the description adequately covers context for a competent AI 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 coverage is 100% with a thorough description of idempotency_key. The description mentions the key but adds no new semantic details beyond the schema. 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 clearly states the tool's function: running the growth-move generator to top up the Feed with fresh marketing moves, referencing the in-app equivalent. It distinguishes from sibling tools like list_feed (read-only list) and get_competitors (read-only 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?

Explicitly states prerequisites: 'write' scope, paid plan or active trial, idempotency key. Also specifies limitations: once per day per product, subject to daily/monthly spend caps, bounded by credit balance. This provides clear when-to-use and 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?

The description goes far beyond annotations by disclosing costs (1 credit), required write scope, idempotency behavior (replay on repeat), per-cycle limits, and spend caps. No contradictions 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 detailed but front-loaded with the warning 'SPENDS MONEY'. Each sentence adds value, though it could be slightly more concise. Still, very efficient.

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 output schema, the description covers all necessary context: prerequisites, constraints, cost, idempotency, and scope requirements. 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?

Schema coverage is 100%, so baseline is 3. The description enhances both parameters: for loop_type it adds reference to runnable_loop_types, for idempotency_key it clarifies replay and charge behavior. This extra context justifies a 4.

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 triggers a one-off generation run of a growth marketing loop, with specific examples like linkedin_post and geo_improvement. This verb-resource combination is unique among sibling tools, distinguishing it effectively.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit prerequisites: the loop must be runnable, provisioned, and enabled, with a reference to get_loop_status. It does not explicitly mention when not to use this tool or list alternatives, but the context is clear.

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

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

Annotations indicate a mutation (readOnlyHint=false) and non-destructive operation, which the description confirms. It adds valuable behavioral context: required access scopes, tier restrictions, and channel-specific limitations that go beyond the annotations. 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?

The description consists of two efficient sentences that immediately convey the core purpose and key constraints. Every clause serves a purpose; there is no redundancy or filler, making it easy for an agent to parse quickly.

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 simple input schema (2 required params) and lack of output schema, the description sufficiently covers purpose, prerequisites, and a critical behavioral exception. It could optionally clarify the implications of setting autonomy levels (e.g., effect on loop triggering), but is largely complete for a configuration 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 description lists the enum values for 'level' (review, one_click, autonomous), which duplicates what the schema's enum provides but adds clarity. For 'loop_type', the schema already includes a descriptive example; the description adds no further detail. With 50% schema coverage, the description provides marginal added value.

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 starts with a clear verb ('Set') and resource ('growth marketing loop autonomy level'), enumerating the specific options (review, one_click, autonomous). This distinctly differentiates it from sibling tools like set_loop_cadence or run_loop, which handle other aspects of loop configuration.

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 states prerequisites ('Requires the 'config' scope and Founder tier') and provides a clear exception ('Social and distribution channels never accept 'autonomous''). This gives agents concrete guidance on when and how to use the tool, as well as 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?

Discloses that the tool modifies cadence and that setting 'default' clears overrides. Adds value beyond annotations (which are minimal), but does not mention timing of effect (e.g., immediate or after current run).

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, front-loaded with purpose and critical constraints, no redundant 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?

Covers all essential aspects: what it does, required scopes, constraints, and parameter semantics. Missing only a note on when changes take effect, which is minor given tool simplicity.

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 covers loop_type with example, but cadence only has enum. Description explains the meaning of each cadence value, especially 'default', compensating for low schema 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?

States the action 'set how often a growth marketing loop runs' with specific resource 'loop cadence'. Distinguishes from sibling tools like run_loop and set_loop_autonomy.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly requires 'config' scope and Founder tier, and warns that you can only slow or pause, never speed up. Provides clear context for when to use.

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

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

Discloses that the tool is non-destructive, idempotent, never posts to channels, and requires specific authorization, adding value beyond the annotations which are minimal.

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?

Concise, front-loaded, each sentence adds meaningful context without 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?

Given no output schema, description fully explains behavior, side effects, and constraints, making it complete for the tool's purpose.

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?

Description adds context to both parameters (e.g., action meanings, output_id origin) that enriches the schema descriptions which are already present.

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 resolves a drafted marketing output with actions 'ship' or 'skip', and distinguishes itself from approve_output by emphasizing it never posts to a channel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly contrasts with approve_output for real publishing, and mentions required scope ('act') and tier (Founder).

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 discloses that the tool modifies state (marks shipped), requires the 'act' scope, is free, and has a specific condition for asset_url. Annotations only show non-read-only and non-destructive, so the description adds valuable behavioral context beyond the structured data.

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

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

The description is three sentences with no fluff. The first sentence delivers the primary purpose, the second adds scope and cost, and the third clarifies the optional parameter. All information is front-loaded and essential.

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 simplicity of the action (marking shipped) and no output schema, the description is mostly complete. It could mention the resulting state or confirmation, but the core behavior is covered. Sibling tools are listed but not contrasted, which slightly reduces completeness.

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 descriptions for both parameters. The description adds that move_id comes from list_feed and asset_url is for a live asset. This enriches the schema definitions but does not provide extensive additional detail.

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 marks a growth move as shipped, equating it to the founder's Ship button. It specifies the action is free and requires the 'act' scope. The resource (growth move) and verb (ship) are explicit, and the condition for asset_url distinguishes it from simply marking shipped.

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 a usage context: 'the same action as the founder's Ship button in the Feed.' It also specifies when to use asset_url. However, it does not explicitly guide when to choose this tool over siblings like skip_move or archive_move, though the purpose implies exclusive use for shipping.

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 already indicate non-destructive behavior (destructiveHint=false) and that it is not read-only (readOnlyHint=false). The description adds that feedback improves future drafts, but does not disclose what happens after dismissal (e.g., whether the move can be undone or is permanently removed). Since the annotations cover the safety profile, the description adds incremental value.

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 first sentence introduces the action and permission, and the second covers the optional parameters and their purpose. Every part is necessary and well 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 simple dismissal tool with 3 parameters, good annotations, and no output schema, the description covers purpose, permissions, and parameter semantics adequately. However, it could mention that the action is reversible via 'undo_move' (a sibling) for full completeness.

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 all parameters described. The description adds value by explaining that feedback improves future marketing drafts and that unknown feedback_key values are ignored by the learning loop. These details go beyond the schema, earning a score above baseline 3.

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

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

The description clearly states it dismisses a 'growth move', with a specific verb and resource. It also equates it to 'Skip in the Feed', providing immediate context. Although it does not explicitly differentiate from siblings like 'archive_move' or 'undo_move', 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 mentions it is free and requires the 'act' scope, giving clear context for when to use. It also explains the optional feedback parameters and their benefit. However, it does not explicitly state when not to use this tool or mention alternatives such as 'undo_move' for reversal.

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=false, destructiveHint=false), the description adds important behaviors: idempotency on pending moves, that it never unwinds real channel publishes, and that archived/expired moves cannot be restored. This provides rich 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 a single paragraph of three sentences, with the main action front-loaded. Every sentence adds value without redundancy or unnecessary detail.

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 one parameter, no output schema, and annotations present, the description covers purpose, usage, behavioral traits, and limitations comprehensively. It addresses the undo action fully, including what it cannot do.

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

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

With 100% schema description coverage, the schema already describes the move_id parameter fully. The description adds no new parameter semantics beyond what is in the schema, so 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 clearly states the tool restores a just-shipped or just-skipped growth move to pending, identifying the specific resource and action. It distinguishes from siblings by being the inverse of ship_move and skip_move, and mentions it mirrors the founder's Undo in the Feed.

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 says it's the self-correction verb for a wrong ship_move or skip_move, telling when to use it. It also states what it does not do (unwind channel publish, restore archived/expired moves) and mentions the required 'act' scope, providing clear usage boundaries.

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 set readOnlyHint=false and destructiveHint=false, consistent with a modification that overwrites content. The description adds value by noting it's 'Free' and requires scope, providing practical constraints beyond basic 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?

A single sentence plus a short qualification ('Free; requires the 'act' scope.') is extremely concise and front-loaded with the core purpose. No extraneous 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 tool with no output schema and straightforward parameters, the description provides sufficient context (when to use, prerequisites). It could mention what 'pending' means or behavior if not pending, but 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% with clear descriptions for both parameters (move_id from list_feed, draft_content with length constraints). The description does not add new semantic information 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 clearly states 'Replace a pending growth move's marketing draft body with an edited version before shipping', specifying the verb, resource, and context. It distinguishes from sibling tools like ship_move and skip_move.

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 indicates when to use ('before shipping') and prerequisites ('requires the 'act' scope', 'Free'). It does not explicitly exclude cases or mention alternatives, but the context is clear.

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

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

Beyond annotations (readOnlyHint, destructiveHint), the description details the exact return fields (enrollment, key, scopes, product identity) and conditional credit field, providing full behavioral 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 two sentences, front-loaded with the purpose, and every sentence provides necessary information without 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?

Given no parameters and no output schema, the description fully explains all return fields and conditional behavior, making it complete for the tool's context.

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?

No parameters exist; schema coverage is 100%. The description adds meaning by explaining all return values, which is the relevant information for a tool with no 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 clearly states the tool's purpose: confirming the AfterLaunch API key works and returning specific details. It distinguishes itself from sibling tools by being a preliminary check 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 gives explicit usage guidance: 'Call this first.' This implies it should be used before other tools, but lacks explicit 'when not to use' or alternatives.

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