AfterLaunch

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 meaningful behavioral context beyond annotations: the operation is durable, one preparation attempt is recorded, a worker may start only under a specific condition, repeats are idempotent with respect to worker launch, and there is a scope requirement. This is strong transparency for an action with side effects.

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 high signal density. The key operational constraint is front-loaded, followed by behavioral consequences and cost/scope info. No filler or repetition of schema details.

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

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

For a 7-parameter tool with retry/legacy-state complexity and no output schema, the description covers only the happy-path semantics. It does not describe the operation parameter, retry requirements, legacy state usage, or what a caller should expect in response. An agent navigating this tool would lack critical context for valid invocation across all supported cases.

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 only 43%, which is below the 50% threshold, so the description needed to compensate for undocumented parameters. It does not explain move_id, target, operation, expected_attempt_id, or the legacy fields. The retry and expected-state parameters remain opaque to an agent trying to construct a valid call.

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 ('accept a move'), the precondition ('only after the founder says yes'), and the core effect (records a durable preparation attempt, may start a worker if launch_won is true). However, it does not explicitly distinguish itself from sibling tools like review_move, ship_move, or skip_move, so differentiation is mostly implicit.

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 concrete usage guidance: only accept after founder approval, worker launch is conditional on launch_won, repeats never start another worker, and the 'act' scope is required. It does not explicitly contrast with sibling tools or explain when to use the retry operation, which leaves some routing to inference.

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

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

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?

Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries the burden. It transparently discloses the return of a checkout_url, automatic upgrade on payment, and binding to the caller's enrollment.

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

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

The description is three sentences with no fluff. It front-loads the core action and then efficiently covers prerequisites and outcome.

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 is nearly complete: purpose, usage context, requirements, and result are all covered. It could mention error cases or already-Founder states, but those are edge cases.

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 input schema is empty with 100% coverage, so the baseline is 4. The description adds no parameter details, but they are not 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 'Create a Founder-tier checkout link for THIS product run' and explains its purpose as unlocking Founder-only growth controls, distinguishing it from siblings like create_topup. The verb and resource are specific.

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 mentions it is 'Reachable on a free trial because it is the path TO Founder', providing clear context on when to use it. It also notes the required 'act' scope and own-enrollment binding, though it does not explicitly name alternatives.

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

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

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 read-only and non-destructive, so the description adds contextual value: the timeline is newest-first, includes rationale, and is 'free' (no cost). This goes beyond the safety annotations and clarifies the content scope.

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 brief sentences covering purpose, usage, and a safety/cost note. The purpose sentence is dense but well-structured, and every sentence earns its place with no redundancy.

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

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

For a simple read-only list tool with one optional parameter, the description adequately covers what it returns (activity timeline with rationale), the ordering (newest first), and the practical use case (prevent redoing recent work). No gaps are apparent.

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

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

The only parameter (limit) is fully described in the schema with range and default, and the description adds no parameter-specific semantics. With 100% schema coverage, 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 clearly defines the tool as 'the product timeline' and enumerates the specific content types (drafts, ships, skips, scans, observations, decisions with their rationale) and ordering (newest first). It distinguishes this from sibling getters by emphasizing the collective agent/founder history rather than a single resource.

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 acting so you never redo recent work,' giving a clear when-to-use. It stops short of naming alternatives or when-not conditions, but the guidance is specific and actionable.

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: it returns structured facts rather than a rendered page, unextracted facts are null rather than errors, and the tool is free. This goes beyond the annotations meaningfully.

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 dense sentence that front-loads the core purpose and then enumerates the returned facts. It is slightly long but every phrase earns its place, and the colon-structured list is 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?

With no output schema, the description carries the burden of explaining what the tool returns, and it does so by listing the fact categories and clarifying null behavior. It is adequately complete for invoking and interpreting the tool, though it does not provide exact property names or a sample response.

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

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

The tool has zero parameters, so there is no input schema ambiguity. The baseline for zero-parameter tools is 4, and the description appropriately focuses on output semantics instead of parameters.

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

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

The description clearly states the tool returns structured business context facts: what the product is, who it is for, competition, pricing, features, and positioning. It is specific about the resource, but it does not explicitly distinguish itself from the sibling get_competitors, which may overlap on competitor information.

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 to read this before writing about the business, which gives a clear trigger condition. It does not mention when not to use it or point to alternatives like get_competitors, so it stops short of full exclusion guidance.

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

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

Annotations already mark the tool read-only and non-destructive, and the description adds meaningful behavioral context: claim records contain a sentence, number with unit, keywords, and a caveat; held claims must not be used; an empty result is not an error. It does not describe the exact output format, but the key caveat behavior is disclosed.

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

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

The description is somewhat long and uses emphatic capitalization, but each sentence contributes substantive information. The most important guidance is front-loaded, and there is minimal 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 no output schema, the description covers the data model, the critical usage rule, the held-claim exclusion, and the empty-result case. It is complete enough to call correctly, though it does not specify the exact output shape or how 'held' appears in the payload.

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

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

The tool has zero parameters, so the baseline of 4 applies. The description does not need to document arguments, and it compensates by explaining what each claim record contains, which is the semantic information an agent needs to interpret returns.

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 as the claim library and explains what claims are: measured numbers the founder stands behind in public writing. It does not explicitly use a retrieval verb or distinguish itself from sibling tools, but the tool name and description together make 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 gives explicit usage guidance: consult this before citing any number in replies, posts, or marketing, and never quote a claim without its caveat. It also warns that held claims are not for use and that an empty library is a valid answer, though it does not name alternative tools.

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

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

Annotations already declare readOnlyHint and destructiveHint, and the description reinforces this with 'Read-only, free' while adding useful context about 'the founder's own edits' and the included metric battery. This goes beyond the structured 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 only two sentences, front-loads the core purpose, and packs in the metric list and usage guidance without fluff. Every clause serves a purpose.

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

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

For a parameterless read-only tool with no output schema, the description adequately covers the data returned (metrics), the usage trigger (competitor/outreach work), and safety (read-only/free). It is complete for its 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 input schema is empty (0 parameters), and the description confirms no arguments are needed. With no parameters to document, the baseline score of 4 applies; the description adds no unnecessary parameter noise.

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 providing 'the competitor roster with the measured stat battery' and enumerates specific metrics (performance, SEO, Core Web Vitals, etc.). This distinguishes it from sibling tools like get_seo or get_scoreboard by centering on competitors as the resource.

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 instructs to 'Read before any competitor or outreach work so a rival is never treated as a pitch target,' giving clear when-to-use context. It does not name alternative tools or exclusion scenarios, 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?

The description repeats the readOnlyHint annotation, but it adds a meaningful extra behavior: saved words are not publication proof and linkage/calendar_sync should be checked. This is exactly the kind of interpretation hazard that structured annotations would not convey. However, 'X production switch' and 'calendar_sync' remain undefined and somewhat opaque.

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 and front-loaded: it lists the returned content first, adds the read-only property, then ends with the caveat. Every sentence earns its place, even though the first phrase is telegraphic.

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-input, read-only tool this is mostly sufficient to invoke safely, but with no output schema the agent must guess the structure and meaning of 'linkage', 'calendar_sync', and 'X production switch'. The caveat adds value, but those undocumented output concepts keep it from being fully complete.

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

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

The tool has zero parameters and the schema description coverage is 100%, so there are no parameter meanings left for the description to clarify. Baseline 4 is appropriate 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?

Although it lacks an explicit verb, 'get_content_calendar' plus 'Read-only' signal a retrieval operation for the calendar, source drafts, Feed state, and X production switch. It names a concrete resource and is not a tautology, but it does not contrast with sibling getters such as get_snapshot or 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?

There is no explicit when-to-use statement or alternative routing; the guidance is limited to the read-only warning and the caveat to check linkage/calendar_sync instead of treating saved words as publication proof. This implies a read-only inspection use case but leaves selection among sibling getters to the agent's inference.

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

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

Annotations already declare readOnlyHint and destructiveHint, and the description reinforces these with 'Read-only'. It goes beyond annotations by listing the concrete return fields and adding the credit-metering note, which gives the agent a clearer picture of behavior.

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

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

The description is compact: one sentence with a clear list of returned fields, followed by two short fragments about credits and read-only/free. There is no fluff or repetition, and the most important information is front-loaded.

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

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

With no parameters and no output schema, the description covers the essential context: what data is returned, that it is a read-only operation, and a note about future metering. It could be more explicit about what 'product run summary' means or when to use this tool, but for a simple getter it 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 tool has zero parameters, so there is no parameter semantics to explain. The description lists output fields instead, which is useful context in lieu of an output schema, though it doesn't directly address 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 identifies the tool as returning a product run summary with a specific set of fields (product_url, tier, trial_ends_at, etc.), which distinguishes it from sibling getters. However, the term 'product run summary' is not immediately obviously synonymous with 'enrollment', so it could be more 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 provides no guidance on when to use this tool versus alternatives. It only states properties like 'Read-only, free' and lists output fields, but does not mention any context where this tool should be preferred or avoided.

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 the return detail ('full markdown body') and the note 'Read-only, free,' which confirms the safety profile and adds the 'free' (no cost) aspect beyond annotations. This is useful context for an agent deciding whether to invoke the 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 two sentences, front-loaded with the core action and output, followed by a concise secondary sentence about slug provenance and read-only/free nature. No unnecessary words or repetition of the tool name. Every part adds value.

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 parameter and no output schema, the description covers the input (slug from list_kb_pages), the output (full markdown body), and the use case. It does not detail error cases or response structure beyond the body, but it's sufficient for a low-complexity tool.

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

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

Schema coverage is 100% with a single required parameter 'slug' described as 'The page slug, from list_kb_pages.' The description repeats this source ('Slugs come from list_kb_pages') but adds no new syntax or format details. With the schema fully documenting the parameter, the description provides marginal additional value, so baseline 3 is appropriate.

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

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

The description clearly states the tool's function: fetching a single Memory page by slug with its full markdown body. It distinguishes itself from siblings by referencing list_kb_pages as the source of slugs and specifying 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 gives clear usage context: slugs come from list_kb_pages, implying a prerequisite step. It also states the tool's purpose ('the record the growth marketing engine drafts from'), which helps the agent decide when this read operation is appropriate. It doesn't explicitly mention alternatives or exclusions, but the relationship to list_kb_pages provides practical guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context by explaining that the tool exposes provisioning status, autonomy levels, and the runnable_loop_types accepted by run_loop, including the prerequisite that loops must be enabled. 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 concise, with two sentences and no fluff. The first sentence is a bit dense with parenthetical examples, but the second sentence earns its place by clarifying the runnable condition. Overall it is efficient and front-loaded with the main resource.

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 should indicate what the response contains, and it does: provisioned loops, autonomy level, and runnable_loop_types. The optional loop_type filter is already documented in the schema. It could be more explicit about response format, but for a simple read-only status tool it is sufficiently complete.

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

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

Schema coverage is 100% with a clear description for loop_type ('Optional loop type, e.g. daily_brief or linkedin_post'). The description does not add any extra meaning about the parameter beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description identifies the resource (automated growth marketing loops) and the information returned (autonomy level, runnable_loop_types), making the tool's purpose reasonably clear. However, it lacks an explicit verb like 'returns' or 'lists', and the phrase 'what run_loop accepts' can be slightly confusing. It does differentiate from siblings like run_loop and set_loop_autonomy by focusing on status.

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

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

The description implies usage by stating 'A runnable type only runs once a loop of that type is provisioned and enabled here,' which suggests checking this tool before using run_loop. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions. This is helpful but implicit 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 annotations, the description discloses important behaviors: source material and prepared_result are separate, a ready result is unpublished and awaiting review, bodies are withheld when post-trial access is closed, tracked_link_state explains null tracked_link reasons, and clicks is null when it cannot be read. This goes well beyond the readOnlyHint and destructiveHint 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 dense but efficient: it front-loads the tool's core purpose, then explains non-obvious output states and confirms costlessness and safety. Every sentence carries useful information, with no redundant 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?

With no output schema present, the description compensates by explaining key return fields, null-value semantics, withholding behavior, and review status. Combined with the schema's parameter guidance and the annotations' safety profile, an agent has enough context to invoke the tool correctly and interpret its response.

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

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

The single parameter move_id is already fully described in the schema, including its type and provenance from list_feed or get_standup. The description adds no new parameter-level meaning, so it rests at 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 identifies the tool as retrieving one complete growth move with its evidence, source material, instructions, and prepared result. It is unambiguous about the resource and action, though it does not explicitly differentiate itself from sibling get_* tools or mention when this is preferable to list_feed or get_standup.

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 by noting the move_id comes from list_feed or get_standup, and it declares the operation as read-only and free. However, it gives no explicit guidance about when to choose this tool over alternatives, nor any exclusions or 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 already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond annotations: the specific data elements returned and the recommended call sequence ('after ship_move'). It does not detail return format, but for a 0-param read-only tool this is sufficient.

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 concise sentences. The first front-loads the output contents, the second states usage and safety. 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 the simple tool (0 params, no output schema, good annotations), the description is complete enough. It lists the key returned data categories and provides the lifecycle context (after ship_move), allowing an agent to select and invoke the tool 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 tool has 0 parameters and the schema is empty, so description has nothing to explain. Per the baseline for 0 params, a score of 4 is appropriate. The description does not need to add parameter details because there are none.

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

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

The description clearly states what the tool returns: tracked-link clicks per move, shipped counters, weekly movement scoreboard, and connection status for GA4/Search Console. It uses a specific verb+resource and distinguishes itself from sibling tools (e.g., get_scoreboard, get_output) by focusing on outcomes of shipped moves.

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

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

Explicitly says 'Call it after ship_move', providing clear context for when to use the tool. It does not mention alternatives or exclusions, but the temporal constraint and 'Read-only, free' signal are strong 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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by explaining that 'SEO linked_article {id,title,content} adds the full Markdown article', which is not disclosed by the annotations. This goes beyond the structured metadata.

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, leading with the core purpose, then adding relevant nuances about the SEO-linked variant and the editing sibling. It is front-loaded and every sentence carries information. A slightly tighter structure (e.g., separating the read-only note from the SEO variant) would be ideal, but it's still efficient.

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

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

For a simple read operation with a single parameter and no output schema, the description is complete enough: it states what it does, mentions a special case (SEO-linked article), and points to the editing sibling. The only minor gap is the lack of an explicit description of the return format, but given the straightforward nature, the information provided suffices.

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 a full description for the only parameter output_id ('The output id (uuid)'), and the description does not add any extra semantic detail about the parameter. Since schema coverage is 100%, the baseline of 3 applies; the description only repeats what the schema already states.

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

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

The description states a specific verb ('Read'), a resource ('a queue draft'), and by 'id', making the purpose immediately clear. It also distinguishes itself from the sibling 'redraft_output' by noting that one edits while this reads, and mentions the SEO-linked article variant. This is well above the minimum viable clarity.

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 its role as a read-only counterpart to 'redraft_output' by saying that redraft_output edits the queue draft only. While it doesn't explicitly state 'use this when you need to read a draft' or list all alternatives, the context gives enough direction for a typical read vs. edit scenario. It doesn't mention when not to use it, but the implication is strong enough for a 4.

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 valuable context beyond this: it is 'free,' describes the output contents (issue groups, trend, performance, etc.), and states that seo_fix moves are 'minted from it.' No contradiction with annotations, and it enriches understanding of what the tool provides.

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: content summary, usage recommendation, and parameter tip. It is front-loaded with what the tool does, efficient, and every sentence earns its place with no fluff.

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

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

For a simple one-parameter, read-only tool with no output schema, the description is thorough. It covers the return content, usage timing, relationship to other tools, read-only/free nature, and parameter usage. No significant 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 a clear description: 'Include the per-page audit detail. Default false: the grouped issues only.' The description's 'Pass include_pages for the per-page detail' is redundant but reinforces the parameter's purpose. It adds no new semantic 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 tool's function: 'The site-wide SEO audit: issue groups with severity and affected pages, the weekly score trend, page performance, links and authority, and day-0 search ranks.' It uses a specific verb-resource relationship ('get_seo' returns an SEO audit) and distinguishes itself from siblings by focusing on this audit and its role in minting seo_fix moves.

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

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

Explicitly says when to use: 'Read before any SEO work of your own; the Feed seo_fix moves are minted from it.' This gives clear context and prerequisite positioning. While no alternatives are named, the tool's unique role in the SEO workflow makes the guidance strong.

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 meaningful context by explicitly stating 'Free, read-only' and explaining that the snippet only provides documentation content, not modifications. It also clarifies the intended workflow (show to founder, add with consent), going beyond the annotation's safety flags.

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 main purpose. The first sentence is long but packs essential detail about the snippet's content; the second gives a clear action. It is not overly verbose, though it could be split for better readability.

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

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

For a tool with no parameters and no output schema, the description fully covers what the tool does, what the snippet contains, usage instructions, and cost implications. It leaves no significant gaps for an agent to understand when and how to invoke it.

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

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

The tool has zero parameters, so the baseline is 4. The description adds value by explaining what the returned snippet contains, even though there are no parameter semantics to clarify. Since schema coverage is vacuously 100%, no additional parameter info is needed.

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

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

The description clearly states the tool returns a paste-able 'Growth (AfterLaunch)' section for CLAUDE.md or AGENTS.md, specifying its content (how to use AfterLaunch for growth, marketing, SEO, GEO, competitors, distribution) and distinguishing it from sibling tools that fetch specific data or perform 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 explains when to use the snippet (when setting up AfterLaunch guidance for coding agents) and provides a clear instruction to show it to the founder and add it only with their approval. It also notes the tool is free, implying safe usage, though it does not explicitly compare 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 already declare readOnlyHint=true and destructiveHint=false, and the description reinforces with 'Read-only, free.' Beyond annotations, it adds behavioral context that the data is stable and not live, which helps the agent understand the nature of the response. It doesn't contradict annotations, and the additional context is 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 two sentences, front-loaded with the core content and immediately followed by a sharp usage alternative. Every word earns its place, with 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 zero-parameter, read-only tool with no output schema, the description is complete. It covers what the snapshot contains, clarifies it's stable, provides a pointer to live alternatives, and mentions read-only/free nature. No gaps remain 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 tool has zero parameters, matching the empty schema exactly (schema coverage 100%). With no parameters, the description doesn't need to explain parameter meanings; the baseline of 4 applies since the schema is fully self-explanatory.

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 the Growth Snapshot, enumerating specific components (positioning, discoverability score, prioritised leverage actions, competitor set, day-0 SEO/AI baselines). It also distinguishes it from live-data sibling tools by calling it 'stable business context.' This is a specific verb+resource definition that effectively separates it from similar-sounding tools like get_visibility and get_seo.

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 provides use context: it is the stable snapshot from the product run, and it directly names alternatives for live signal data ('use get_visibility and get_seo'). This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value by explicitly stating 'Read-only, free' (though read-only is redundant with annotation) and discloses operational details like 'capped at the account's age' and that the deep scan status is included. It does not contradict annotations, so no annotation 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, dense sentence, front-loaded with the key phrase 'daily growth marketing standup in one call'. Every clause adds unique information (shipped items, receipts, ready list with rank explanation, engine actions with cap, deep scan status). There is no fluff, and it ends with 'Read-only, free' for quick safety recognition.

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 zero parameters and no output schema, the description fully explains its purpose, content, usage timing, and constraints (cap, free, read-only). It covers all key aspects an agent needs to invoke it correctly and interpret its output. It is complete for a zero-parameter tool.

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

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

The tool has zero parameters, so the schema is trivial. The description explains what the tool returns (the standup data sections) and instructs to 'relay the message field', adding meaning beyond the empty schema. Since there are no parameters to document, a baseline of 4 is given, but the explicit instruction about relaying a field elevates it.

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: 'The daily growth marketing standup in one call' and enumerates the specific data sections (receipts, ready, while_you_were_gone, deep scan status). It distinguishes itself from siblings by explicitly saying 'Call this at the START of a session, before list_feed', which differentiates it from list_feed and other get_* 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?

It provides explicit when-to-use guidance: 'Call this at the START of a session, before list_feed.' This instructs the agent on ordering relative to a sibling tool, and the tool is clearly a session-initiation utility. It also implicitly says when not to use (not for listing feed items), making usage guidelines strong.

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 adds meaningful behavioral context: the sampling count's statistical implications ('treat a change as indicative unless it says otherwise'), the 'Read-only, free' note, and the sequencing dependency on refresh_scan. This is substantial value beyond annotations.

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

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

The description is succinct yet dense, condensing a large amount of information into a few sentences. Every clause serves a purpose: defining the output scope, qualifying data reliability, directing workflow, and explaining the optional parameter. No fluff 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?

Despite lacking an output schema, the description enumerates all major output components (engine answers, share of voice, sources, gaps, trend, crawlability, off-site reach) and explains the sampling caveat. It also covers the single parameter and its effect. For a read-only, relatively simple tool, this is complete enough for an agent to set expectations.

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 echoes the schema's guidance ('Pass prompt_id to drill into one question') without adding new semantic detail beyond what the schema states, so no bonus is warranted.

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

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

The description clearly specifies the resource and action: 'The measured AI visibility (GEO) results' with detailed constituent elements (engine answers, share of voice, cited sources, gaps, trends, crawlability). It distinguishes from siblings like get_seo by focusing on AI visibility/GEO rather than traditional SEO or other analytics 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?

Provides explicit workflow context: 'Read after refresh_scan and before any AI visibility or GEO work,' which tells when to use it. It also gives conditional usage via the prompt_id parameter ('Pass prompt_id to drill into one question'). However, it does not explicitly state alternatives or when not to use it, stopping 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 signal read-only; the description adds that has_profile false is a valid answer, not an error, and clarifies the three register meanings. This materially reduces the chance an agent treats a missing profile as a failure.

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

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

The description is compact and front-loads the definition of the voice profile. Minor redundancy ('Read-only' repeats the annotation) and internal jargon ('register', 'has_profile') keep it from a 5.

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

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

For a one-parameter getter with no output schema, the description explains the returned concept, the register field, and the key edge case (has_profile false). It could be more explicit about the exact return shape, but nothing critical is missing for correct invocation.

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

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

With schema coverage at 100%, the schema already documents the one parameter; the description goes further by defining what each register means (brand, personal, imported). It does not repeat the parameter syntax, so it adds value without duplication.

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 name supplies the verb, and the description defines the resource precisely: a structured voice profile containing tone, characteristic phrases, vocabulary, sentence style, and avoided elements. It is clear what this tool returns, though it does not explicitly contrast itself with sibling getters.

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 context ('every AfterLaunch growth marketing draft') implying when the voice profile matters, and it explains register semantics, but it never states when to choose this tool over alternatives or when not to use it. No alternative is mentioned among the many sibling getters.

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 the description reinforces this with 'Read-only.' It adds meaningful behavior beyond annotations: default filtering to live moves, incremental use of since during a deep scan, and the semantic of draft_kind/posture. It does not mention pagination or rate limits, but for a read-only list tool this is sufficient.

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 and front-loaded: it opens with what the feed contains, then covers posture, usage, the get_move routing, and filtering. Every sentence carries useful information. It is longer than strictly necessary and slightly redundant with the schema in a couple of spots, but it remains well structured and efficient.

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

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

Since there is no output schema, the description takes on the work of enumerating the main output fields and their meanings, which it does well. It also explains the relationship to get_move for material bodies. It does not name every possible output field such as the move ID or first_seen_at, but it provides enough for an agent to call and consume the tool 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 the description has little obligation to document parameters. All three parameters (since, verbosity, include_resolved) are already thoroughly described in the schema. The description adds some contextual rationale for since and verbosity, but does not substantially extend what the schema already provides.

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

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

The description clearly identifies the resource as the 'ranked backlog of growth marketing moves' and enumerates the fields returned (title, why, area, status, rank, has_draft, draft_kind, posture). It also distinguishes itself from get_move by explicitly stating that the material body is elsewhere. The purpose is unambiguous and strong.

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 says exactly when to use it: 'Read it before improvising growth work of your own.' It also tells the agent to call get_move for the material body, providing a clear alternative. The use of include_resolved and since are explained with concrete conditions ('Live moves only unless...', 'pass since for what is new...').

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' (free being new) and clarifies that output consists of summaries with a size hint, giving useful behavioral context beyond annotations.

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

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

The description is two sentences long and packs relevant context (what the pages are, output format, alternative for full bodies). The parenthetical list of example pages is somewhat heavy, but overall it is compact and front-loads key info.

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

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

For a zero-parameter, read-only list tool, the description adequately communicates what the tool returns (summaries) and how to get more detail (get_kb_page). No output schema exists, but the simple nature of the tool means this is sufficient, though it doesn't specify pagination or field details.

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 baseline is 4. The description does not need to add parameter details, and none are expected for a simple list operation.

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 what the tool returns (summaries with a size hint), and distinguishes from the sibling tool get_kb_page for fetching full bodies. However, it lacks an explicit verb like 'lists' or 'lists summaries', relying on the tool name for the action.

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

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

The description explicitly states when to use this tool (to get summaries) and directs to an alternative for full content: 'fetch a body with get_kb_page'. This provides clear distinction and usage context.

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

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

Annotations already cover read-only and non-destructive behavior, and the description reinforces this with 'Read-only, free.' It adds valuable behavioral context: the output is ordered newest first, includes only specific metadata fields, and lacks the body content—information not available from annotations alone.

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

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

The description is compact and efficiently front-loaded, covering the resource, ordering, fields, a cross-reference to a sibling tool, and safety status in just two sentences. Every clause provides meaningful information without redundancy.

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

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

Given zero parameters, no output schema, and strong annotations, the description fully covers what the tool does, what it returns, and how to use it in context. It explains the exact data fields and the relationship to get_output, making it complete for a simple list tool with no additional 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?

The input schema has zero parameters, so there is no parameter documentation needed. The description still adds value by specifying the output fields, which helps users understand what each returned item contains, despite no schema-level parameter semantics to clarify.

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 defines the tool as listing drafted marketing and distribution content for the product, specifying the exact fields returned and the ordering (newest first). It also distinguishes itself from get_output by pointing to that tool for fetching the body, making the purpose specific and unambiguous.

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

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

Provides clear context for when to use this tool (to list metadata for drafted content) and explicitly directs users to get_output for the body, implying this tool is not for retrieving full content. It doesn't explicitly mention when not to use other list tools, but the product-specific scope and field list give sufficient 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 minimal annotations, it discloses useful behavioral details: rows contain a nullable attempt_id, summaries never include prepared_content, the tool is free, and it requires the 'act' scope. This gives the agent important operational knowledge.

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 deliver the core purpose, row shape, usage instruction, and caveats. There is no waste and the most important information is front-loaded.

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

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

For a tool with no parameters and no output schema, the description covers what the rows contain, the ordering, the follow-up action, and important exclusions. An agent has enough context to invoke it correctly and understand the returned data.

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 coverage is 100%, so there is no parameter burden on the description. Baseline for zero-parameter tools is 4, and the description adds no conflicting or unnecessary parameter information.

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

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

The description clearly identifies the resource ('unclaimed preparation jobs'), the operation ('list'), and the ordering ('oldest first'). It also distinguishes the row contents, making it unambiguous what this tool returns.

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

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

It explains exactly how to use the results: call pick_up_job with both job_id and attempt_id before starting. It does not explicitly name when to avoid this tool, but the context of unclaimed jobs is clear enough for an agent to select it appropriately.

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?

Annotations only declare readOnlyHint=false and destructiveHint=false, so the description carries the behavioral burden. It adds significant context beyond annotations: the claim_won:true contract, the rule that an unchanged result means non-winner and 'must not start work', cost ('Free'), and auth requirement ('requires the 'act' scope'). This is exactly the operational detail an agent needs for a conditional claim operation.

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

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

Four short sentences, each earning its place: purpose, invocation, winning condition, losing condition, plus scope/cost. Critical safety constraints are front-loaded immediately after the purpose statement. No filler or repetition of schema 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?

With no output schema, the description correctly explains the essential response contract (claim_won:true, unchanged means non-winner). It covers the nuanced nullable attempt_id and the destructive safety boundary. The only minor gap is not describing error/failure responses for invalid job_id or expired attempts, which an agent could encounter.

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 schema already documents all three parameters, including that job_id is from list_queue and attempt_id is exact and nullable only for legacy jobs. The description adds marginal value by restating provenance and emphasizing exactness, but does not meaningfully exceed schema content, so baseline 3 is appropriate.

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

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

The opening phrase 'Try to claim one queued preparation attempt' names a specific verb (claim), resource (queued preparation attempt), and conditional nature. This clearly distinguishes it from siblings like list_queue (listing), get_claims (reading claims), and record_claim (recording outcomes) without ambiguity.

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

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

The description gives clear invocation context: 'Pass job_id and the exact nullable attempt_id from list_queue' establishes the prerequisite workflow (list_queue feeds this tool). It does not explicitly name alternatives or state when-not-to-use, so it falls short of a 5, but the usage context is 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?

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?

With only readOnlyHint=false and destructiveHint=false in the annotations, the description carries the behavioral burden and exceeds it: tail-of-board placement, thread-keyed dedup onto one row, the draft_only posture on Reddit/Hacker News, an absolute prohibition on posting to those communities, a per-day quota, and idempotent return of an existing move id. This is far more than the annotations alone convey.

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

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

Purpose is front-loaded in the first sentence, followed by a labeled WHEN section and a WHAT COMES BACK section. Roughly 150 words for a 6-parameter mutation tool with dedup, posture, and quota rules is justified, though the middle sentence is dense and slightly run-on.

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?

Because there is no output schema, the description correctly takes responsibility for return values ('the move id and posture') and covers the key edge case (already-on-board returning the existing id). Constraints (never post, quota, draft_only) and the follow-up step (update_draft) are all present. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 100%, so each parameter is already documented (title naming, why length, kind enum, target address, draft, sources). The description adds modest color — relating kind to the draft_only posture and why to the 'twenty minutes' framing — but does not meaningfully extend per-parameter meaning. 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 opening sentence names a specific verb and resource: 'Put a discussion thread you found onto the founder's growth board as a pending move.' This clearly separates propose_move from the move-lifecycle siblings (ship_move, skip_move, archive_move, undo_move, get_move) by anchoring on the 'pending' state, and the draft_only posture further pins down its role versus the founder-posting 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?

An explicit WHEN clause states the trigger: a thread the board does not already carry, read on a community the founder works, with a reason it is worth their time. The dedup line ('A thread already on the board hands back its existing move id') implies the when-not case, and update_draft is named as the follow-up. However, it never explicitly contrasts this tool with related siblings such as ship_move or skip_move, so the guidance 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?

The description goes beyond the annotations by disclosing overwrite behavior (recording twice replaces earlier wording, pinned claims are left as is), the required 'act' scope, and the return payload (top of board with move ids). readOnlyHint=false is consistent with the described write behavior, and destructiveHint=false is not contradicted.

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 efficiently organized with 'WHEN' and 'WHAT COMES BACK' markers, front-loading the core purpose first. Every sentence carries distinct information—trigger, exclusions, auth, overwrite behavior, return shape—so nothing is wasted despite the 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 tool with no output schema, the description compensates by specifying the return value, required scope, overwrite semantics, and exact inclusion criteria. All five parameters are covered by the schema, and behavioral dependencies (pinned claims) are disclosed. No significant gap remains for an agent to decide 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 100% schema coverage, the schema already documents each parameter. The description adds meaningful semantic framing—number must be a real measurement, never an estimate, and the caveat must accompany it ('a number without its caveat is what this library exists to prevent'). This clarifies relationships between parameters beyond their individual schema descriptions.

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

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

The description uses a specific action ('Put one measured number... into the claim library') and clearly scopes what belongs: only measured numbers the founder will defend. It distinguishes this tool from similar record-style siblings by defining its exact input conditions, even though it doesn't name the sibling explicitly.

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?

WHEN gives a concrete trigger (real measurement lands, founder says they would defend it) and the NEVER-list provides explicit exclusions (estimates, projections, rival figures, inferred data). It lacks an explicit pointer to alternative tools like record_insight, so routing is strong but not fully complete.

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 give readOnlyHint=false / destructiveHint=false, and the description adds beyond that: it states the 'act' scope requirement, clarifies 'no spend or posting' (bounding side effects), and instructs 'Keep run_key stable' (idempotency/retry behavior). This is meaningful disclosure for a write tool, though it omits what the response/return looks like.

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

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

Front-loads the core action, which is good, but then packs multiple dense, occasionally cryptic clauses into one run-on block ('a legacy reply retains its saved X status as the destination'). Sentences are efficient but several require re-reading, costing 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 12-parameter, nested-object tool with no output schema and 0% field docs, the description covers operations, key conditionals, and a sibling handoff, but it does not document the required operation values' behavior or the free-text fields. Adequate but with clear gaps given the schema 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 description coverage is 0%, so the description must carry parameter meaning. It explains operation via 'idea or draft', the conditional link between action_kind and idea_id/source_idea, source URL's evidentiary role, and adopt_legacy's fields. However it leaves why, text, title, channel, and claim_ids entirely untreated, so the burden is only partially met.

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?

Opens with a specific verb and resource ('File a growth idea or original X draft'), so the agent immediately knows this creates content records. It does not directly contrast itself with record_claim, record_insight, or redraft_output, but the imperative 'file idea/draft' framing is distinct enough to distinguish from most siblings.

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

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

Provides real conditional routing: new drafts require action_kind social_post plus one of idea_id or source_idea; adopt_legacy is restricted to classifying an exact saved replay; and it defers completion work ('Read get_move; use existing move verbs'). No explicit when-not beyond the adopt_legacy restriction, but the constraints are actionable.

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?

Annotations only say readOnlyHint=false and destructiveHint=falsecars, but the description adds substantial behavioral detail: manual-only operation, refusal when placeholders/broken links exist, preservation of revision history, and the required 'act' scope and Founder tier. This goes well beyond the annotations and gives an agent a clear picture of exact behavior and side effects.

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 cluster of sentences, each delivering essential information: action, manual/AI distinction, refusal conditions, revision history, and auth/price. It is front-loaded with the core action and avoids wasted words, though slightly dense compared to the tersest examples.

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?

While the description covers many behavioral aspects, there is no output schema and no mention of what the tool returns on success or how to verify the replacement (e.g., updated output object, revision ID). The complex draft_fence parameter is also only documented in the schema description, not in the tool description, leaving a significant contextual gap for an agent deciding how to invoke the tool.

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

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

Schema description coverage is 100%, covering all three parameters including the nested draft_fence. The description does not add additional parameter-level semantics beyond referring to the body replacement; it relies on the schema's parameter descriptions, which is sufficient per the high coverage baseline.

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') and resource ('drafted marketing output's body') and specifies when it applies ('before it is shipped'). It does not explicitly name or distinguish itself from the sibling tool 'update_draft', but the 'Manual replacement only' line implies a contrast with AI-driven redrafts, making the purpose reasonably unambiguous.

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

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

The description gives useful context: this is for manual replacement of a draft before shippingalert, and it notes refusal conditions. However, it does not explicitly mention when to use this tool versus an alternative like update_draft or accept_move, nor does it state any exclusions or prerequisites beyond the tier/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?

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 openly discloses that the operation 'SPENDS MONEY', requires specific auth scopes, uses an idempotency key, and is bounded by credit balance and rate caps. These details go far beyond the simple readOnlyHint and destructiveHint annotations, providing excellent behavioral transparency.

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

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

The description is concise and front-loaded, with 'SPENDS MONEY' as an immediate warning. Each sentence adds essential information: purpose, prerequisites, limits, and frequency. There is no redundancy or filler.

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

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

The description covers the tool's purpose, prerequisites, costs, and limits thoroughly. However, it does not mention the return value or whether the operation is synchronous/asynchronous, which would be useful given there is no output schema. Still, it is complete enough for a simple trigger action.

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 documents the single parameter idempotency_key with a description ('Client-minted key (1-200 chars)'). The tool description only repeats 'an Idempotency-Key you mint' without adding new meaning, so the baseline of 3 for high schema coverage 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 action ('run the growth-move generator on demand to top up the Feed') with specific resources (Feed, marketing moves) and domains (SEO, AI visibility, competitors, distribution). This distinguishes it from sibling tools like list_feed or run_loop, 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 strong context: it is for on-demand top-ups, requires write scope and a paid plan/trial, and is subject to daily/monthly caps and a once-per-day-per-product limit. It does not explicitly name alternative tools, but the prerequisites and constraints effectively guide appropriate usage.

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

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

Beyond the readOnlyHint and destructiveHint annotations, the description discloses meaningful side effects: ready remains unpublished until founder confirmation, shipped is retained only for stored legacy jobs, and omitted attempt_id cannot turn managed work into legacy. It also states the required scope and that the operation is free, which is 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?

Four dense sentences front-load the core action, and each subsequent sentence adds a distinct constraint or caveat. There is no filler, and the description stays compact despite covering several edge cases.

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

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

For an action with 8 parameters, high schema coverage, and no output schema, the description covers the essential call logic: valid states, preconditions for ready, legacy handling, auth requirements, and cost. An agent can construct a correct call with minimal ambiguity.

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

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

Schema coverage is high at 88%, so the baseline is 3. The description adds state-specific semantics such as ready requirements, the shipped legacy exception, and the exact attempt_id rule, going beyond what the property names alone convey. Some of this duplicates the schema's attempt_id description, but the added state logic earns a 4.

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

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

The description opens with a precise action: report a claimed attempt as running, ready_for_review, or failed, always with the exact attempt_id. It also clarifies the shipped edge case for legacy jobs, so the tool's scope is clear and distinguishable from generic state setters.

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 concrete usage conditions: ready requires prepared_content or a prepared asset_url, shipped is only for legacy jobs with null attempt_id, and omitting attempt_id never converts managed work into legacy. It does not explicitly name sibling alternatives or say when not to use report_job, but the stated conditions strongly imply the decision context.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false; the description goes beyond them by disclosing that no publication side effect ever occurs, that a revision spawns a new attempt only if the concurrent transaction wins, and that the call requires the 'act' scope and costs nothing. The 'inspected' precondition on legacy results is additional behavioral context not present in 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?

Roughly 45 words across four short sentences, with the purpose and operations front-loaded. Every sentence adds a distinct fact — operation set, transactional revision behavior, no-publish guarantee, cost/scope — and there is 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 an 11-parameter, four-mode, CAS-guarded tool with no output schema, the description is too thin: it omits how the expected_* fields serve as concurrency tokens, what the response contains (e.g., a new attempt id after revise), and which parameter combinations are valid per operation. The schema's operation description fills the adopt_legacy_result gaps only; the rest is left to 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?

Schema description coverage is only 18% (just operation and expected_attempt_id are documented), and the description only loosely compensates with the 'transaction wins' phrase. It never explains the optimistic-concurrency parameters (expected_move_updated_at, expected_legacy_updated_at, expected states) or which parameters apply to each operation, so an agent must infer the CAS mechanics from the operation enum text alone.

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

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

States a specific action ('Apply one explicit founder review decision') on concrete resources ('current managed attempt', 'unfinished work', 'legacy result', 'recorded publication') and enumerates the four operation modes (revise, withdraw, adopt_legacy_result, correct_publication). These operations are unique among the move-family siblings (accept/archive/propose/ship/skip/undo), so an agent can distinguish it without inspecting the schema.

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

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

Provides clear context: 'This never publishes anything' rules out the tool when a publication effect is desired, revision is gated on the transaction winning, and it requires the 'act' scope and is free. It stops short of explicitly naming sibling alternatives, so the when-not-to-use guidance is implied rather than fully stated.

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

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

The description discloses critical side effects beyond the minimal annotations: 'SPENDS MONEY', costs 1 credit, requires write scope, is capped, and has idempotent replay behavior. This provides the agent with the consequences of invocation, which the annotations alone do not convey.

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

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

The description is dense but efficient; every sentence adds essential information (cost, scope, caps, idempotency, eligibility). It is front-loaded with the 'SPENDS MONEY' warning. No fluff.

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

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

For a money-spending mutation tool with no output schema, the description covers the action, cost, prerequisites, limits, and acceptance criteria. It could mention the return value or failure modes, but it still provides enough for an agent to decide 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?

The schema already documents both parameters with descriptions, but the description adds important semantics: the idempotency_key must be client-minted, and repeats replay at no cost regardless of key. It also clarifies that loop_type must be a provisioned, runnable type, enriching the schema's simple examples.

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: 'trigger one on-demand generation run of a growth marketing loop' and gives concrete examples (linkedin_post, geo_improvement, competitor_intel). It distinguishes from sibling tools like set_loop_cadence and get_loop_status by focusing on the on-demand execution.

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 usage context: requires 'write' scope, idempotency_key, is bounded by caps, and only accepts runnable, provisioned loop types (referencing get_loop_status). It explains the one-run-per-cycle idempotency behavior, which informs when to reuse keys. However, it doesn't explicitly name alternative tools for scheduling or other operations, so it stops short of full when-not-to-use guidance.

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

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

Annotations 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral details: permission requirements, the speed constraint, and that 'default' clears any override. This enriches the agent's understanding of side effects and limitations without contradicting 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, each with a distinct purpose: core function, requirements, and behavioral constraint. No wasted words, and the most important information is front-loaded.

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

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

For a simple two-parameter tool with no output schema, the description covers purpose, requirements, constraints, and reset behavior. It lacks explicit alternative tool references, but overall it is sufficient for an agent to select and invoke the tool 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 description explains the cadence values (including the reset behavior of 'default') and implies the loop_type parameter via 'growth marketing loop'. With 50% schema coverage, this adds meaningful context beyond the raw schema, especially for the cadence enum.

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 with a specific verb ('Set') and resource ('growth marketing loop'), and enumerates the exact cadence values. It also differentiates from sibling tools like set_loop_autonomy and run_loop by focusing on cadence scheduling.

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 for when to use the tool by specifying required scope ('config') and tier ('Founder'), and imposes a key constraint (only slow/pause, never speed up). It does not explicitly name alternatives or when-not-to-use cases, but the context is strong enough to guide correct usage.

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

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

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?

Annotations already mark readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context beyond that: setting is free, only usage above 15 included questions is billed, narrowing costs nothing and refunds nothing, and omitting the body reads without changing anything.

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 action and parameters, and most sentences carry distinct information about scope, cost, and read mode. It is slightly wordy and dense in the billing sentence, but every component 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?

There is no output schema, so the description appropriately explains the return value as the credits drawn above the included 15 questions. It also covers both write and read modes, cost behavior, and parameter scope. Minor missing details like output formatting or persistence behavior prevent a 5.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by linking engines and question count to billing: 'returns the credits a scan draws ABOVE the included 15 questions' and 'Narrowing costs nothing and refunds nothing.'

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: 'Set how AI visibility scans run: engines, questions per scan, cadence.' It also distinguishes this from siblings by scoping it to 'config' and Founder tier, and clarifies a read mode via 'Omit the body to read the config and quote ladder.'

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

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

The description gives clear context for when the tool applies: configuring AI visibility scans, scoped to 'config' and Founder tier. It explains the read-only usage mode but does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion 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?

With only readOnlyHint=false and destructiveHint=false in the annotations, the description carries the behavioral burden, and it does so well: it discloses that this is a write operation, requires the 'act' scope, updates only the founder's profile, never the brand's, performs partial updates, and returns every axis on record plus the top of the board. This gives the agent a clear picture of side effects and response behavior.

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 longer than average, but the length is justified: it uses labeled sections (WHEN, WHAT COMES BACK), front-loads the core purpose, and each sentence adds operational context. Slight redundancy around 'this verb cannot touch it' is acceptable given the importance of preventing writes to the wrong profile.

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 mutation tool with no output schema and sparse annotations, the description covers all essential context: target profile, non-target profile, timing, batching, partial updates, required scope, and the return payload. Nothing critical is missing for an agent to invoke the tool 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 already describes the 'axes' parameter structure well, including the lean enum and strength range, so the baseline is 3. The description adds meaningful usage semantics by instructing to 'leave out an axis with too few observations' and 'send only the axes that moved', which directly affects how the parameter object should be populated.

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 ('Write the calibrated leans...') and a precise target ('FOUNDER'S OWN voice profile, the personal register'), explicitly excluding the brand's profile. This distinguishes the tool from related voice/profile tools like get_voice_profile and clarifies exactly what resource it operates 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?

The description gives explicit WHEN guidance ('after a round, once an axis has enough answers to read'), exclusions ('leave out an axis with too few observations'), and batching rules ('Send one write per round, not one per pair'). It also says to send only axes that moved, which helps the agent decide what to include and when to call the 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?

Beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), the description discloses several important behaviors: it records an attestation rather than publishing, it accepts an optional published_url, it is free, and it requires the 'act' scope. It also emphasizes that the operation must wait for explicit founder confirmation. This is substantial context that helps the agent avoid misusing the 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 four compact sentences, front-loaded with the most important condition ('only after the founder explicitly confirms it'). Each sentence earns its place: one defines the action, one explains the two modes, one clarifies the non-publishing behavior, and one gives cost/scope details. There is no redundancy or filler.

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

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

For a mutation tool with 11 parameters and no output schema, the description covers the essential behavioral context, usage prerequisites, cost, and scope. It leaves some parameter relationships (e.g., expected_legacy_* fields) unexplained, though the schema already documents the required pairing of expected_move_state and expected_move_updated_at for independent_work. Overall it is complete enough for the core decision-making, with minor gaps around legacy state parameters.

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

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

With schema description coverage at only 36%, the description partially compensates by explaining the meaning of completion_kind (prepared_result vs independent_work) and clarifying that published_url is optional and merely recorded. However, it leaves several parameters ambiguous (job_id, attempt_id, note, expected_legacy_state, expected_legacy_updated_at) and does not fully replace the missing schema descriptions. It adds meaningful value for the core parameters but not comprehensive 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 states a specific action ('Record completion') on a clear resource, and immediately qualifies it with the condition that the founder must explicitly confirm. It also distinguishes the tool from publish-like operations by explicitly saying it 'never publishes anything.' This makes the purpose 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 gives explicit selection guidance for the completion_kind parameter: use 'prepared_result' after reviewing the prepared attempt, use 'independent_work' when the founder completed it separately. It also states the prerequisite that the founder must confirm. However, it does not name any sibling tools or contrast this action with alternatives like accept_move or review_move, so the 'when not to use' context is missing.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds the 'act scope' requirement and notes that feedback improves future marketing drafts, providing behavioral context beyond the annotations. It does not contradict annotations and adds value by explaining the learning loop effect.

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 concise sentences, front-loaded with the action. It includes only essential information without fluff, making it easy to parse quickly.

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

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

For a simple skip action, the description covers the operation, cost, required scope, and feedback effect. It does not mention return value or reversibility (undo is implied via sibling), but this is not critical for basic invocation given the provided annotations and schema.

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

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

Schema coverage is 100%, with each parameter already described in detail (move_id, feedback_key enum, feedback_note maxLength). The description only restates the purpose of feedback_key/note, adding no extra semantic value beyond what the schema provides.

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

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

The description clearly states the verb 'Dismiss' and the resource 'growth move', with a clarifying parenthetical '(Skip in the Feed)'. This distinguishes it from siblings like archive_move and undo_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?

Provides useful context such as 'Free' and 'requires the act scope', but does not explicitly mention when alternatives like archive_move or undo_move should be used. The sibling names make the distinction fairly clear, but no direct exclusions are given.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description reveals important behavioral details: invalid drafts with unfilled placeholders or broken links are refused, the operation is free, and the 'act' scope is required. This gives the agent meaningful expectations about validation and auth without relying on 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?

Two tightly packed sentences front-load the core operation and immediately follow with failure behavior and prerequisites. No wasted words; every clause adds operational relevance.

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

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

For a mutation tool with a nested object parameter and no output schema, the description covers purpose, lifecycle timing, validation, cost, and scope. It does not mention the draft_fence parameter, but the schema's own description for that parameter provides the necessary guidance, so the overall tool definition is sufficiently 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?

With 100% schema description coverage, the baseline is 3. The tool description adds value by explaining that draft_content must be a valid marketing draft body and by stating the validation rule around placeholders and broken links, which clarifies acceptable inputs beyond the schema's basic string constraints.

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 a pending growth move's marketing draft body before shipping'—with a clear verb (replace), resource (marketing draft body), and lifecycle context (pending, before shipping). This differentiates it from siblings like redraft_output or ship_move without needing to inspect either schema.

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

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

The description provides clear context for when to use the tool—only for pending moves before shipping—and states that invalid drafts are refused rather than saved. It does not explicitly name sibling alternatives or exclusion conditions, so it stops short of full when/when-not guidance.

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

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

The description adds behavioral context beyond the readOnlyHint annotation, such as feed_ready being false while the deep scan builds and credits only available once metering is live. This helps the agent understand the asynchronous nature of certain returned fields and plan accordingly. 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, dense sentence that front-loads the purpose and packs in relevant details. It is efficient, though slightly overloaded with multiple clauses; splitting it into two sentences could improve readability without losing information.

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

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

Given no output schema, the description thoroughly covers the expected return values (product run, scopes, tier, trial_ends_at, feed_ready, credits) and the timing of their availability. It also provides usage context that makes the tool's role clear in the broader workflow.

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

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

With zero parameters and an empty input schema, there is no need for parameter explanation. The baseline for a zero-param tool is 4, and the description adds value by explaining the returned fields instead, which is appropriate.

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

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

The description clearly states the tool's function: 'Confirm the AfterLaunch key works' and enumerates the specific information it returns (product run, scopes, tier, trial_ends_at, onboarding, credits). This distinguishes it from sibling tools by establishing it as an identity/context check to be called first.

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 instructs 'Call this first' before any growth or marketing work, and provides additional timing guidance (wait for feed_ready before reading the Feed, credits once metering is live). This clearly indicates when to use the tool and sets expectations for subsequent actions.

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