Shipfound

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the audit is the stored/latest one (so no filtering or re-run occurs), outlines the shape of what is returned, and notes it is free of cost — a genuine trait. It omits behavior when no audit exists, freshness semantics, and any permission requirements, so it is only partially complete.

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

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

A single tightly packed sentence with the resource front-loaded and the cost note trailing; nothing is padded. The phrase 'what was seen and the fix' is slightly cryptic, which keeps it just short of ideal.

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

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

For a zero-parameter read tool with no output schema and no annotations, the description should describe the return payload more concretely and state the empty/missing case (what happens before any audit is recorded). It gives a reasonable outline of returned content but leaves the freshness and error-state behavior unspecified.

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 takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly implies a parameterless, always-latest retrieval.

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 resource precisely (the latest stored access audit) and enumerates its contents (areas, status, observations, fix), which is more than the bare name 'access' conveys. It does not, however, distinguish itself from nearby siblings like record_access (presumably the write counterpart) or app_audit, so sibling differentiation is missing.

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 when-to-use guidance, no statement of what this replaces (e.g., running a fresh audit via record_access), and no conditions or exclusions. The only usage-adjacent signal is 'Free.', which hints at cost but not at selection between 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?

No annotations are provided, so the description carries the full burden. It usefully discloses that nothing changes in Apple Ads until the founder approves, which is the key safety behavior for a proposal tool. However, it omits auth/permission needs, rate limits, and what the approval flow returns or triggers, leaving gaps for a tool with no annotation coverage.

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 core sentences are front-loaded and reasonably tight, but the trailing tags 'Growth. Free.' add no actionable meaning for an agent and read as leftover categorization. The parenthetical source list is dense and could be cleaner.

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 proposal tool with no annotations and no output schema, the description covers the source, the approval gate, and the per-item required fields, which is the essentials. It still leaves open what happens after approval and how to interpret undocumented fields (matchType, bid), so it is adequate but not complete.

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

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

Schema description coverage is 0% (only 'bid' is documented), so the description must compensate. It does add meaning for kind (keyword vs negative), campaignId, adGroupId, and why ('why' is even a required field). It says nothing about bid semantics, matchType EXACT/BROAD, or the text constraints, so coverage remains partial.

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 ('Propose new exact keywords... or negatives') and clarifies the workflow purpose: founder approval. It references sibling tools (keyword_research as a source, ads_review for campaign/ad group), which helps an agent place it. Slightly muddied by the phrase 'exact keywords' when the schema also permits BROAD match type.

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 clear routing: pull candidate keywords from keyword_research, the App Store keyword field, or reviews, and get campaign/ad group context from ads_review. It implies this is the pre-approval step ('Nothing changes... before the founder approves'). No explicit when-not-to-use statement, but the 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?

With no annotations, the description carries the full burden and does well: it discloses that proposals require the founder's approval and that nothing changes in Apple Ads before that, which is critical non-destructive context for an agent. It omits auth requirements and rate/scope limits, so it stops short of a 5.

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 core is front-loaded and dense with useful detail, but the single-sentence run-on is hard to parse and the trailing fragments 'Growth. Free.' add no operational value. Trimming those would tighten it 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?

For a two-param review-and-propose tool with no output schema and no annotations, the description explains the metrics read, the kinds of proposals generated, and where approval happens (the results app's App Store page). That is close to complete; only tool-routing against ads_propose 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%: both 'days' and 'targetCpi' are already fully documented, including defaults and bounds. The description corroborates the time window and target cost per install but adds no syntax, format, or edge-case meaning beyond the schema, 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?

States specific verbs and resources: reads Apple Ads (campaigns, keywords, search terms) and proposes concrete changes (keywords, negatives, bid moves, pauses, budgets). The change types make the purpose very concrete. However, it never names or distinguishes itself from the sibling ads_propose, leaving the reader to infer which tool actually applies proposals.

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?

Usage is implied by the workflow it describes (review performance, then propose optimized changes), which is enough to know roughly when to reach for it. But there is no explicit when-to-use/when-not guidance and no reference to alternatives such as ads_propose or keyword_research, even though those siblings overlap heavily.

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 no annotations, the description carries the full burden. It usefully discloses the default period (last 28 days) and that the tool is 'Free,' plus the AI Search channel and shipped-work dimension behavior, but it never states read-only status, permissions, pagination, or return shape.

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, followed by an informative enumeration of reports and key defaults. The report list is long but each item earns its place as the primary input value set; the two explanatory sentences add real 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 9-parameter read tool with no output schema, the description covers the report enum and date defaults but is thin on the non-report parameters (filters, limit, metric, interval) and gives no sense of the returned data shape.

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 56%, so the schema already documents several params (to, from, metric, compare, interval). The description maps to the report enum and default period but adds nothing about filters, limit, compare, or metric semantics, leaving the gap only partially compensated.

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

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

The description states a specific verb and resource: 'Run any report on the site's traffic,' and names the available report types matching the enum. It is clearly distinct from most siblings, though it never explicitly contrasts itself with adjacent tools like visibility or goals.

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 or when-not-to-use guidance, and no alternative sibling is named. The list of report types implies what can be requested, but the agent is left to infer selection criteria on its own.

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?

No annotations are provided, so the description carries full behavioral burden. It discloses that it reads a public listing (name, subtitle, rating, reviews count, languages, screenshots) and that it is free, which is useful. However, it does not describe what happens on success (e.g., app appears in workspace), error behavior for invalid URLs, or side effects beyond that it is free.

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

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

Two efficient sentences, front-loaded with the action and input, followed by the read behavior and cost. No wasted words.

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

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

For a single-parameter add tool with no annotations or output schema, the description covers input source, what is read, and cost. It does not specify error handling, workspace requirements, or return behavior, but the core invocation context is 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% and the single parameter is documented there as the apps.apple.com link. The description restates the link format and adds an example (id123), but the schema already provides the required format. Baseline 3 per rules when schema is fully covered.

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 (Add) and resource (founder's iOS app), plus the exact input form (apps.apple.com link). It reads a public listing, which distinguishes it from sibling tools like app_audit or app_reviews that operate on already-added apps.

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

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

The description implies usage ('from its App Store link') but does not state when to use this versus alternatives such as app_audit or app_reviews, nor does it mention prerequisites like having a workspace. Usage context is implied through the input requirement, not explicitly guided.

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 no annotations, the description carries the full burden and does real work: it discloses the reduced-scope fallback when locales are absent, that the keyword field is private without them, that the tool is free, and that it only diagnoses (the fixes are written by the user as a PR). Missing return-shape and rate-limit detail, but the mutation/scope profile is well covered.

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?

Long but dense and front-loaded: the check list comes first, then the locales conditional, then cost/ownership. Every clause conveys a distinct fact, though the single sprawling sentence chain could be split for faster scanning.

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

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

For a 3-parameter diagnostic tool with no output schema, the description says what is checked, what changes the depth of the check, and what the agent gets back in conceptual terms. Return-value format and the appId parameter are the only things an agent might still want.

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 33%, so the description must compensate, and it does for the most complex parameter — it tells the agent exactly where `locales` comes from and which metadata files (name.txt, subtitle.txt, keywords.txt, promotional_text.txt, description.txt) map to fields. `storefront` is covered by the schema itself; `appId` gets no description anywhere, which is the remaining gap.

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 (check) and resource (an app's App Store metadata) and then enumerates the exact rule classes it evaluates — character limits, wasted keyword characters, cross-field word repetition, locale indexing, screenshot captions, AI-answer readiness. That enumeration distinguishes it clearly from siblings like keyword_research or check_content.

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

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

Gives an explicit conditional: pass `locales` from fastlane metadata files for the full check; without them only the public listing is checked and the keyword field is private. That is a clear when-to-use branch, though it never names a sibling alternative or states when to skip the tool entirely.

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?

No annotations are provided, so the description carries the full burden. It discloses that a created page is a draft, starts from live version media, keywords must already be approved, search visibility occurs after approval, and the founder submits for review. However, it omits permissions required, rate limits, what 'list' returns, and side effects of creation beyond draft status.

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 single run-on sentence packs a lot of information but is awkward and not front-loaded; readers must parse multiple clauses to find the core action. It is efficient in length but weak in structure.

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

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

Given 8 parameters, no required fields, no output schema, and no annotations, the description is partially complete: it clarifies draft creation, key constraints, and the ppid/app_site link. It still leaves significant gaps around listing behavior, parameter roles, and operational requirements.

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 25%, so the description must compensate. It adds meaning to keywords (approved-only, search after approval) and screenshots (captioned, from live media) and mentions ppid linkage, but does not explain name, appId, locale, deepLink, or action semantics. Partial compensation warrants a middle score.

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 dual action (list or create a draft custom product page) and enumerates the created artifacts (promotional text, deep link, keywords, captioned screenshots). It is specific but does not explicitly differentiate itself from siblings like app_metadata, app_screenshots, or app_site, other than mentioning ppid linkage.

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

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

No explicit guidance on when to use this tool versus alternatives. The mention that the founder submits for review in App Store Connect and that linking uses app_site is contextual, but there are no when/when-not conditions or named alternatives for the core list/create decision.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses the required auth level (Admin role), a data-availability latency (first report one to two days after connecting), and cost (free). It stops short of describing return structure, pagination, or behavior when no data exists.

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

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

A single front-loaded sentence delivers the metric, breakdowns, and source, with compact parentheticals explaining the source taxonomy and the sf-* campaign meaning. No filler; every clause adds 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 simple two-parameter read tool with no output schema, the description covers what is produced, how it is broken down, and the operational conditions for success. It is nearly complete, lacking only a note on return shape and the appId parameter's role.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies that 'days' means the recent window ('for the last days'), but says nothing about 'appId' or that 'days' is capped at 35. Partial compensation for two undocumented 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 names a specific metric (first-time downloads and redownloads), the breakdown dimensions (source and campaign), and the data source (App Store Connect analytics reports). It is unambiguous about what the tool returns, though it does not name a sibling tool to distinguish itself from close relatives like 'analytics'.

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 availability context (Admin-role key required, first report lands a day or two after connecting, free), which helps an agent know prerequisites. However, it never states when to prefer this over alternatives such as 'analytics', and provides no explicit exclusions, so usage is only implied.

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

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

No annotations are provided, so the description carries the full burden, and it does substantial work: it discloses the draft-only state, who initiates the live test, the 90-day maximum, that only icon/screenshots/previews are tested (not text), and the 3-treatment cap. It stops short of covering permissions, error behavior, or what listing returns.

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 clause, and the following sentences add real constraints rather than filler. The trailing 'Growth. Free.' fragments are low-value tags that do not earn their 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 6-parameter tool with no output schema and no annotations, the description supplies the operational and behavioral context an agent needs: draft status, treatment limits, what Apple tests, the test duration, and the human-in-the-loop start. The unresolved gap is the relationship to the sibling experiment_* tools.

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 33%, so the description must compensate and does so partly: it clarifies trafficProportion is a percent and that treatments are up to 3 sets of captioned screenshots. But name, appId, action and locale are left entirely to the schema, so a meaningful coverage gap remains.

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: 'List the app's product page tests, or set one up as a draft', which makes the list/create duality clear. However, siblings named experiment_create, experiment_results and experiment_close exist, and the description never explains how this tool differs from them, leaving sibling differentiation unaddressed.

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?

Usage is implied by the draft framing ('set one up as a draft') and the workflow note that the founder starts it from the results app or App Store Connect, which tells the agent not to claim it is running. But there is no explicit when-to-use vs the experiment_* siblings, and no stated prerequisites for listing vs creating.

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 no annotations, the description carries the burden and does well: it discloses the auth dependency (ASC key), that the call is a read, that it returns both the in-preparation and live versions, and that it is free. It omits failure modes when the key is absent (beyond the fallback) or any rate/return-shape notes, keeping it just under a 5.

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 what is returned, then the dependency and the fallback; two dense sentences with no filler. The parentheticals are compact, though the sentence is fairly packed.

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 explain the return content (per-locale fields, both version states), and it covers the auth prerequisite. The only real gap is the undocumented appId parameter, which is minor for a one-param 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 single parameter appId has 0% schema coverage and is never mentioned or explained in the description. It is nearly self-evident, but the description makes no attempt to compensate for the empty schema, and it never states whether appId is required or what happens if omitted (required is technically 0).

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?

Specific verb ('read') plus resource (App Store Connect metadata), and it enumerates the fields returned (name, subtitle, keywords, promotional text, description, what's new) across every locale and both version states. It also names the sibling it is not (app_audit), so an agent can distinguish it 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 prerequisite (founder's App Store Connect key connected on the results app page) and an explicit fallback with the alternative named ('without it, use app_audit with the repo's fastlane metadata'). The when-to-use/when-not-to-use decision is fully specified.

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?

No annotations, so the description carries the full burden and does well: it discloses the write target (staged version, not live), that it never submits, that it adds new locales, and the post-step of record_action plus verify. Doesn't mention auth requirements or who is 'founder' precisely, but overall it discloses scope and side effects beyond the schema.

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

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

The first two sentences are front-loaded and dense, but the tail ('Builder and Growth. Free. Afterwards the founder submits... record_action... verify') mixes audience/pricing tags, workflow notes, and a follow-up snippet that strains 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 mutation tool with no annotations and no output schema, the description gives the essential write-target and workflow context but leaves gaps: permissions, whether a version/staging entity must pre-exist, response shape, and how appId interacts with the changes array.

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 schema itself documents field maxLengths, but the description restates the length limits (30/100/170/4000) in prose and names the change types. It doesn't explain the 'changes' array shape, the required locale, or appId semantics, so it partially compensates but not fully.

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: write listing changes into the founder's submittable version through App Store Connect, enumerating which fields (name, subtitle, keywords, promotional text, description, what's new). Distinguishes from app_metadata by clarifying it stages into the pending version rather than touching the live listing.

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?

Clear implicit when-to-use: for editing listing text before submission, with the alternative path (founder submits the version in App Store Connect) spelled out. Lacks explicit when-not guidelines beyond 'never touches the live listing'.

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?

No annotations exist, so the description carries the full burden. It usefully discloses the source (Apple's public feed) and that access is free/no paid tier, but says nothing about authentication, rate limits, freshness/latency beyond 'latest', or what happens at the pages boundary.

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

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

A single dense, front-loaded sentence that leads with the resource and then lists deliverables. Efficient with little waste, though the enumeration of return fields makes it somewhat crammed.

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 cover the return payload well (star counts, per-version ratings, low reviews). But for a 3-parameter tool with low schema coverage and zero required params, the absence of any parameter or 'which app/country' guidance leaves a meaningful gap.

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

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

Schema coverage is only 33% (only 'pages' is documented), so the description must compensate but does not. It never explains appId format, the meaning of the 2-letter country code, or any defaults beyond what the schema already states, and it does not clarify that all three parameters are optional.

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 is a specific noun phrase naming the exact data source (Apple's public App Store review feed) and enumerates its contents (star counts, rating by version, share of 1-2 star reviews, low reviews). No explicit verb and no sibling is named, but the resource is distinctive enough that an agent can tell this apart from analytics/visibility 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 implies a use case ('for you to group into the to-do list (what to fix, what to answer)') and notes it is 'Free', which is mild routing context. However it gives no when-to-use vs. alternatives, no prerequisites, and no conditions for choosing pages/country.

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 no annotations, the description carries the full burden and does well: it discloses the output shape (a link per image to show the founder or download), that rendering matches App Store Connect's exact size, that the tool is free, and the behavioral quirk that caption text appears to count for App Store search since 2025 with the first three screenshots carrying the search result. It omits auth/rate-limit details but adds substantive context beyond the bare 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?

Front-loads the core purpose, then layers in output, caption guidance, sibling routing, and pricing in a compact block with no wasted filler. Sentences are slightly dense with multiple ideas but remain readable and well-ordered.

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 generator with no output schema and no annotations, the description covers what the tool does, what it returns (a link per image), and how it fits with the uploader siblings. The main gap is that size options and image-source requirements are left to the schema, but overall an agent has enough to call it correctly.

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

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

Schema coverage is 50%, and the description adds meaning for the caption field (a benefit in searchable words, counts for search) and the optional second line, but says nothing about the size enum values, the required img source, or the bg/fg colors documented only in the schema. It partially compensates but leaves half the schema carrying the load.

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: renders New App Store screenshots with a caption (plus optional second line) over each raw screen at App Store Connect size, returning a link per image. It also distinguishes itself from siblings by noting that app_cpp and app_experiment perform the uploading, so the agent knows this tool generates rather than uploads.

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 clear routing context: this produces screenshots, while app_cpp and app_experiment upload them, and it advises writing captions as searchable benefits. It stops short of stating an explicit when-not condition, but the division of labor with sibling tools is clear enough to guide 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?

With no annotations, the description carries the full behavioral burden and does substantial work: it discloses the read-vs-write switch keyed on `content`, that writing is free, that publication is out of scope for this tool, and a hard safety rule ('Never tell the founder it is live before they publish'). It does not state whether a write overwrites vs merges beyond the schema's note, nor any auth/rate-limit 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?

Front-loaded with what the tool is before any workflow advice, and nearly every sentence carries operating information (keyword selection, sourcing constraint, publish boundary, the not-live warning). It runs slightly long with clause-stacked sentences, but there is no filler.

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

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

For a nested, mutation-capable tool with no annotations and no output schema, the description covers purpose, mode switching, sourcing rules, and the publish boundary well. The remaining gap is the shape of what a read returns ('the current draft and its issues' is undefined), which matters given there is no output schema to fall back on.

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 a moderate 67%, and the description adds genuine meaning over the schema: it explains the read/write semantics of `content` (absent = return draft and issues), that `slug` is the subdomain set on first use, and that each page carries a `keyword` linking to an App Store page or `ppid`. appId is left entirely to the schema, which keeps it out of 5 territory.

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?

Names a specific verb pair (read or write) and the exact resource: the app's small marketing site on <name>.shipfound.site with a home page plus one page per search. The prose description of page anatomy (title, description, headline, intro, sections, FAQs, ppid links) is specific enough to separate it from siblings like app_metadata or site_fixes without opening the schema.

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

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

Gives an explicit workflow prerequisite ('Pick each page's search with keyword_research; write from the listing, the repo and the reviews') and an explicit branch condition ('Without `content` it returns the current draft and its issues'). It also routes the publishing step to another surface ('publishing is the founder's own action in the results app'). It doesn't state when to prefer this over site_fixes, 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?

With no annotations, the description carries full behavioral burden. It discloses a real behavioral trait beyond the schema: the credit cost model ('Costs 2 credits, charged only when it returns'). But it does not state whether the tool mutates anything, what permissions are needed, or what the pass/fail result looks like, leaving significant gaps for a no-annotation 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?

Front-loaded with the action, then the gate list, then the prerequisite and cost. The long gate enumeration earns its place since it tells the agent exactly what will be checked, though it is dense enough that a slightly tighter grouping would help.

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

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

There is no output schema and no annotations, so the description must cover return behavior; it says the check 'returns' and charges credits, but never describes the result shape (per-gate pass/fail, messages). Combined with thin parameter coverage, it is adequate on purpose but incomplete on inputs and outputs.

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% across 4 parameters, so the description must compensate. It clarifies the 'facts' parameter's provenance (the facts content_brief returned) and implies 'markdown' is the draft, but it never explains the 'type' enum values or the 'title' parameter, leaving half the inputs undocumented in both schema and prose.

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 ('Run the gates on a local draft') and enumerates exactly what is validated: fabrication, unsupported claims, disparagement, duplication, placeholders, banned words, dashes, answer-first opening, headings, length, links. An agent can tell this is a pre-publication linting/QA tool distinct from content generation or research 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?

Gives clear context ('before the PR') and a workflow prerequisite ('Pass the facts content_brief returned'), which ties it to a sibling tool. It does not, however, name any alternative check tool or state when not to use it, so it falls short of explicit 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?

With no annotations, the description must carry the behavioral burden. It discloses the credit cost (5 credits) and the charge condition (charged only when it returns), plus a constraint that every number must come from a fact. It does not describe auth requirements or return format beyond the listed contents.

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 followed by two short clauses. It front-loads the core output list and ends with cost and constraint. Slightly long but every clause contributes 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 annotations, no output schema, and full schema coverage, the description provides the essential behavioral context: what is returned, the cost model, and a data-integrity rule. It could be stronger with explicit when-to-use routing against siblings, but it is largely complete for an agent to invoke correctly.

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

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

Schema coverage is 100%, so the schema fully documents the three parameters, including the enum values and topic meaning. The description does not add any parameter-level guidance beyond what the schema already provides.

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

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

The description clearly states the tool's purpose: it produces the research for one page, enumerated as facts with source URLs, headings, PAA, gaps, an outline, and rules. The verb is implicit ('research...you write the page from this') but the resource and scope are specific enough to distinguish it from siblings like keyword_research or check_content.

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

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

It implies usage — 'You write the page in the repo from this' suggests a pre-writing step — but does not explicitly state when to use this versus alternatives like keyword_research, plan, or check_content, nor does it describe prerequisites or 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?

No annotations are provided, so the description carries the full behavioral burden, and it does well: it discloses that the kept variant becomes the page's only version, that experiment code is removed in the same PR, and that a record_action with module EXPERIMENTS is emitted. It stops short of stating irreversibility, required permissions, or auth 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?

Front-loaded with the core action followed by a tight sequence of consequences; no sentence is redundant. The trailing 'Free' is terse but informative about cost.

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 annotations and no output schema, the description adequately conveys the full workflow and its side effects. It falls short only on the semantics of the identifier/note/site parameters and any authorization context.

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

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

Schema coverage is 0% for four parameters, so the description should compensate. It meaningfully clarifies 'keep' (the winner, or the control when nothing won), but 'key', 'note', and 'site' are entirely undocumented anywhere, leaving most parameters opaque.

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 ('Stop a test') and goes further to enumerate the resulting side effects (ship the kept variant, remove experiment code, record the action). An agent can tell this apart from experiment_create and experiment_results without opening any 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?

Usage is implied by the name and the phrase about recording the winner vs. the control, which guides the 'keep' choice. However, there is no explicit when-to-use guidance, no exclusions (e.g., examine results first with experiment_results), and no stated prerequisites before closing.

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 no annotations, the description carries the full burden and does much of it: it reads 28 days of data, computes required sample size, refuses statistically unviable tests with numbers, and returns shippable code. It omits auth/permission requirements and rate limits, but the operational behavior is unusually well 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?

A dense but front-loaded paragraph where nearly every clause adds decision-relevant information (prerequisite, computation, refusal rules, return value, free-tier note). Slightly crowded, but no filler sentences.

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

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

There is no output schema, so the description must explain returns, and it does ('returns the code to put on the page... which you ship as a PR'). Prerequisites, failure modes, and the control convention are all covered, leaving nothing an agent needs 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 75% (baseline 3), and the description adds value the schema lacks: the mde default of 0.2 (20%) is not in the schema, and it clarifies the control is always the first variant. It does not document key, goal, path, or hypothesis beyond 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?

States a specific verb+resource ('Size and start an A/B test') with scope ('on one page against one goal'), clearly distinguishing it from experiment_close and experiment_results. An agent can identify the tool without opening the schema.

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

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

Gives a hard prerequisite ('The site must be in Attribution mode') and the failure conditions under which it refuses (over 12 weeks, under 50 testable visitors/week). It does not explicitly route to a sibling alternative the way an ideal definition would, but the usage context is concrete.

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 no annotations, the description carries the burden and does well: it defines the conversion counting rule (only at/after first exposure), states the default ordering (running first), the cost ('Free'), and a critical interpretation constraint. It omits read-only confirmation, auth requirements, and result volume/pagination limits.

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

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

Highly dense and front-loaded: the payload contents come first, then three terse constraint sentences. Every clause carries information (metrics, statistical method, verdict options) with 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?

With no output schema, the description usefully enumerates the return shape and verdict vocabulary, and covers the optional-key behavior. It is only incomplete because 'site' is undocumented and no volume/pagination expectation is set for the workspace-wide case.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the optional 'key' param well (omitting it returns every test in the workspace, running first) but says nothing about 'site', leaving one of two parameters entirely uninterpreted.

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 enumerates exactly what the tool returns (exposed/converted counts per variant, rates with 95% intervals, chance to beat control, lift, sample ratio check, verdict), which unambiguously identifies it as the read path for an A/B test. Combined with the title 'Read an A/B test' and siblings experiment_create/experiment_close, an agent can tell it apart without opening a 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?

It gives a scoping rule ('Without a key, every test in the workspace, running first') and an interpretive rule ('Never call a winner the verdict does not'), which implies usage but never states when to call this versus experiment_close or any alternative. No explicit when-not guidance, so usage is only implied.

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

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

With no annotations, the description carries the full burden and does substantial work: every created goal is SOFT, only the founder makes a goal HARD, changes to a HARD goal revert it to SOFT, headline conversions count HARD goals once any exist, and a payment goal is auto-proposed during list. It stops short of covering auth/permission requirements and failure behavior, so not a 5.

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 list/create purpose is front-loaded, but the body is one long run-on sentence with deeply nested parentheticals that is hard to parse. Each clause carries information, but the structure obscures it rather than organizing it.

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 and no annotations for a 7-parameter tool, and several parameters (name, valueCents, action, siteId) and the return shape are unexplained. The core goal-creation semantics are well covered, but an agent still lacks guidance on non-type parameters.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate. It explains the `type` enum values richly and clarifies `note` and partially `match`, but leaves `name`, `valueCents`, `action`, and `siteId` undocumented, so compensation is only partial.

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 clear verb+resource: list the site's goals and funnels, or create a goal, followed by a detailed enumeration of the six goal types. It does not reference any sibling tool by name, so it earns a 4 rather than a 5, 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?

Usage is implied through the action enum ('list', 'create') and the type semantics, and it says to use `note` to say why. There is no explicit when-to-use-this-vs-another-tool guidance and no stated prerequisites or exclusions for list vs create.

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 no annotations, the description carries the full behavioral burden and does well on the economic side: it discloses a cost of 4 credits, that billing occurs only on successful returns, and that empty results are free. That is genuinely decision-relevant context an agent cannot get from the schema. It still omits auth/permission requirements, expected latency, and failure behavior on errors, so it falls short of a 5.

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 compact sentences, front-loaded with the resource and its outputs, followed by the cost terms. The output enumeration is long but each item is substantive rather than filler, so it earns its length. No boilerplate or hedging.

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

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

There is no output schema, so the description must describe return values itself — and it does, listing all major data blocks including rank position and cited brands. Combined with the credit-cost disclosure, an agent has enough to invoke and interpret the call. Missing only operational details like latency, permissions, and error handling.

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 parameter whose description ('A keyword or a buyer question') already defines accepted input. The description's 'For one topic' reinforces singularity but adds no format, syntax, or cardinality detail beyond the schema. Baseline 3 is appropriate.

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

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

The description names a specific resource scope ('For one topic') and enumerates exactly what data comes back: search volume, CPC, difficulty, related searches, top 10 Google results, People Also Ask, and Perplexity citations. An agent knows precisely what this tool produces. It does not, however, distinguish itself from siblings like visibility or visibility_run, which also touch search performance data.

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

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

'For one topic' implies the usage pattern — call it per keyword/buyer question rather than in bulk — but the description never states when to reach for this tool versus visibility, visibility_run, or plan. The scoping hint is useful but usage guidance is only implied, not explicit.

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

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

With no annotations, the description carries the full burden, and it discloses genuinely useful behavior: a fixed cost of 4 credits charged only on a successful return, plus the implicit read-only filtering rule that already-listed directories are excluded. It omits auth requirements, rate limits, and result format, but the cost and billing disclosure is strong value that structured fields do not provide.

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

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

The core purpose and selection criteria are front-loaded in the first sentence, with the include constraint and cost follow-ups. Three sentences are dense and each carries information, though the opening sentence is long and slightly overloaded.

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

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

For a 2-parameter tool with no annotations and no output schema, the description is reasonably complete: it explains what is returned, the filtering logic, the optional include expansion, and the credit cost. The main gap is that, absent an output schema, it does not describe the shape of each returned entry beyond 'where to submit'.

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 both parameters (count, include) are already documented in the schema. The description reinforces the include enum by naming what launch and review entries mean, but adds no syntax or default 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?

The description states a specific resource (directories to list the product on) and enumerates the selection criteria: free, open to the product, not already listed, ranked by AI citations, with submission locations. An agent understands exactly what comes back. It does not, however, name or contrast any sibling tool (e.g. keyword_research or app_add), so it stops short of a 5.

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?

Guidance is limited to the include parameter ('Review profiles and launch platforms only when asked for in include'), which tells the agent when to expand scope, but there is no explicit when-to-use-this-tool-vs-alternatives statement. Usage context is implied by the filtering criteria 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?

With no annotations, the description carries the full burden and does disclose non-obvious traits: it is 'Free' (cost), and it is 'built only from what the latest access audit unlocked,' which tells the agent the result depends on prior access-audit state and may be empty or stale otherwise. It also specifies the ordering ('ranked') and time scope ('this week'). It omits auth requirements and pagination/refresh 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?

Three short sentences, front-loaded with what the queue is, then its fields, then cost and consumption rule. Every sentence carries information; the inline field list is the only slightly clunky element, but it is compact and useful.

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, so the description must explain the return value, and it does so by naming all six fields and the ranking ordering. Combined with the zero-param schema and the stated data dependency, an agent has enough to call and interpret it; only edge cases (empty queue, stale audit) are left implicit.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline for a 0-param tool is 4. The listed tuple describes the return shape rather than inputs, which adds clarity without conflicting with the empty schema.

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

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

The description states a specific resource and scope: 'the ranked queue for this week,' and enumerates the fields it contains ({rank, module, title, why, command, credits}), so an agent knows exactly what it gets back. It is clear but stops short of naming a sibling (e.g. visibility, goals, access) or explicitly saying how this differs from those plan-like 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?

'Work it top down; state the credits before running anything priced over 5' gives real guidance on how to consume the output and a cost gate before spending. However, it offers no guidance on when to call this tool versus alternatives, no prerequisites, and no exclusions, so tool-selection guidance is only implied.

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

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

No annotations, so the description carries the full burden. It usefully discloses that recording is free and that only the latest audit feeds the plan (implying prior audits are superseded), but it omits auth requirements, idempotency/overwrite semantics, and error behavior for a write 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?

Front-loaded with the core action, then unpacks the entry shape; no filler sentences and 'Free.' is a compact, useful aside. Dense but each clause maps to a real schema element.

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 three-parameter tool with nested objects and no output schema or annotations, the description is adequate on what to store but silent on permissions, return behavior, and the non-area parameters, leaving meaningful gaps for a mutation 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 0%, so the description does real work: it enumerates the eleven area ids, maps status to green/amber/red, explains detail and fix, and names plan-read facts including the required `framework`. It still leaves the top-level `repo` object, `client`, and other nested repo fields (canPush, branchProtected, etc.) unexplained.

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 ('Store') and resource ('access audit') and details exactly what each entry contains (area id, green/amber/red status, detail, single fix action, plan-read facts). It links to the `plan` sibling by noting the plan is built from the latest audit, but never explicitly contrasts itself with the adjacent `record_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?

'Free' and 'the plan is built only from the latest audit' imply the record should be written after an audit and before the plan is generated, giving implied usage. However, it never states when to call it vs alternatives like `record_action` or `verify`, nor any precondition (e.g., run access first).

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 no annotations, the description carries the full behavioral burden and does so well: it discloses the resulting state (stored as Claimed), cost model (free, verify costs 1 credit), the 30-day free re-check window, idempotency ('recording the same URL again updates it'), and the https-only constraint. It omits auth/permission requirements and failure behavior, but the disclosed traits are unusually rich for a create 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?

A single dense paragraph with the core purpose front-loaded and every clause carrying information (constraints, cost, lifecycle, idempotency). It is efficient but verges on a run-on, and the per-kind url/liveUrl mapping would be easier to parse as a list.

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 6-parameter, 4-required tool with a nested meta object and no output schema, the description covers purpose, cost, lifecycle and idempotency but leaves the module enum semantics and most of the meta object undocumented. An agent could still call it, but would likely guess at module values and meta contents.

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

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

Schema description coverage is 0%, so the description must compensate and it only partially does: it clarifies url vs liveUrl semantics for several kinds and documents meta.fixIds for site fixes. However, the module enum (FIXES, CONTENT, INDEX, LISTINGS, etc.) is never explained, the kind enum is only partially mapped to the examples, and meta's broader structure is left unaddressed.

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 (report/record) and resource (shipped work), then enumerates the concrete artifact types it accepts (PR, live page, listing, index request, post, Gmail draft), which lets an agent match its own artifact to the tool. It does not explicitly distinguish itself from the close sibling record_access, which handles a different recording flow.

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 clear context for when to call it ('report anything you shipped') and names the follow-up alternative (verify to check the claim, at 1 credit) versus the free automatic daily re-checks. It lacks any explicit when-not-to-use guidance relative to record_access or shipped, but the conditional mapping of url vs liveUrl per artifact type is 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?

With no annotations and no output schema, the description carries the full behavioral burden and delivers little. It mentions state values and 'what the last check saw', but says nothing about permissions, scope (whose actions), result ordering, pagination, or result volume for what is presumably an unbounded listing.

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

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

Two short, front-loaded sentences with no padding; the state list is placed early. The dangling 'Free.' is contextual noise that is not integrated into the sentence structure, keeping this just short of 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 read tool with no annotations, no output schema, and two undocumented enum parameters, the description is too thin. An agent cannot tell what set of actions is returned, whether filters are ANDed, how results are ordered, or what 'last check' maps to in the output.

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

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

Both parameters have 0% schema description coverage and the description only echoes the state enum values that already appear in the schema. It never explains the module enum or what filtering by module means, and with 0 required parameters it does not say whether omitting both returns everything.

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 (recorded actions) and its payload (state plus what the last check saw), which is more than a tautology. However, it never states a verb or retrieval scope, and it does nothing to separate itself from siblings like record_action, verify, or app_audit, which an agent could easily confuse with it.

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 guidance on when to call this versus record_action, verify, tracking_check, or app_audit. The trailing 'Free.' hints at a cost distinction but never says to prefer this tool on that basis, so the agent is left to infer the usage context entirely.

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 no annotations, the description carries the full burden and discloses the authentication flow, the approval-page interaction, the 40-second wait, and the signed-in status behavior. It does not cover failure modes such as denied approval, expired codes, or timeout behavior beyond the wait duration, so it is strong but not exhaustive.

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 main action and then walks through the stateful flow in clear steps. It is appropriately sized for an auth tool with no annotations, though the final 'Free.' sentence is unnecessary and could be dropped.

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 authentication complexity and lack of annotations or output schema, the description explains the key return values (link, code, working site) and the multi-step approval process. It is nearly complete, with minor gaps around error handling and repeated-call semantics when already signed in.

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%; the single client parameter is fully documented in the schema with an enum and default. The description adds no additional meaning about the parameter, so 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 a specific verb and resource: signs the session in to Shipfound from the chat. It is clearly distinguishable from all sibling tools, which are analytics, content, or app-management operations, and no schema inspection is needed to understand its role.

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 state-dependent instructions: when signed out, the first call returns a link and code and must be followed by a second call after the founder approves; later calls wait up to 40 seconds. When signed in, it reports the working site. There is no ambiguity about when or how to invoke it.

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

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

No annotations exist, so the description carries the full burden, and it delivers well: it discloses the 6-credit cost, that billing only occurs on return, that already-shipped fixes are excluded, the return structure ({ id, theme, page, issue, evidence, fix }), the one-PR-per-theme grouping, and the meta.fixIds dedup workflow. Missing auth/permission or latency details keep it from a 5.

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 purpose, then cost and workflow notes. The long parenthetical audit list is dense but earns its place by conveying scope. It is a single dense sentence plus two short follow-ups, with little waste.

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

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

There is no output schema, so the description correctly takes on the return-value burden by naming the fix-spec fields and grouping. Combined with cost, dedup, and downstream recording instructions, an agent has everything needed to call it and handle the result.

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

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

Schema coverage is 100% for the single 'url' parameter, so the schema already documents it (including the homepage default). The description adds no additional syntax or format meaning for the parameter, which is the expected baseline when the schema does the work.

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 ('Audit the live site') and enumerates the exact audit surface (robots rules for AI crawlers, firewall, rendering, indexing, canonicals, etc.). The 'live site' framing distinguishes it from siblings like app_audit, verify, and check_content, which target different artifacts.

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?

Usage is only implied – an agent infers it should call this to obtain site fix specs. There is no explicit when-to-use vs. when-not versus app_audit, verify, or check_content. It does give downstream workflow guidance ('when you record the PR, put fix ids in meta.fixIds'), which is useful but not tool-selection 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 no annotations, the description carries the full burden. It discloses the three signals evaluated (events, crawler hits, goals), the green success condition, and that output is 'in plain words', which is useful. It omits auth requirements, error/failure behavior, and rate limits, so it is only partially complete.

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, front-loaded sentences with no filler. The only minor inefficiency is the clipped 'Free.' fragment, which reads awkwardly but is still concise.

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

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

For a simple single-parameter read check with no output schema, the description conveys what is being checked and the success state. However, the lone parameter is unexplained and the return shape is only glancingly described ('in plain words'), leaving gaps an agent must guess at.

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?

One parameter (siteId) exists with 0% schema description coverage, so the description is expected to compensate but never mentions siteId or what value it should take. It adds no meaning beyond the bare schema property name.

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 purpose: checking whether the live site is sending events, crawler hits and goals, and reporting what is missing. It is clear what the tool does, though it does not differentiate itself from the related sibling tracking_install, so an agent has to infer the boundary between checking and installing.

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 guidance and no named alternative. The 'Tracking turns green' line describes the success state rather than when an agent should call this tool, and 'Free' hints at cost but does not route the agent between this and tracking_install.

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 no annotations, the description carries the load and does disclose meaningful side effects: the secret is displayed only once (or via rotateSecret), rotating invalidates the old secret, the secret must never be committed, and static sites get only a log-shipper note. It omits auth/permission requirements and re-run behavior for an already-tracked domain.

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 action and the artifacts it creates; the closing sentence adds plan limits and the 'first PR / never commit the secret' directive without wasted words. The first sentence is dense with a long list, but each item is substantive output information rather than 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?

No output schema and no annotations exist, and the description compensates by describing the returned/created artifacts (key, secret, script tag, middleware) as well as plan constraints and secret-handling rules. It is close to complete for a 5-parameter setup tool, with auth requirements and idempotency the main gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's framework list (nextjs, astro, nuxt, sveltekit, cloudflare) and the static-site note largely repeat what the schema already documents and omits html, hugo, remix, gatsby, webflow, framer, wordpress, and other.

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 ('Set up tracking for the site') and then enumerates exactly what installation produces: site key, secret, tracking.js script tag, AI crawler middleware, default goals and funnel. That enumeration makes it unmistakable that this is the installer rather than the verification sibling tracking_check.

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

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

Gives clear context for when to run it ('Ship it as the first PR') and the plan eligibility that gates it (Free/Builder 1 site, Growth 3, free on every plan). It does not name an alternative or state when not to use it, so it stops short of full routing 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?

No annotations are provided, so the description carries full behavioral burden. It usefully discloses the cost model ('Costs 1 credit, charged only when it returns') and specific detection behavior (e.g., Reddit removals), but it omits permissions, failure modes, and what the verification result contains.

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 paragraph that front-loads the purpose, then adds cost and exclusion details. Every sentence carries useful information, though the parenthetical examples could be slightly more scannable.

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

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

For a tool with one undocumented parameter, no output schema, and no annotations, the description should explain at least the shape of a verification result or how to source the actionId. It covers scope and cost well but leaves output and parameter semantics entirely unaddressed.

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 'actionId' has 0% schema description coverage, and the description never explains it beyond implying 'one recorded action.' It does not state the expected format, source, or how to obtain a valid actionId.

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 ('Check') and resource ('one recorded action from the outside'), then gives concrete examples of what can be verified (PR state, live page, listing rel, Reddit post). It is clear enough to distinguish from generic tools, but it does not explicitly differentiate itself from siblings like check_content or tracking_check.

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

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

The description implies when to use it by listing verifiable action types, and it explicitly excludes index requests and drafts ('cannot be verified by us and cost nothing'). However, it names no alternative tools or conditions that would route an agent to a sibling tool instead.

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 no annotations, the description carries the full behavioral burden and does meaningful work: it discloses that only completed (not in-flight) checks are returned, that the call is free, and it defines the non-obvious "named" threshold (2 of 4 runs, at least one engine, at least one tracked question). It does not cover auth requirements, freshness/staleness of the latest check, or pagination 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?

It front-loads what the tool returns and then supplies only the two definitions an agent actually needs (the stability label example and the "named" rule). Slightly dense with the inline quoted example and the final definition sentence, but 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?

With no output schema and no annotations, the description must carry the return-value burden, and it only sketches the shape (question/engine pairs, stability labels, named brands) without describing field structure or empty-state behavior when no check has finished. The cost signal and "named" definition help, but the picture remains partial.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The stability-label and "named" definitions add semantic meaning to the output fields even though no input exists.

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

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

The description names a specific resource and scope: the latest *finished* full check, listing question/engine pairs with stability labels plus the brands named in your place. That is enough for an agent to know this is a retrieval of existing results rather than a new scan, though it never explicitly contrasts itself with the sibling visibility_run.

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 word "Free" plus "latest finished" implies you call this to read results from an already-completed check instead of paying to run a new one, which is useful routing context. However, there is no explicit when-to-use/when-not statement and no direct pointer to visibility_run or what to do when no check has finished yet.

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 no annotations, the description carries the full burden and delivers: it discloses that the work happens in the background (~10 minutes), that a separate call to `visibility` is needed for results, and the credit/plan/rate-limit implications of re-running. This is unusually rich behavioral context for a zero-parameter 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 critical facts (async, ~10 minutes, call `visibility` next) are front-loaded, and the billing rules follow. It is dense with plan/credit detail, but each clause governs a decision the agent may need to relay, 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?

For a no-param, no-output-schema tool, the description covers what it does, how long it takes, what to call next, and when it is permissible or costly to run. Nothing an agent needs to invoke it correctly 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 takes no parameters, so the baseline is 4; there is nothing parameter-related the description needs to add. It appropriately spends its text on cost and sequencing instead.

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

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

The description states a concrete action and scope: it asks 10 buyer questions across every engine, 4 runs each, asynchronously. It also distinguishes itself from the sibling `visibility` by saying to call that tool afterwards to get results, so an agent can tell run from retrieve without opening a 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?

It lays out explicit conditions: first check is a free baseline on every plan; subsequent re-checks require Builder or Growth, cost 15 credits, are capped at one per day, and Builder/Growth get weekly automatic re-checks. It even instructs the agent to state the price before a re-check.

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 no annotations, the description carries the full behavioral burden. It usefully discloses cost ('Free') and the return contents, but says nothing about authentication/scope requirements, error behavior, or whether the result is cached – gaps that matter less for a read-only singleton but are still undocumented.

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 tight fragments, no filler, and the most actionable line ('Call this first') is short and memorable. Minor issue: placing the priority instruction before the field enumeration would front-load the call-to-action better.

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 compensates by listing the returned fields, and with no parameters and no annotations there is little else an agent needs. It is complete enough to call correctly, though it omits any caveat about what happens if the key is invalid or the workspace is uninitialized.

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 takes no parameters, so there is nothing to document and the baseline is 4. The description does not need to explain argument semantics, and it correctly says nothing about inputs.

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

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

The description enumerates the exact payload an agent will get back (name, URL, plan, credits left, access summary, tracking state, result-app and proof-page links), so the resource is unambiguous even without a leading verb. It does not distinguish itself from related siblings such as 'access' or 'plan', which keeps it short of a 5.

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?

'Free' tells the agent this call does not consume credits, and 'Call this first' gives an explicit sequencing instruction for onboarding. There is no when-not-to-use guidance or named alternative, but for a zero-arg singleton the context is clear.

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