AfterLaunch

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

Goes well beyond the annotations, which only mark it non-readOnly and non-destructive. It discloses idempotency ('a repeat never starts another worker'), the conditional side effect (worker starts only when launch_won is true), durability ('one durable preparation attempt'), cost ('free'), and the required scope ('act'). All meaningful traits the agent needs.

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

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

Four compact sentences, each carrying distinct information: precondition, side-effect condition, idempotency, and cost/scope. Front-loaded with the gating condition and 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?

Covers the operation semantics and safety profile well for a 7-param write tool with no output schema. Leaves target enum values and the retry/legacy-state parameters to the schema, which is acceptable given its partial descriptions, but a sentence on the target choices 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?

Schema coverage is 57%, so roughly half the parameters are described in the schema (move_id, operation, expected_attempt_id) and the others (note, target, expected_legacy_state, expected_legacy_updated_at) rely on enums or are undescribed. The description adds nothing about parameters, so it neither compensates for the gap nor duplicates the schema. 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?

Clear verb+resource: accepts a move, with the precondition that the founder has said yes. Distinguishes itself somewhat from siblings like ship_move, propose_move, and review_move by framing this as the acceptance step, though it doesn't explicitly contrast with them.

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

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

States the gating condition ('only after the founder says yes') and mentions the launch_won=true trigger, which is clear context for when to invoke. It stops short of naming when NOT to use it or pointing to a specific alternative sibling for the pre-acceptance flow.

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?

Discloses key behavioral traits beyond annotations: the data is read-only and free, never generates or revises strategy, strategy is dated judgment rather than measured evidence, and missing facts/strategy return null. This is rich, accurate context that helps the agent interpret the result correctly.

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

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

Every sentence carries useful information: first sentence inventories the content, second sentence prescribes usage and data interpretation. No filler or repetition of annotation fields.

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, no-output-schema tool, the description fully covers what the agent can expect: content fields, source/versioning, null semantics, and the evidential status of strategy. Nothing necessary for correct invocation or interpretation is missing.

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

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

The tool has zero parameters and 100% schema coverage (empty schema), so there is no parameter meaning to add. The description instead clarifies the semantic quality of the returned data (null for missing, dated judgment for strategy), which is more relevant for a parameterless 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?

Description names a specific resource ('structured business positioning, audience, ICP, pricing, features and competitors') and a specific action ('Read before planning or writing'). It clearly differentiates from sibling get_* tools by listing its unique content scope, including growth_strategy with version/source/date details.

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 guidance on when to use it ('Read before planning or writing') and a clear exclusion ('never generates or revises a strategy'). It also advises cross-checking strategy against current founder intent, but does not name alternative sibling tools or specify when NOT to use it beyond the generation/revision exclusion.

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 'never runs one' and the interpretive guard 'each is an observation, not a rate,' which provides meaningful context 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?

Three short sentences carry purpose, ordering, safety, and interpretation with no filler. Each clause earns its place, and the most distinguishing 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?

Given read-only annotations, three optional parameters, and no output schema, the description covers what is returned (already-run experiments, newest first), the safety profile, and a key interpretation caveat. The main gaps are the lack of explicit filter semantics and output shape, but they are minor for a simple list tool.

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

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

Schema description coverage is 0%, and the description does not explain limit, idea_id, or experiment_id. The parameter names are somewhat self-explanatory, but 'with scoped evidence' only vaguely hints at filtering, leaving the agent to guess how the parameters shape the result.

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 a specific resource (growth content experiments), states they are already run, and adds ordering ('newest first') and a semantic qualifier ('each is an observation, not a rate'). It does not explicitly distinguish from sibling tools by name, but the purpose is unambiguous.

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

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

The description implies this tool is for retrieving historical experiments and explicitly notes it never runs one, which helps route an agent away from using it for execution. However, it does not name alternatives or state when to prefer this over siblings like get_scoreboard or get_outcomes.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so 'Read-only, free' is largely redundant. The real added value is the data-semantics disclosure: 'Ready means awaiting review, not published', 'Closed post-trial access withholds bodies without asserting absence', and how to interpret tracked_link_state and null clicks. With no output schema, these interpretation rules carry genuine behavioral weight.

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

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

Compact and front-loaded — it leads with what the move contains before the finer interpretation rules. No filler sentences. A few fragments ('null clicks means unreadable') are terse to the edge of ambiguity, which slightly hurts 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?

With no output schema, the description must explain the returned fields, and it does: it enumerates the payload shape (evidence, source material, instructions, prepared_result), clarifies linked_article, and decodes the ambiguous status/null fields. For a one-parameter read tool, nothing essential is missing.

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

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

Schema description coverage is 100% with a single parameter, and the schema already documents 'Move id (uuid), from list_feed or get_standup'. The description repeats the same provenance without adding format or validation detail. With high coverage, the baseline 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?

States the resource and its contents ('One growth move: evidence, source material, instructions and prepared_result'), making it clear this returns a single move rather than a list. It implicitly differentiates from siblings by naming list_feed/get_standup as the id source, though it never uses an explicit retrieval verb. Clear enough to distinguish it from list_feed and the many *_move mutation 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?

It tells the agent where move_id originates (list_feed or get_standup), which is useful routing context for the prerequisite step. However, it gives no explicit when-to-use-this-vs-alternative guidance (e.g. when to call get_move versus review_move or get_standup). Usage is implied rather than 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?

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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: the operation is read-only and free, and it discloses the sampling caveat that changes should be treated as indicative unless the sample count licenses otherwise. 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 dense but front-loaded with the core purpose, then adds sampling caveats and drill-down guidance. A few phrases are packed together, but each sentence earns its place and the structure supports a complex read-only reporting tool.

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 results include, and it does: engine answers, share of voice, cited sources, gaps, trend, crawlability, off-site reach, sample counts, and the drill-down parameter. It also embeds the critical sampling interpretation and workflow placement, making it complete 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 coverage is 100% and the single optional parameter is already described in the schema as drilling into one tracked question for engine answer text and citations. The description repeats this without adding material new semantic detail, 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?

Description clearly names the resource: measured AI visibility (GEO) results across specific engines, plus components like share of voice, cited sources, and trends. It is unambiguous about what get_visibility returns, though it does not explicitly contrast itself with sibling tools like get_seo by name.

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?

Gives explicit sequencing: 'Read after refresh_scan and before any AI visibility or GEO work.' It also explains when to pass prompt_id for drilling into a single question. It does not name alternatives or state when-not-to-use, 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 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?

Annotations already declare readOnlyHint=true, but the description adds meaningful behavioral detail beyond those annotations: it is free on every plan, enforces a hard cap of 15, returns prompts in tracking order, and explains that curated: false means AfterLaunch generated the prompt and it can be replaced. For a read-only list tool with no output schema, this is strong 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 dense but efficient: purpose, return contents, usage guidance, and availability are all covered in four sentences. It could be slightly tightened (the first sentence's phrasing is a bit tangled), but every clause 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?

Given zero parameters, read-only annotations, and no output schema, the description supplies everything an agent needs to call the tool correctly: what it returns, the hard cap, the meaning of the curated flag, and why to call it before track/untrack operations. No critical gap remains.

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

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

The tool accepts zero parameters, so the parameter-semantics burden is minimal; the baseline for 0-parameter tools is 4. The description wisely focuses on what the response contains rather than nonsensical parameter explanation.

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

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

The description starts with a specific verb-resource pair: lists the tracked prompts that AfterLaunch maintains, and distinguishes them from generic prompts by explaining they are the AI visibility (GEO) question set. It precisely names the tool's output (prompts, cap, used, curated flag), leaving no ambiguity about what the tool does.

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 this tool before track_prompt or untrack_prompt to avoid duplicating questions or misjudging remaining capacity. This provides clear usage context and directly references the sibling tools that an agent might otherwise confuse it with.

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 are minimal (readOnlyHint false, destructiveHint false), so the description carries the burden of behavioral disclosure. It states 'Requires act scope; no spend or posting' and 'keeps evidence holds and never authorises drafting,' which are useful constraints. However, it's ambiguous what 'keeps evidence holds' means and doesn't fully explain side effects like whether existing data is modified. It adds some value beyond annotations but not comprehensive.

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 paragraph that mixes operational rules, constraints, and parameter notes without structure. It's over 200 words, front-loads the purpose but then rambles through exceptions and conditions. It would benefit from bullet points or separation by operation. Every sentence carries weight, but the lack of organization makes it hard to parse.

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

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

Given the tool's complexity (14 params, nested objects, 3 operations, no output schema), the description is incomplete. It covers the three operations and some constraints but doesn't explain critical parameters like why, text, title, channel, idea_id, claim_ids, or the structure of research and source_idea. It also doesn't mention return values or error conditions. An agent would struggle to build a correct request without consulting additional resources.

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 0%, the description must compensate for all 14 parameters. It only mentions a handful (run_key, action_kind, source_url, adopt_legacy, expected_updated_at) and leaves others like why, text, title, channel, idea_id, research, claim_ids, and source_idea unexplained. The description gives partial semantics for some operations but fails to define the majority of parameters, making it insufficient for correct invocation.

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 'File a growth idea (optional channels, kind, score), original X draft or research outcome,' which clearly states the tool's main function: creating content records of three types (idea, draft, research). It distinguishes from siblings like record_claim and record_insight by focusing on content creation rather than claims or insights, though it doesn't explicitly name alternatives. The purpose is specific enough to be 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 provides operation-specific guidance: research appends results to an idea, drafts require action_kind social_post and one idea_id or source_idea, adopt_legacy reclassifies an exact saved replay, and completion uses move verbs. It explains when each operation is appropriate, though it doesn't explicitly mention when not to use the tool or name sibling tools as alternatives. The guidance is clear and contextual.

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 adds substantially more: idempotency semantics ('recording the same insight twice replaces your earlier note; a pinned note is left as it is'), the required 'act' scope, that the call is free, and the return payload ('the top of their board with move ids'). This is behavior the agent could not infer from structured fields.

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-loaded with the core action and organized into WHEN, constraints, cost/scope, and WHAT COMES BACK sections. It is on the verbose side, but nearly every sentence carries distinct information, so little is wasted.

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

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

No output schema exists, but the description explains the return value in prose ('the top of their board with move ids'). Combined with scope, cost, idempotency, and content constraints, an agent has everything needed to call this 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%, so all three parameters are already documented in the schema, including the kind enum and the source_move_id uuid origin (list_feed). The description reinforces the 10-500 character and one-sentence constraints but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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 verb and resource: 'Write one durable thing you have learned... into AfterLaunch's Memory,' and defines Memory as the record drafts are written from. It distinguishes itself from siblings by explicitly excluding restatements of get_snapshot/get_kb_page and by passing voice rules to record_voice_rule. An agent can tell this apart from record_claim or record_content without opening schemas.

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 WHEN clause ('the moment the founder tells you something that will still be true next month and that AfterLaunch could not have measured itself'), plus concrete negative guidance ('Never record chatter, a passing mood, a restatement of get_snapshot or get_kb_page, or anything you inferred'). The kind schema description additionally routes voice rules to record_voice_rule.

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 it is a non-read-only, non-destructive write. The description adds genuinely useful behavior the annotations cannot: it requires the 'act' scope, is free, persists into Memory where the user can see and remove it, and is consumed downstream by morning marketing drafts, get_move, and get_voice_profile.

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 purpose, then WHEN, then constraints; no filler sentences. The middle sentence listing downstream consumers is a little dense and harder to parse than the rest, costing it the top score.

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-param persistence write with no output schema, it covers scope/auth, approval prerequisite, persistence/removal, and downstream effects. The only soft spot is the cryptic 'At most 12' whose unit is never stated.

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% (baseline 3), but the description adds constraints beyond the schema: the rule must be 'One sentence' and 'At most 12' (presumably words, though the unit is left implicit). This meaningfully narrows how to fill `text` relative to the 200-char cap.

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 verb+resource with scope: 'Save one writing rule the person approved into their OWN voice, never the brand's.' The 'OWN voice, never the brand's' qualifier distinguishes it from siblings like record_claim, record_insight, and set_voice_axes.

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 WHEN and a hard exclusion: 'only after they approve it in words' and 'Never record one they did not approve', including a concrete trigger (a yes to a rule proposed from an edit). It does not name an alternative tool for recording brand-level rules, so routing against siblings is left implicit.

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 it as a non-read, non-destructive write, so the description carries real extra weight: it adds cost ('Free'), an auth requirement ('act' scope), a no-publish guarantee, and CAS semantics ('Revision starts a new attempt only when this transaction wins'). It stops short of describing failure/conflict behavior when the CAS check loses.

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

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

Three compact sentences, front-loaded with the action and its enumerated decisions, then constraints. No filler; every clause (scope, cost, no-publish, CAS) carries 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?

For a complex 11-parameter mutation with no output schema and low schema coverage, the description covers scope, cost, and concurrency but omits parameter-level meaning, conflict/error outcomes, and return shape. Adequate orientation, but not enough to call it confidently without opening the schema.

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

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

Schema description coverage is only 27% across 11 parameters, so the description must compensate and largely does not. It says nothing about move_id, job_id, note, asset_url, prepared_content, expected_move_state, or the two updated_at CAS fields; only the operation and attempt/CAS concepts get indirect mention. Two of the eleven params carry schema descriptions, leaving most undocumented.

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 verb ('Apply one explicit founder review decision') and then enumerates the four exact operations (revise, withdraw, adopt_legacy_result, correct_publication). This clearly separates it from siblings like accept_move, ship_move, skip_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?

The enumerated decisions effectively tell the agent which situation maps to this tool versus the other move tools, and 'This never publishes anything' sets a boundary. However, it never explicitly names an alternative (e.g. use ship_move to publish) or states when NOT to use it, so routing still requires 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 only say readOnlyHint=false/destructiveHint=false; the description adds real behavioral context beyond that — it never posts anywhere, requires the 'act' scope and Founder tier, is free, and mandates truthful reporting because an unreported result blinds the record. This is substantive disclosure the annotations do not carry.

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-loaded with the core action and routing, and most sentences earn their place. It is somewhat verbose, restating the human-decision/your-reporting split twice, which trims a point off otherwise tight structure.

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

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

For a mutation tool with no output schema, the description covers everything an agent needs: what it changes, that it does not publish, the required scope and tier, the alternative publishing tool, and the reporting obligation. Nothing material is missing.

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

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

Schema description coverage is 100%, so the schema already documents output_id, action, and final_text in detail. The description reinforces action semantics and the honesty constraint on final_text, but adds little syntax the schema lacks; baseline 3 applies when the schema does the heavy lifting.

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 verb (resolve) and resource (one drafted marketing output in the review queue), names the source sibling (list_outputs), and distinguishes its two actions from real publishing by explicitly contrasting with approve_output. An agent can tell exactly what this does versus its 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 explicit WHEN guidance: call 'ship' only when the founder confirms the content is out and with their go, 'skip' when they decide against it. It also names the alternative path (approve_output for actual publishing), so both the trigger and the exclusion are 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?

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?

With only readOnlyHint=false and destructiveHint=false in annotations, the description carries real added burden and meets it: it discloses the act scope requirement, that the call is free, and most importantly that it 'records an attestation; it never publishes anything' – a non-obvious side-effect profile for a tool named 'ship'.

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-loaded with the confirmation gate, then the kind selection, then the published_url rule, then the attestation/scope footer. No sentence is 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 13-param, no-output-schema tool this covers the decision logic and safety profile well, and the attestation framing tells the agent what the call effectively returns (nothing published). The gap is the undocumented expected_* concurrency parameters and their required-with relationships.

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

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

Schema coverage is only 54% across 13 params. The description adds genuine meaning for completion_kind, published_url (explicitly distinguished from planned_url), and final_text, but says nothing about the optimistic-concurrency params (expected_move_state/expected_move_updated_at, required for independent_work per the schema) or how job_id/attempt_id relate.

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 verb (record) and object (completion of a move), and the gating condition (founder confirmation). It is distinguishable from lifecycle siblings like accept_move, review_move, skip_move, and undo_move, though it never names them 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?

Gives concrete selection guidance between the two completion_kind values ('prepared_result after reviewing the current prepared attempt' vs 'independent_work when the founder completed it separately') plus a conditional rule (site changes need a live published_url or they stay prepared). It does not, however, contrast against the other move-lifecycle siblings.

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

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

Annotations already 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 say readOnlyHint=false and destructiveHint=false. The description goes much further, disclosing that the next scheduled scan runs at full depth, the week-over-week trend re-baselines, questions are deduplicated, and there is a hard cap of 15. This is exactly the kind of side-effect transparency agents need.

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, then packs consequences, constraints, auth requirements, and upgrade behavior into a few tight sentences. Every sentence earns its place, and there is no redundant padding.

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

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

For a single-parameter tool with no output schema, the description covers cost, side effects, constraints, permissions, plan requirements, and free-trial behavior. There is nothing an agent needs to know before calling it that is missing.

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

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

Schema coverage is 100%, so the baseline is 3. However, the description adds meaning beyond the schema by explaining that the text is a customer question, is deduplicated, and counts against a hard cap of 15 tracked prompts. This is useful context that the schema alone does not convey.

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 first sentence names a specific operation ('Add one customer question') and the exact resource ('AI visibility (GEO) set'), making it easy to distinguish from untrack_prompt and list_tracked_prompts. The rest of the description reinforces this by explaining what changing the set does.

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: add deliberately rather than churning, and the consequences of changing the set. It does not explicitly name sibling alternatives (e.g., untrack_prompt for removal), but the purpose is clear enough that an agent can infer when to use this tool.

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

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

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

With only minimal annotations, the description fully carries the behavioral burden: it discloses idempotence, case- and punctuation-insensitive matching, no monetary cost, the two side effects (full-depth scan and trend re-baselining), and auth requirements (config scope, Founder plan). This goes well beyond what the annotations provide.

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

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

Three dense sentences with no filler. The primary action and cap implication come first, followed by consequences, matching behavior, and auth. Every sentence earns its place.

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

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

For a one-parameter mutation tool with no output schema, the description covers everything needed to invoke it correctly: what it does, why it exists (cap management), side effects, idempotence, matching rules, and required permissions. Nothing essential is missing.

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

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

The single parameter is already fully documented in the schema, including the matching behavior and the source list. The description restates the matching semantics rather than adding new parameter-level detail, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource: 'Remove one customer question from the AI visibility (GEO) set'. It adds concrete context about the cap of 15 slots and clearly distinguishes this from its sibling by naming track_prompt and describing the inverse action.

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

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

The description makes the usage context clear: use it to remove a tracked question and free a slot against the cap. It references track_prompt and the same consequences, but does not explicitly state when-not-to-use or name alternatives like list_tracked_prompts as the source for the text to pass.

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.