AfterLaunch

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

Annotations indicate a non-read-only, non-destructive operation. The description adds valuable context: 'Free' (no cost), 'requires the act scope' (authorization), and 'Idempotent on an already-archived move' (repeated calls safe). It also clarifies the semantic distinction from skip, providing behavioral nuance not captured by 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 extremely concise: two sentences covering purpose, differentiation, cost, scope, and idempotency. No filler or redundancy. The key verb and resource are front-loaded, making it easy to scan.

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 tool with one parameter, the description is fully sufficient. It covers what, when, prerequisites, cost, and behavioral guarantees. No output schema exists, but the tool is a mutation, and the description does not need to explain return values. Siblings are acknowledged via the skip contrast, making it contextually 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%: move_id is described as 'Move id (uuid), from list_feed.' The description adds no extra parameter detail, which is acceptable since the schema fully documents the single parameter. 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 opens with 'Archive a growth move', a specific verb+resource that clearly states the action. It further distinguishes itself from sibling tools by contrasting with skip: 'a lighter dismissal than skip, with no verdict recorded'. This makes its purpose unambiguous and differentiates it from skip_move and dismiss_gap.

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 contrasts with skip, signaling when to choose archive over skip (lighter dismissal, no verdict). It also notes the prerequisite 'act' scope and idempotency, which guide safe repeated use. However, it does not explicitly mention alternatives beyond skip or state a 'when not to use' clause, leaving a small gap.

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 sparse annotations (readOnlyHint=false, destructiveHint=false), the description reveals the return value ('Returns a checkout_url'), the side effect ('the upgrade lands automatically once payment succeeds'), the auth requirement ('Requires the 'act' scope'), and scope binding ('always bound to your own enrollment'). This gives the agent a thorough behavioral 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?

The description is two sentences, front-loaded with the primary action, and every clause adds necessary information: the thing created, the output URL, the post-payment effect, free-trial availability, auth scope, and self-binding. 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 zero-parameter tool with no output schema, the description covers everything an agent needs: what it does, what it returns, what happens after payment, when it is available, and what permissions/scope apply. It is a complete operational specification for this use 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?

There are zero parameters, so the schema leaves nothing to document. The description adds semantic value by explaining the implicit context ('THIS product run', 'bound to your own enrollment'), which tells the agent why no parameters are needed and how the tool is scoped. Baseline 4 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 opens with a specific verb and resource: 'Create a Founder-tier checkout link for THIS product run.' It clearly distinguishes itself from siblings like create_topup by explicitly naming the output (checkout_url) and the purpose (unlocking Founder-only growth 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?

The description provides clear context: 'Reachable on a free trial because it is the path TO Founder' tells when to use this tool. It doesn't explicitly exclude alternatives among the siblings (e.g., create_topup), but the context makes the intended use unambiguous.

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 behavioral context beyond the annotations (readOnlyHint=false, destructiveHint=false): it states the tool returns a checkout_url, that credits land automatically after payment, and that it requires specific auth and plan. It also mentions the enrollment binding, enriching the agent's understanding of side effects and constraints.

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 carrying distinct information: purpose, parameter, return/behavior, and auth/alternative/enrollment. No filler or repetition, and the most critical action is front-loaded. Perfectly sized for the tool's 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?

Given only one parameter and no output schema, this description covers all necessary aspects: what the tool does, how to use the parameter, what is returned, what happens after payment, required scope/plan, and an exclusion for free trials. It is fully self-contained 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 schema already provides 100% coverage with the enum and description for pack_id. The description repeats the enum values and adds a small detail ('The founder sees the price on the checkout page'), which is minor incremental value. This matches the baseline for high 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?

The description clearly states it creates a credit top-up checkout link for the current product run, using the specific verb 'Create' and resource 'credit top-up checkout link'. It distinguishes from sibling create_checkout by explicitly mentioning 'on a free trial use create_checkout first', and adds scope with 'THIS product run' and 'Always bound to your own enrollment'.

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

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

Explicit guidance is given on when to use this tool versus create_checkout: 'Requires the "act" scope and the Founder plan (on a free trial use create_checkout first)'. This provides clear conditions and names the alternative tool, which is exactly what effective usage guidelines need.

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 strongly implies a destructive action by stating it 'delete[s] the credential stored for it' and 'revoked at Google', yet the annotations declare destructiveHint=false. This is a direct contradiction. The readOnlyHint=false is consistent, but the destructiveHint mismatch forces a score of 1 per rules.

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 (three sentences), starts with the action verb, and covers idempotency, effect, and caution. The final 'Free.' is slightly extraneous but non-hindering, keeping the overall structure 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?

For a simple one-parameter tool with no output schema, the description covers the main behavior, idempotency, impact on measurement, and a user confirmation requirement. The only omission is the exact return value, but that is not critical given the tool's 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?

The schema already fully describes the 'provider' parameter with allowed values. The description adds meaningful provider-specific nuance by noting that for Google the credential is also revoked, which isn't in the schema. This extra context enhances parameter understanding.

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

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

The description clearly states the verb 'Disconnect' with a specific resource type ('growth data source or distribution channel') and additional detail about credential deletion and Google revocation. This distinguishes it from sibling tools like start_connection and list_connections.

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 on when to use the tool (to disconnect a data source or distribution channel), its effect (narrows what the growth engine can measure), and a caution to confirm with the founder first. It does not explicitly contrast with alternatives, but the 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?

The description discloses behavioral outcomes beyond annotations: it resolves the gap in one place (stops being re-proposed on the growth Feed), improves future ranking via the reason, and is idempotent. It also mentions cost/plan availability. This adds significant context to the readOnlyHint/destructiveHint 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 yet comprehensive: it covers what, why, comparison, effect, cost, scope, and idempotency in a few sentences with no fluff. Every clause adds value and is 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?

Despite lacking an output schema, the description fully explains the tool's behavior, effects, prerequisites, and edge cases (already shipped/archived). It also differentiates from siblings and covers all relevant context for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so baseline is 3. The description reiterates that prompt_id and prompt_text are required together but does not add new meaning beyond what the schema already states. No additional parameter clarification is provided.

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: 'Set aside one AI visibility (GEO) gap the founder is not going to act on.' It also distinguishes itself from the sibling tool skip_move by specifying 'The same verdict as skip_move, on the AI visibility surface,' clarifying the exact scope and differentiating it from alternative actions.

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 describes when to use it: 'a tracked question where rivals get named and this product does not' and 'the founder is not going to act on.' It contrasts with skip_move, provides prerequisites ('requires the act scope'), and explains the idempotent behavior, giving clear context 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?

Annotations already declare readOnlyHint=true and destructiveHint=false; the description adds valuable behavioral context by specifying the content scope (actions and rationale), ordering (newest first), and the cost profile ('free'). 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?

Two sentences, zero filler. The first sentence immediately states the resource and nature; the second gives a practical usage directive. Every word contributes.

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 tool with one optional parameter and no output schema, the description fully covers what it returns, the ordering, and when to use it. No gaps remain for an agent to invoke it correctly.

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

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

The input schema provides 100% coverage for the single 'limit' parameter with a clear description. The tool description adds no new parameter-level details, so the baseline of 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 opens with 'The product timeline' and enumerates exactly what it shows (drafts, ships, skips, scans, observations, decisions) with rationale, newest first. This clearly distinguishes it from sibling tools like get_standup, list_feed, and get_scoreboard, which cover different domains.

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 phrase 'Read before acting so you never redo recent work' provides explicit contextual guidance for when to invoke the tool. It doesn't enumerate when not to use it or name alternatives, but the action-oriented 'read before acting' is sufficient for this read-only timeline 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds content details and the 'free' aspect, but no additional behavioral traits like auth requirements or rate limits. Given the annotations, a score of 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?

The description is composed of three sentences. The first lists the content with useful specifics, the second gives usage guidance, and the third repeats the read-only nature already covered by annotations. It is mostly concise and front-loaded, but the third sentence is slightly redundant, preventing a 5.

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

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

With no output schema and no parameters, the description fully conveys what the tool returns (the stat battery components) and when to use it. It is complete for a simple read-only tool, covering content, usage, and safety implicitly through annotations.

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

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

The tool has zero parameters, and the schema is empty. The baseline for 0 params is 4, and the description correctly focuses on the return content rather than parameter details, adding value through the stat battery enumeration.

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 specifies what the tool returns: a competitor roster with measured stat batteries for the user and each rival, listing specific categories. It also states it includes the founder's own edits. This is specific and distinguishes it from sibling tools like get_seo or get_scoreboard, which focus on different domains.

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 the tool: 'Read before any competitor or outreach work so a rival is never treated as a pitch target.' This provides clear context, though it does not mention alternatives or when-not-to-use, so it falls short of 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. The description adds 'Read-only, free' and notes 'Credits once metering is live,' providing future cost context beyond the annotations. No contradiction, though the added depth is modest.

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 the tool's purpose and content list. The 'Credits once metering is live' fragment is slightly cryptic but does not waste space.

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 tool, the description enumerates the returned fields and explicitly states read-only/free. The metering note adds a behavioral caveat. Adequate coverage for the tool's 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?

The schema has zero parameters, so the description has nothing to explain. 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?

Clearly identifies the tool as returning the product run summary for the growth engine, with a specific list of fields. However, it does not explicitly differentiate from sibling get_* tools, so it is clear but not fully distinct.

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?

No explicit guidance on when to use this tool vs alternatives. It implies use for growth engine summary data, but there is no mention of when to choose it over get_snapshot, get_activity, or other 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, free.' It adds useful behavioral details by stating the full markdown body is returned and that this page serves as the source record for drafting. 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 short sentences with no filler. The description front-loads the main purpose, then adds usage context and a safety note. 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 single-parameter get-by-slug tool with no output schema, the description tells the agent what the return contains (full markdown body), where to obtain the slug (list_kb_pages), and that it's safe to call. This is complete for the tool's 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% and the schema already describes slug as 'The page slug, from list_kb_pages.' The description repeats this information without adding new semantics, so the baseline of 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 states 'One Memory page by slug, with its full markdown body' which clearly identifies the resource and the retrieval verb. It also differentiates from list_kb_pages by explaining this returns a single page, and adds context about its role as 'the record the growth marketing engine drafts from.'

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 'Slugs come from list_kb_pages', providing a clear source for the parameter and implying when to use this tool (when you have a slug from that list). This is strong context, though it doesn't explicitly enumerate when not to use 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 mark the tool as read-only and non-destructive. The description adds meaningful behavioral context: it enumerates the categories (AI visibility, competitors, channel distribution) and clarifies the provisioning/enabling prerequisite for runnable types—useful nuance 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 short (two sentences) but the first sentence is a dense, grammatically fragmented noun phrase that is somewhat hard to parse. It packs useful information, but the structure could be clearer.

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 getter with one optional parameter and no output schema, the description sufficiently conveys the key return contents (loops, autonomy level, runnable types) and the important caveat about provisioning. It does not explain the effect of the loop_type filter, but the schema already documents that 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?

The schema covers the single optional loop_type parameter 100%, including an example. The tool description does not add further semantics about how the parameter filters results, so it stays at the baseline for full 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?

The description names the specific resource (automated growth marketing loops) and the aspects returned (autonomy level, runnable_loop_types). It implicitly distinguishes from sibling tools like run_loop by noting what run_loop accepts, though it lacks a direct verb like 'returns' or 'lists'.

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 second sentence implies when to use this tool: 'A runnable type only runs once a loop of that type is provisioned and enabled here.' This suggests checking this status before running a loop, but there is no explicit when-to-use or when-not-to-use guidance relative to 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 declare readOnlyHint and destructiveHint, and the description reinforces with 'Read-only, free.' It adds rich behavioral context beyond annotations: details of the returned content (drafted body, evidence, receipt, acceptance criteria), and the conditional 'tracked_link rides when one exists; this door reports one, never mints one.' This fully discloses what the tool does and does not do.

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 rich and front-loaded with the core purpose, but the first sentence is an extremely long list that could be broken up for readability. Still, every clause contributes meaningful detail, and the overall length is justified given the complexity of the returned object.

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 has only one simple parameter and no output schema, the description provides thorough context: what the move includes, the relationship to ship_move, the tracked_link caveat, and safety (read-only, free). It is complete enough for an agent to understand when and how to invoke this tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning to the move_id parameter beyond what the schema already states, but it implicitly clarifies the purpose of the ID by describing what the returned move contains. 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 what the tool does: returns 'One growth move in full: everything needed to write its deliverable yourself.' It specifies the resource (a growth move) and the action (getting/reporting it), and distinguishes it from related tools by noting it 'reports one, never mints one' and references ship_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?

Explicitly states when to use: 'Read it before writing any move, then ship_move once the founder is happy.' It positions itself as a prerequisite to writing, and contrasts with ship_move, giving clear contextual guidance. The schema further notes move_id comes from list_feed or get_standup.

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 readOnlyHint=true and destructiveHint=false; description confirms 'Read-only' and adds 'free' and the prerequisite of calling after ship_move. It does not discuss rate limits, but given the simple read-only nature, this is adequate.

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 the data list, followed by usage and cost. No 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 zero-parameter, read-only tool with annotations and no output schema, the description adequately covers return content and call timing. It is complete enough for an agent to select and invoke.

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 are no parameter semantics to explain. The description instead clarifies the meaning of 'outcomes', adding value beyond the empty 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 identifies the tool as returning outcomes of shipped growth moves, enumerating specific metrics (tracked-link clicks, shipped counters, scoreboard, connection status). It lacks an explicit active verb like 'retrieves' but is unambiguous and distinct from siblings like get_scoreboard or get_output.

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 temporal guidance: 'Call it after ship_move.' Does not list alternative tools or when not to use, but this is sufficient context for a simple reporting 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 declare readOnlyHint=true and destructiveHint=false, so the description's 'Read-only, free' adds little safety info. However, it adds valuable behavioral context: the response includes the 'full content body' and that ids are sourced from list_outputs. This goes beyond the annotations without contradicting them.

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 compact three-clause sentence (~20 words) that front-loads the core purpose. It includes no redundant filler; each clause provides distinct, useful information: what it returns, how it is fetched, and the id source.

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 getter with one parameter, no output schema, and strong annotations, the description adequately covers what the tool does, what the response contains, and how to obtain a valid id. The sibling tool list_outputs provides listing context, making this description complete for the intended use.

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 output_id, providing a baseline of 3. The description adds meaning by explaining that ids come from list_outputs, helping the agent understand how to populate the parameter with valid values. This is a useful supplement to the schema's bare uuid 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 clearly states the tool retrieves 'one drafted marketing output by id' with its 'full content body'. It distinguishes from sibling tools like list_outputs by focusing on a single entity, and from other get_* tools by specifying the resource type and content.

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 phrase 'Ids come from list_outputs' provides explicit context on the typical workflow: first list outputs, then retrieve a specific one. This is clear guidance, but it does not explicitly exclude alternative tools or state when not to use the tool, 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 declare readOnlyHint and destructiveHint, so the description adds value with 'Read-only, free' and, more importantly, a detailed explanation of the like_for_like field's true/false/null semantics and the warning not to report deltas unless true. This is meaningful behavioral 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 contains useful details but is somewhat verbose and redundant: the opening rhetorical question is not essential, and the ALWAYS/Never sentences overlap. The phrasing 'The proof read for a period' is also awkward. Still, it front-loads the core purpose and keeps the critical caveat.

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 does a good job of listing the scoreboard's key components and thoroughly explains the like_for_like flag's interpretation. It lacks a formal return-structure description but covers the most important fields and semantics for a read-only summary 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 input schema already provides 100% coverage for the single parameter, including default and clamping behavior. The description adds no additional parameter semantics, 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 clearly identifies the tool as a period scoreboard covering AI visibility at start/end, moves shipped, scans, and receipts, which distinguishes it from narrower siblings like get_visibility or get_outcomes. However, the awkward phrasing 'The proof read for a period' obscures the otherwise clear 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 opening question 'Did the growth work move anything?' sets a clear use case, and the explicit instruction to always check like_for_like before reporting a change provides actionable guidance. It does not explicitly name alternative tools or say when not to use this tool, 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 declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond that: it's 'free,' it's the source for seo_fix moves, and it lists the types of data returned. 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 and front-loaded with the purpose, followed by usage and parameter guidance. Each sentence earns its place: purpose, prerequisite context, and parameter hint. 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 simple read-only tool with one optional parameter and no output schema, the description is complete. It explains the tool's role in the broader workflow (seo_fix moves), what it returns, and how to get more detail. Annotations cover safety, and the schema covers the 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 parameter include_pages, which already describes its effect. The description mentions 'Pass include_pages for the per-page detail,' but this essentially restates the schema. Baseline 3 is appropriate given high 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?

The description clearly states the tool's function: 'The site-wide SEO audit' followed by a specific list of outputs (issue groups, severity, affected pages, weekly score trend, etc.). This specific verb-resource pairing (get + SEO audit) distinguishes it from sibling tools like get_competitors or get_visibility.

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: 'Read before any SEO work of your own.' It also explains the tool's relationship to seo_fix moves, indicating it's a prerequisite. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by noting it's 'Free' (no cost) and 'paste-able', and by stipulating the need for founder approval. These details go beyond the annotations and provide useful 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 well-structured: the first sentence delivers the core purpose, followed by two short clarifying sentences on cost/read-only and the approval workflow. Every sentence earns its place; 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?

Given no parameters and no output schema, the description fully conveys what the tool returns, its intended use, the workflow, and cost implications. It is complete and self-contained for an agent to 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?

With zero parameters, the baseline is 4. The description does not need to explain parameters; it focuses on the output and purpose, which is appropriate. No parameter information is missing.

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 a paste-able section for CLAUDE.md/AGENTS.md, specifying its content (how to use AfterLaunch for growth, marketing, SEO, etc.) and distinguishing it from sibling tools by focusing on setup documentation. The verb 'get' is implied through 'paste-able section'.

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

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

It gives clear context: use this to obtain a snippet for repository documentation. It also provides an explicit workflow step ('Show it to the founder and add it with their say-so'), indicating when to use it. However, it does not explicitly mention alternatives or when not to use it, so it's not a full 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only, free.' It also adds useful behavioral context: the data is a stable baseline, not live signals. 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 two sentences long. The first lists the contents of the snapshot, the second provides usage alternatives and cost. Every word earns its place; 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?

With no parameters and no output schema, the description adequately covers what the tool returns and when to use it. The enumerated data contents and the live vs stable distinction make this a complete description for a simple read-only 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 description has no need to explain parameters. The baseline of 4 applies as the description fully compensates by explaining what data is returned.

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's resource as 'The Growth Snapshot' and enumerates its contents (positioning, discoverability score, leverage actions, competitor set, baselines). The purpose is unambiguous even without an explicit verb like 'retrieves'. It also distinguishes itself from sibling tools by contrasting with live-signal 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 explicitly states when to use the tool: 'for live signal data use get_visibility and get_seo.' It labels the snapshot as 'stable business context', giving clear selection criteria. This is a strong example of usage 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 declare readOnlyHint=true and destructiveHint=false, and the description reinforces with 'Read-only, free'. It adds valuable behavioral context beyond annotations by explaining rank gap semantics, the uniqueness of needs_you, the cap on while_you_were_gone, and the deep scan status indicator. This exceeds the safety-only disclosure provided by 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 information-dense and front-loaded with the core purpose. The first sentence is long with embedded parentheticals, but each clause adds essential meaning and there is no fluff. It could be split into more sentences for readability, but it remains efficient given the complexity of the response 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?

Since there is no output schema, the description carries the full burden of explaining return values. It enumerates all major fields (receipts, ready, needs_you, while_you_were_gone, deep scan status), explains the rank/gap logic, provides usage ordering, and includes a read-only note. This is comprehensive for a zero-parameter 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?

The tool has zero parameters, so schema description coverage is 100% and there is nothing to clarify. Per the baseline rule for 0-parameter tools, a score of 4 is appropriate; the description focuses on output semantics instead.

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 a daily growth marketing standup with specific components (receipts, ready, needs_you, while_you_were_gone, deep scan status). It uses a specific verb phrase 'in one call' and distinguishes itself from list_feed by explicitly instructing to call it before list_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?

It provides explicit when-to-use guidance: 'Call this at the START of a session, before list_feed'. It also directs the agent to relay the message field after invocation, which is actionable context. This is sufficient and clear, even though it only names one alternative (list_feed).

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 readOnlyHint and destructiveHint annotations, the description discloses that every reading has a sample count, and changes should be treated as indicative unless the sampling block says otherwise. It also clarifies the read is free and specifies the operational order, adding valuable 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 slightly lengthy due to an exhaustive list of metrics, but each sentence serves a purpose: the first defines the resource, the second adds a sampling caveat, and the third gives usage order and parameter guidance. The main purpose is front-loaded, making it efficient despite density.

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 lists all return aspects (share of voice, cited sources, competitor gaps, trend, crawlability, etc.) and includes important sampling caveats. It lacks structural details like response format or pagination, but the tool is a read-only getter with a single optional parameter, so 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?

The input schema already covers 100% of the parameter descriptions, and the description merely repeats the same drill-down behavior without adding new semantic detail. Baseline of 3 is appropriate because the schema does the heavy lifting; no additional meaning is provided beyond what's structured.

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

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

The description explicitly states the tool returns measured AI visibility (GEO) results across specific engines (ChatGPT, Gemini, Perplexity, Google AI Overviews) and lists concrete data points (share of voice, cited sources, gaps, trend, crawlability). This clearly distinguishes it from siblings like get_seo or get_scoreboard by focusing on AI/GEO visibility.

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 sequencing guidance: 'Read after refresh_scan and before any AI visibility or GEO work.' It also advises interpreting changes with caution due to sampling, and mentions the optional prompt_id for drill-down. This establishes clear when-to-use context without relying on sibling names.

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, so the bar is lower. The description adds useful context about the output states (connected, not_connected, not_available) and that a reason is provided for not_available, plus 'free'. It does not contradict annotations and provides behavioral detail 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 concise and well-structured: it opens with the core purpose, then explains the output semantics, then gives usage guidance, and ends with read-only/free. Every sentence earns its place; there is 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 zero-parameter, read-only status listing tool, the description is complete: it covers what is returned, the possible states, the reason field, and when to use it. No output schema exists, so the description fully carries the burden and does so effectively.

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 has zero parameters, so the baseline is 4. The description adds meaning by explaining what the tool lists and what the state values represent. There is no parameter information to compensate for, and the description fully serves that role.

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 the tool lists which growth data sources (GA4, Search Console, Google Business Profile) and distribution channels (LinkedIn/Reddit) are connected, and that each row carries a state. This distinguishes it from sibling tools like start_connection or disconnect_connection, which perform actions rather than list status.

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

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

It explicitly instructs to 'Read before start_connection so you never offer a connection that cannot be made', which tells the agent when to use this tool relative to a specific sibling. It does not explicitly state when not to use it or mention alternatives like poll_connection, so it stops short of a full 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which the description reinforces with 'Read-only.' Beyond annotations, it discloses that the tool omits drafted bodies (unless verbosity=full) and that live moves are returned by default unless include_resolved is passed. This adds behavioral context around filtering and content availability.

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 earning its place: what the list contains, the primary usage guidance, and critical filtering/behavior clarifications. Front-loaded with the core value proposition.

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 read-only list tool with 3 optional parameters and no output schema, the description is complete. It names the returned fields, highlights the relationship to get_move, and covers all parameter-driven behavior changes. No gaps material to usage.

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 descriptions cover 100% of parameters, so baseline is 3. The description adds context for 'since' ('what is new while the deep scan fills the board') and clarifies that verbosity controls body inclusion, but these are minor additions over the schema's own detailed parameter docs.

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 a ranked backlog of growth marketing moves with specific fields (title, why, area, status, rank, has_draft). It distinguishes from sibling get_move by noting 'The drafted BODY is not here: call get_move for the one you are working on.'

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-to-use: 'Read it before improvising growth work of your own.' It also gives alternative: 'call get_move for the one you are working on' and explains conditional parameters like include_resolved and since.

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 that this tool returns summaries with a size hint and is 'free,' providing useful context beyond the annotations. 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?

The description is a single, information-dense sentence that conveys purpose, output, alternative, and cost without any wasted words. The front-loaded resource definition helps orientation.

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 list tool with annotations, the description covers the key aspects: what the pages are, what the tool returns, and how to get the full body. It does not mention ordering or pagination, but these are likely secondary for this 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 coverage is trivially 100%. No parameter explanation is needed, and the description does not attempt to add any. Baseline 4 for zero-param tools 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 identifies the resource ('Memory pages') and the output ('Summaries with a size hint'), and distinguishes from get_kb_page. The verb 'list' is implied by the tool name rather than stated explicitly, but the description makes the function 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 explicitly directs users to get_kb_page for fetching a body, providing a clear alternative. It also notes 'Read-only, free,' which sets expectations for when to use this 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 declare readOnlyHint and destructiveHint, and the description reinforces this with 'Read-only, free'. It adds behavioral context with 'newest first' ordering and mentions the field list. This is meaningful but not extensive, which is acceptable given the low complexity of a parameterless list tool.

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

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

The description is a single sentence that front-loads the purpose, then provides the fields and a pointer to get_output. No unnecessary words 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?

For a parameterless list tool with no output schema, the description is complete: it states what content is listed, the sort order, the fields returned, and how to retrieve the body. It is a straightforward tool, and the description covers all needed 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?

The tool has zero parameters, so there is nothing to document. The description still adds value by stating the output structure and ordering, earning a baseline of 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 uses the specific verb 'list' and clearly states what is returned: drafted marketing and distribution content for this product, newest first, including the exact fields (id, loop_type, kind, status, title). It also distinguishes itself from get_output by directing users to use an id with get_output for the 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?

The description provides clear guidance on when to use this tool (to list drafts) and explicitly points to get_output for the body, which serves as an exclusion. It does not compare with other sibling list tools, but the context is sufficiently 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 the readOnlyHint annotation, the description discloses return order, the hard cap of 15, the 'used' count, and the meaning of the 'curated' flag. This gives the agent a clear mental model of the tool's behavior without needing to call it.

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 front-loaded with the resource definition and returns details, and every sentence adds value. However, the first sentence is grammatically awkward ('the AI visibility (GEO) question set every measurement is taken against'), slightly denting clarity.

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 list tool with no output schema, the description covers the return payload (prompts, ordering, cap, used, curated), usage context (before track/untrack), and operational notes (read-only, free). This is complete for the agent to invoke and interpret results.

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 schema provides no parameter semantics. The description adds output semantics and context, but there are no params to explain. Baseline 4 for 0-param tools 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: 'the buyer questions AfterLaunch tracks' and the action: 'Returns prompts in tracking order, cap (a hard 15) and used'. It distinguishes the tool from siblings by explicitly linking to track_prompt/untrack_prompt, making it obvious this is the read-only listing counterpart.

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 directs when to use: 'Read before track_prompt or untrack_prompt so you never duplicate a question or guess at the room left.' This provides unambiguous timing and purpose relative to related mutation tools, fulfilling the when-to-use requirement.

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, destructiveHint), the description explicitly states 'Idempotent: nothing is spent or consumed. Read-only, free.' This adds important behavioral context about side effects and costs. It also enumerates all possible outputs, enhancing 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 front-loaded with a clear question and provides all necessary details in a compact form. It is somewhat conversational and slightly longer than necessary (e.g., the question format could be more direct), but every sentence contributes valuable information, so it earns a 4.

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 sufficiently covers the tool's behavior: it explains the input, all possible statuses (pending, connected, expired, not_found), and how to handle each (wait or re-mint). It also notes idempotency. This is complete for a read-only polling 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 the poll_token parameter already described as 'The poll_token start_connection returned.' The description repeats this same instruction without adding additional semantics, so it meets the baseline for full schema coverage but does not go beyond.

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 indicates the tool polls the status of a connection, using a question to frame the purpose ('Did the founder finish connecting...?'). It specifies the resource (growth data source connection) and reports statuses (pending, connected, expired, not_found), distinguishing it from siblings like start_connection and list_connections.

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 the agent to pass the poll_token returned by start_connection. It also provides actionable guidance for each status: wait poll_after_seconds and ask again for pending, mint a fresh link for expired. This is clear when-to-use and what-to-do 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?

Beyond the readOnlyHint=false annotation, the description discloses that recording the same insight twice replaces the earlier note, that pinned notes are left unchanged, that it requires the 'act' scope, and what the return value contains. This is thorough behavioral disclosure that complements the sparse 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 lengthy but well-structured with labeled sections (WHEN, Never record, WHAT COMES BACK). Each sentence adds necessary context, though it could be tightened without losing key information. The front-loading of the core action helps, and the format is 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?

With no output schema and only two boolean annotations, the description carries the full burden. It covers purpose, timing, examples, exclusions, side effects, return value, and authentication scope. Very complete for a write tool of this 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%, so the baseline is 3. The description adds extra semantics by requiring the insight to be 'one sentence in the founder's own terms' and reinforcing that it must be heard, not inferred. It also maps kind values to the examples, adding context beyond the schema's already detailed 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 specific verb-resource pair: 'Write one durable thing you have learned about this founder or their product into AfterLaunch's Memory.' It clearly distinguishes from siblings by explicitly warning not to restate get_snapshot or get_kb_page, and by framing recording as a distinct 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 'WHEN' section states exactly when to use it ('the moment the founder tells you something that will still be true next month') and the 'Never record' section provides explicit negative guidelines (no chatter, moods, or restatements). It also names specific sibling tools to avoid confusing with this one, giving strong when-to-use versus when-not-to 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 sparse annotations by disclosing specific validation rules ('draft carrying an unfilled placeholder or a broken link is refused'), safety behavior ('previous draft is kept as revision history'), and access requirements ('requires the 'act' scope and Founder tier'). These are valuable operational details not encoded in the annotations.

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

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

The description is three sentences: the first sentence states the core purpose and timing, the second clarifies manual-only behavior, and the third provides validation/versioning details plus access requirements. Every sentence adds distinct value 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 simple two-parameter write tool, the description covers the action, prerequisites, validation failures, and revision history. It lacks an explicit statement about success response, but given no output schema and straightforward operation, this is a minor gap. Overall, the description is fairly 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?

Both parameters are fully described in the input schema (100% coverage). The tool description adds no new parameter-specific semantics; it only restates that the draft is a replacement body, which is already in the schema. Thus 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 action ('Replace ... body'), the target resource ('drafted marketing output'), and a clear condition ('before it is shipped'). It also distinguishes the tool from AI redrafting by explicitly saying 'Manual replacement only: the AI redraft 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?

The description provides clear usage context: use this when you want to manually replace a draft before shipping. It also excludes AI-driven redrafting ('Manual replacement only'), but it does not explicitly name alternative sibling tools or state when not to use this tool in favor of another.

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 critical behavioral traits beyond the annotations: it 'SPENDS MONEY', requires specific billing state, is bounded by credits and caps, and enforces a deduplication rule (repeat on the same day replays the original result regardless of key). This is exactly the kind of context an agent needs to avoid unexpected costs and understand idempotency semantics.

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 information-dense, with the prominent 'SPENDS MONEY' warning front-loaded. Each clause earns its place, covering purpose, prerequisites, limits, and dedup behavior. However, it is structured as a single long run-on sentence with semicolons, which reduces readability; a bulleted list would have been clearer.

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 paid, rate-limited operation, the description covers operational essentials: cost, auth, idempotency, and quotas. However, it does not describe the return value or whether the scan runs synchronously or asynchronously; since no output schema is provided, a brief note on expected response would improve 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?

The schema already includes descriptions for both parameters (scan enum and idempotency_key), and the description adds little new meaning beyond restating that the key is client-minted. Since schema coverage is 100%, the description does not need to compensate, but it also does not enrich the parameter semantics further.

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 action: 'run an on-demand AI visibility scan' with the specific scan type 'ai_visibility' and its purpose (GEO measurement of answer engine representation). This distinguishes it from sibling tools like get_visibility or get_competitors, which likely retrieve existing data rather than trigger a new 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 strong when-to-use context: it triggers a paid, on-demand scan and outlines prerequisites (write scope, paid plan/trial, idempotency key). It also warns about credit limits and daily caps. However, it does not explicitly name alternative tools for reading existing results, such as get_visibility, so the guidance is clear but not fully comparative.

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. While annotations only declare readOnly=false and destructive=false, the text warns 'SPENDS MONEY,' details the need for a paid plan/trial and write scope, stresses the idempotency-key requirement, and quantifies limits (credit balance, daily and monthly caps, once a day per product). This gives the agent crucial cost and failure-boundary information not present in 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?

Three sentences with no wasted words. The 'SPENDS MONEY' warning is front-loaded, then the action, then prerequisites and constraints. Every clause conveys essential information, making it easy to scan and understand 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?

For a single-parameter tool with no output schema, the description adequately covers the effect (top up Feed with moves), prerequisites (scope, plan/trial, idempotency-key), constraints (credit balance, caps, daily frequency), and cost implications. An agent has enough to decide when to call and what to expect. No critical gaps remain.

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 idempotency_key fully described ('Client-minted key (1-200 chars). Reuse the same key on a retry.'). The description adds 'you mint' but does not introduce new semantics beyond restating the schema. Baseline 3 is appropriate since the schema carries the parameter meaning.

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: 'run the growth-move generator on demand to top up the Feed with fresh marketing moves.' It specifies the resource (Feed) and distinguishes from read-only siblings like list_feed by emphasizing generation rather than listing. It also enumerates content areas (SEO, AI visibility, competitors, distribution), making the 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 provides clear context: it's an on-demand top-up tool, requires a paid plan/trial and write scope, and is limited to once a day per product. It does not explicitly name alternatives or when-not-to-use scenarios, but the constraints and purpose make usage scenarios clear. No explicit exclusion of other siblings is stated, but the unique cost/limit warnings set it apart.

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 critical behavioral traits beyond annotations: cost (1 credit), spend warning, required scope, per-tenant daily/monthly caps, and idempotent replay behavior within the same cycle. These are not derivable from the annotations (readOnlyHint=false, destructiveHint=false) and provide essential 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 dense but every sentence contributes: cost, action, examples, scope, caps, idempotency, and restrictions. The 'SPENDS MONEY' opener effectively front-loads the most important warning.

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 only 2 params and no output schema, the description covers all necessary operational knowledge: cost, authorization, rate limits, idempotency, and valid input types. References get_loop_status for further context, making it self-sufficient 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%, so baseline is 3. The description adds value by giving examples for loop_type and clarifying idempotency_key semantics (mint a key, replay regardless of key within cycle), exceeding the schema's basic explanations.

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 an on-demand generation run of a growth marketing loop, with specific examples (linkedin_post, geo_improvement, competitor_intel). It distinguishes itself from sibling get/set tools by emphasizing the action of running a loop.

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 context for when to use: on-demand runs, with prerequisites ('Needs the write scope', 'Accepts only runnable, provisioned loop types' referencing get_loop_status). It also explains idempotency and caps, though it doesn't explicitly exclude alternatives like scheduled cadence 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 only indicate readOnlyHint=false and destructiveHint=false, which are generic. The description adds valuable behavioral details: it requires the 'config' scope and Founder tier, and it reveals a domain-specific rule about social channels always requiring human review. This goes well beyond the annotations, providing the agent with essential 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 three sentences long, with the core purpose in the first sentence, followed by prerequisites and a crucial exception. Every sentence carries meaningful, non-redundant information, making it compact 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?

For a simple two-parameter setter with no output schema, the description is largely complete. It covers the main action, required permissions, and a key limitation. It lacks explicit mention of return values or error behavior, but these are generally less critical for a configuration setter and the description already provides the key context an agent needs.

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 50% (loop_type is described, level only has enum). The description clarifies the meaning of the 'level' parameter by listing the acceptable values in context ('review, one_click or autonomous') and adds the cross-parameter constraint regarding social channels. It doesn't fully explain each level's behavior, but it sufficiently compensates for the missing schema description on 'level'.

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: setting the autonomy level of a growth marketing loop, and explicitly lists the three possible levels (review, one_click, autonomous). This verb+resource+scope combination effectively distinguishes it from sibling tools like set_loop_cadence or run_loop.

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 context including required scope and tier, and a critical constraint about social/distribution channels never accepting 'autonomous'. However, it doesn't explicitly name alternative tools or when to use them over this one, so it falls short of a perfect score.

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 indicate non-read-only and non-destructive. The description adds crucial behavioral detail: you can only slow down or pause, never speed up, and 'default' resets any override. This is valuable 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 entire description is two sentences, front-loaded with the core action, and every part earns its place (permissions, constraint, reset behavior). No fluff 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 moderate complexity and minimal annotations, the description covers the main aspects: what it does, required scope/tier, the slow/pause constraint, and the default override behavior. It lacks detail on loop_type domain and immediate side effects, but is fairly complete for a cadence setter.

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 only 50% (loop_type has a description, cadence does not). The description explains cadence values and the meaning of 'default', but loop_type remains under-specified with no full list of valid values provided anywhere.

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+resource: 'Set how often a growth marketing loop runs', and lists the specific cadence values. This distinguishes it from siblings like run_loop or 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?

It provides clear context by stating permissions ('Requires the config scope and Founder tier') and a key constraint ('only SLOW or pause'). However, it does not explicitly mention alternatives or when not to use the tool, so it stops short of full 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?

Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses key behavior: it never posts to a channel, requires 'act' scope and Founder tier, and that reporting the outcome is not optional. It also clarifies the semantic difference between 'done/published' and actual publishing, which is non-obvious and valuable.

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 well-structured and front-loaded with the core operation, followed by usage and constraints. However, it includes somewhat verbose motivational phrases ('because an unreported result leaves the record blind to what the work earned', 'Report only what is true...') that are not strictly necessary, making it slightly longer than ideal.

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 two-parameter mutation tool with no output schema, the description covers all relevant context: what it does, when to use each action, what it intentionally does NOT do, required scopes/tier, and the mandatory reporting behavior. It is complete for an agent to 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?

Schema coverage is 100% and the schema already describes both parameters accurately (action enum with ship/skip meanings, output_id from list_outputs). The description reinforces but does not add new semantic meaning beyond the schema, though it does connect them to the workflow context.

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 specific verbs ('Resolve', 'ship', 'skip') and clearly states the resource: 'one drafted marketing output in the founder's review queue (from list_outputs)'. It distinguishes from sibling tools by explicitly noting that this does NOT publish anywhere, contrasting with 'approve_output' for real publishing.

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-to-use guidance for each action: 'call 'ship' the moment the founder confirms the content is actually out, with their go and never on your own; call 'skip' when they decide against it'. It also names the alternative tool for publishing ('approve_output') and clarifies that reporting is mandatory.

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 (readOnly=false, destructive=false), the description discloses that setting is free, returns a cost quote, and that omitting the level is a read-only action. It also explains the behavioral effect of 'more passes per question per engine' and the confidence band, adding substantial 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?

Three concise sentences, front-loaded with purpose. Every sentence adds unique information: level definitions, behavioral effect, cost/quote, and read-only omission. 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?

For a simple tool with one optional parameter and no output schema, the description covers purpose, parameter semantics, usage context, cost, and return behavior (quote). No significant gap remains; it is comprehensive for the tool's 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%, but the description adds semantic value by explaining what each enum level means ('standard', 'deep', 'exhaustive') and the effect on confidence. It also reinforces the optional omit behavior, which matches the schema but gives rationale.

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 ('Set') and resource ('AI visibility scans measure') with clear level definitions (l1/l2/l3). It distinguishes from sibling setters like set_loop_autonomy and set_output_status by focusing on scan intensity.

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 usage context: scope ('config'), tier ('Founder'), and cost implications ('Free to set'). It also explains a safe fallback behavior ('Omit level to read the ladder'), but does not explicitly state when to prefer this over 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 are minimal (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It reveals important behavioral traits: requires 'act' scope, reports are not optional, only report true ships, and the response includes a receipt_url when applicable. This goes beyond what annotations 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?

The description is slightly longer than strictly necessary, but every sentence adds critical context—timing, exclusions, auth, parameters, and response. It is well-structured with a clear WHEN clause and effective front-loading of the primary action.

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 2-parameter tool with no output schema, this description is remarkably complete. It covers when to call, what counts as shipped vs. not, which sibling to use for declined moves, the required scope, optional parameter behavior, and response contents. 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 adds value by specifying the source for move_id ('from list_feed') and the condition for asset_url ('when the move published a live asset'), which clarifies usage beyond the 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 specific verb and resource: 'Mark a growth move shipped' and explicitly ties it to an existing action ('the same action as Ship in the Feed'). This clearly distinguishes it from sibling tools like skip_move and undo_move, which handle different outcomes.

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-to-use guidance: 'call it the moment the founder confirms the work is actually live, with their go and never on your own.' It also names the alternative for a different scenario: 'a move the founder turned down goes to skip_move with the real reason.' This gives clear decision criteria.

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 show readOnlyHint=false and destructiveHint=false. The description adds valuable context beyond this: permission requirement ('requires the 'act' scope'), cost ('Free'), and feedback behavior ('unknown keys are ignored by the learning loop', 'improves future marketing drafts'). It does not clarify if dismissal is reversible or permanent, but the annotations already indicate non-destructive.

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 concise sentences, front-loaded with the core purpose. Every sentence provides necessary information (purpose, scope/cost, feedback details) without redundancy or fluff.

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

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

For a simple 3-parameter tool with no output schema, the description covers the main aspects: what it does, permission requirement, cost, and feedback behavior. It does not describe the return value or error handling, but the operation is straightforward and the provided context is sufficient for an agent to invoke it correctly.

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

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

Schema coverage is 100%, with each parameter described. The description adds extra semantic value by explaining that feedback_key is a closed vocabulary (see enum) and that feedback_note is free-text which 'improves future marketing drafts'. This goes beyond the schema's basic descriptions, though it does not elaborate on move_id beyond the schema's 'from list_feed'.

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: 'Dismiss a growth move' with the parenthetical 'Skip in the Feed' adding specificity. This distinguishes it from sibling tools like archive_move or ship_move. The verb 'dismiss' is action-oriented and the resource is explicit.

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 useful context (free, requires act scope, feedback improves drafts) but does not explicitly explain when to use this tool versus alternatives. It does not mention that this is for skipping while archive_move or undo_move are for other purposes, so the agent must infer usage from the tool name and 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?

The description goes beyond the basic annotations (readOnly=false, destructive=false) by disclosing session binding ('bound to their session'), link expiry (15 minutes), the refusal behavior for shut connectors, and the 'Free, spends nothing' cost aspect. It does not mention potential side effects like creating a pending connection record, but still adds substantial 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 front-loaded with the purpose and packs essential information (returns, polling, refusal, cost) into a dense but readable block. It could be slightly more concise, but every sentence serves a practical need for the agent.

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 has only one parameter and no output schema, the description is exceptionally complete: it lists exact return fields, provides the next-step action (poll_connection), specifies the timeout, covers an edge case (connector shut), and clarifies cost. This leaves little ambiguity for the 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?

The schema already documents the provider parameter with 100% coverage, including valid values (ga4, gsc, etc.) and reference to list_connections. The description adds no additional parameter-level detail, so it meets the baseline but does not enhance 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 the tool's purpose: 'Connect a growth data source or distribution channel' with a specific verb (connect) and resource (data source/channel). It distinguishes from siblings like poll_connection (which checks status) and list_connections (which lists available connectors) by detailing the one-time link flow and founder approval.

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 workflow guidance: 'Then poll_connection until it reports connected.' It also warns about a failure condition (when a connector is shut). However, it does not explicitly state when to avoid this tool or mention alternatives like disconnect_connection for removal, so it misses a bit on exclusions.

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

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

Annotations only flag non-read-only and non-destructive, but the description discloses major behavioral consequences: the next scan runs at full depth, the week-over-week trend re-baselines, deduplication, the 15-item hard cap, and free-trial behavior. This is substantial context beyond the annotations, 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?

The description is long but every sentence carries a distinct piece of necessary information: purpose, cost, consequences, guardrails, and requirements. It is structured with the primary action first, followed by consequences and usage constraints, making it scannable despite its length.

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 mutating tool with no output schema and nontrivial downstream effects, the description covers what happens, the constraints, and the access requirements. It even handles the free-trial edge case and points to create_checkout for upgrade, so an agent can decide and execute correctly without additional 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?

The schema already fully describes the 'text' parameter with length constraints and an example, so the baseline is 3. The description adds the deduplication rule, the hard cap of 15, and the 'real person' phrasing requirement, which refines the parameter semantics 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 opening sentence names the action ('Add one buyer question') and the target ('the AI visibility (GEO) set'), which separates it from sibling tools like untrack_prompt or list_tracked_prompts. It additionally states the business constraint ('Free, spends nothing'), making the operation's intent unmistakable.

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 says 'Add deliberately rather than churning the list' and explains the consequences of changing the set, giving the agent situational guidance. It also notes prerequisites ('config' scope and Founder plan) and points to create_checkout for upgrade, though it doesn't explicitly list alternative tools for the same 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 only provide readOnlyHint=false and destructiveHint=false. The description adds substantial behavioral details beyond that: 'Free', 'requires the act scope', 'Idempotent on a move already pending', and to key exclusions: 'never unwinds a real channel publish' and 'archived or expired move cannot be restored'.

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 dense, front-loaded sentence conveys the verb, scope, idempotence, and key exclusions without wasted words. 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?

Despite no output schema and a single parameter, the description covers what it does, when to use it, prerequisites, and edge cases (already pending, published, archived/expired). No meaningful gaps for 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?

Schema coverage is 100% with a clear parameter description ('Move id (uuid), from list_feed.'). The description does not add parameter-level semantics, 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 states the action with a specific verb and resource: 'Restore a just-shipped or just-skipped growth move to pending'. It also distinguishes from siblings by explicitly naming ship_move and skip_move as the actions it reverses.

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 clearly frames when to use this tool ('self-correction verb for a wrong ship_move or skip_move') and gives explicit limitations ('an archived or expired move cannot be restored'). It also mentions a prerequisite ('requires the act scope').

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 discloses critical behaviors: 'Free, spends nothing,' the two consequences (full-depth scan and re-baselining trend), idempotency, and matching rules (ignoring case/punctuation). It also mentions the required 'config' scope and Founder plan, which are not in the schema or 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 yet information-dense: opening with the primary action, then covering cost, consequences, matching, idempotency, and prerequisites. Every sentence earns its place, and the key information is front-loaded without any 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?

The description thoroughly covers prerequisites, effects, and matching behavior, making it complete for a tool with a single parameter. It does not state return values or error cases, but given the absence of an output schema and the tool's simplicity, this is a minor gap rather than a significant 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 schema already describes the only parameter 'text' clearly, including the matching rule and source (list_tracked_prompts). The description repeats the matching rule but adds no new parameter-specific meaning beyond what the schema 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 uses a specific verb 'Remove' with a clear resource ('buyer question from the AI visibility (GEO) set') and adds the cap-of-15 detail, effectively distinguishing this from the sibling track_prompt. The purpose is unambiguous and immediately actionable.

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 as the inverse of track_prompt by referencing 'Same two honest consequences as track_prompt' and the schema points to list_tracked_prompts for source text. However, it does not explicitly state when NOT to use it or name alternatives beyond this implicit contrast, so it falls short of a 5.

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

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

Annotations indicate non-read-only and non-destructive, so mutation is implied. The description adds useful behaviors: validation refuses drafts with unfilled placeholders or broken links, cost is free, and requires 'act' scope. This goes beyond what annotations 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?

Two sentences, front-loaded with the main action, no filler. 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 tool's simplicity (2 params, no output schema), the description covers the action, validation behavior, cost, and auth. It doesn't describe the success response, but that's not required. Slightly more could be said about return values, but overall 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 covers both params at 100%, giving a baseline of 3. The description adds context: move_id refers to a pending growth move and draft_content is the marketing draft body. It also clarifies validation criteria, adding meaning 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 the action: 'Replace a pending growth move's marketing draft body before shipping.' The verb 'Replace' plus resource 'draft body' and context 'before shipping' distinguish it from siblings like ship_move or redraft_output.

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: before shipping a pending move, and what validation will occur (invalid drafts refused). It doesn't explicitly name alternatives, but the 'before shipping' context implies timing relative to ship_move. Lacks explicit exclusions but 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?

The annotations provide readOnlyHint and destructiveHint, but the description adds behavior not visible in annotations: the feed_ready state and the fact that credits appear 'once metering is live'. It also reveals that the deep scan is still building during onboarding. 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 sentence that front-loads the purpose ('Confirm the AfterLaunch key works') and then packs useful details. It is somewhat dense but every clause adds value; not overly verbose.

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 itself enumerates the key return fields and explains the onboarding state and credit timing. This covers the essentials for an agent to understand what to expect, making it complete for a first-call health check 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 input schema is empty ({}), so there are no parameters to explain. The description correctly focuses on the tool's output rather than inputs. Baseline of 4 applies for zero 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 the tool's function: 'Confirm the AfterLaunch key works before any growth or marketing work' and enumerates the specific data returned (product run, scopes, tier, trial_ends_at, feed_ready, credits). This differentiates it from sibling tools like list_feed or get_activity.

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 instructs 'Call this first' and provides a conditional for using the Feed: 'wait before reading the Feed' until feed_ready is true. This gives clear ordering relative to other tools, even if no alternative tool is named.

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