Engagemii Citation Watch

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

With no annotations, the description carries full burden. It discloses that it does a fresh live fetch, the rate limit, and the absence of auth, which covers key behavioral aspects. It does not explicitly state it is read-only, but the nature of an audit implies no side effects. Slightly more detail about what happens on invalid domains or the exact output format would push it to a 5, but it is quite transparent overall.

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

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

The description is two sentences, front-loaded with the core purpose, and immediately followed by usage guidance and limitations. Every word earns its place, with no fluff or redundancy.

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

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

Given a single simple parameter, no output schema, and no annotations, the description covers all necessary context: what it does, when to use it, how it differs from a sibling, and operational limits. An agent can confidently invoke it without missing critical information.

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 domain parameter is already described as 'Company domain or URL, e.g. example.com'. The tool description adds no extra semantic beyond what the schema provides, so it meets the baseline for high coverage without adding additional nuance.

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 runs a LIVE AEO audit, listing exactly which resources it fetches (homepage, robots.txt, sitemap, llms.txt, about page) and what it produces (scores on six on-page categories with recommendations). It also distinguishes itself from the sibling aeo_score, making its purpose unambiguous.

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

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

The description explicitly says to use this tool to verify fixes immediately after applying them, and contrasts it with aeo_score which returns the stored dataset score on the next crawl. It also states constraints (free, no auth, 5 per hour) and the single parameter domain, leaving no ambiguity about when or how to use it.

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

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

With no annotations, the description carries the behavioral burden. It discloses the score range, the data source (40 million+ dataset), and auth requirements (no auth). It doesn't cover not-found cases or rate limits, but for a simple read-only lookup it provides strong transparency.

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

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

Two tightly packed sentences: the first front-loads the tool's purpose and output contents, the second adds data source and access cost. No filler or redundancy.

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

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

For a one-parameter tool with no output schema, the description explains what the tool returns and its data provenance. It lacks error/edge-case behavior, but an agent can invoke it correctly with the provided information.

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% and the single parameter 'domain' is already documented as 'Company domain or URL.' The description adds little beyond the schema, so the baseline 3 applies.

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

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

The description names a specific verb-resource pair ('Get the Engagemii AEO score') and enumerates the exact output components (six sub-scores, seven off-page signals, llms.txt verdict). This clearly separates it from a generic audit or other tools, even without naming a sibling.

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 usage is implied: pass a company domain to retrieve the score. It notes 'for any company domain' and 'Free, no auth,' but does not explicitly state when to prefer this over aeo_audit or any other sibling, nor any 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?

With no annotations provided, the description carries the full burden and does useful work: it states the data is 'server-side, IP-verified', that the tool is 'Free, no auth', and describes the returned time windows and series. It does not detail response formatting or rate limits, but for a simple read endpoint this is solid disclosure.

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

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

The description is compact and front-loaded: it opens with a compelling question, then explains data source, outputs, and example uses in three sentences. The only minor waste is the promotional phrase 'one of the largest networks of business pages online', but overall it earns its place.

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

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

For a one-optional-parameter, no-auth read tool with no output schema, the description is largely complete: it covers purpose, data provenance, auth requirements, time granularity, and sample queries. It does not describe the exact return schema, but that is somewhat mitigated by the clear description of what is returned.

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

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

Schema description coverage is 100%, so the schema already fully documents the single optional 'days' parameter. The description adds a little context by mentioning 'daily series' and the allowed range indirectly, but it does not significantly enhance the parameter meaning beyond the schema.

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

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

The description clearly identifies the tool's function: tracking which AI engines read business web pages, via server-side IP-verified crawler logs. It states specific output measures (per-engine reads over 10 minutes, 24 hours, all time, plus a daily series), which distinguishes it from the unrelated SEO/audit siblings.

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

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

The description provides explicit use-case examples: 'which AI crawler is most active', 'how much is Claude reading compared to GPTBot', and 'is AI crawling going up'. It does not explicitly state when not to use the tool or name alternatives, but the provided queries give clear contextual 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 burden, and it does well by disclosing that the operation is free, requires no auth, and returns a defined list of fields. It does not mention rate limits or behavior for unscored domains, but the read-only public-profile framing and auth disclosure are solid.

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

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

One compact sentence that front-loads the core purpose and output contents, then adds the auth/cost fact. No filler or redundant wording.

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

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

For a simple one-parameter lookup with no output schema, the description is largely complete: it specifies the input domain implicitly, lists the output components, and states access requirements. It only lacks explicit error/empty-response behavior and domain format normalization.

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

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

There is a single required parameter, domain, and schema description coverage is 0%; the description never mentions the domain parameter or clarifies expected format (e.g., bare domain vs URL, www normalization). The meaning is inferable from the word 'domain,' but the description adds no parameter-level guidance.

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 (public profile of a scored company) and enumerates the contents: score breakdown, category, geography, detected platform, social profiles, AI-crawler visit counts. It clearly distinguishes the tool from a simple score-only sibling like aeo_score, though it never names any sibling explicitly.

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

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

The phrase 'Full public profile for a scored company' plus 'Free, no auth' implies when it should be used: when a complete public profile is needed and no authentication is available. However, it does not explicitly state when to prefer a sibling tool or call out 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?

With no annotations provided, the description carries the transparency burden and does well: it discloses the 30-minute refresh cycle, 48-hour lookback window, precomputed scores, and that it is free with no auth. It omits minor operational details like limits or pagination, so a 4 is appropriate.

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

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

The description is front-loaded with purpose and packs useful facts (frequency, window, auth, example use cases) into four sentences. The opening phrase is somewhat colloquial, but no sentence is superfluous.

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-parameter, read-only data query with no output schema, the description gives an agent enough context to invoke it: what data is returned, how fresh it is, and when to use it. Exact output shape is not specified, but the described fields (brand names and scores) are sufficient for a simple endpoint.

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 both parameters (limit and category) already have semantic descriptions in the input schema. The tool description adds no parameter-level detail beyond mentioning 'category X', so it stays at the baseline 3.

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

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

The description states a clear output: a record of brands ChatGPT names in response to buyer questions, paired with each brand's AI visibility score, over the last 48 hours. This identifies the specific resource and differentiates it from sibling tools such as aeo_score or brand_profile by describing the data source and update mechanism.

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

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

Provides explicit example questions ('which brands does AI recommend in category X', 'is an AI visibility score related to being recommended') that tell an agent when to choose this tool. It does not mention alternatives or exclusions, 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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It does an excellent job: it reveals account provisioning, snippet generation, reporting behavior, dashboard access, data licensing, domain identification, opt-out availability, and the fact that only bot visits are tracked. This is unusually transparent for a tool description.

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 core purpose and flows naturally into workflow, install instructions, and consent requirements. It is fairly long, but nearly every sentence earns its place because it conveys either a side effect, a prerequisite, or a privacy condition the agent must communicate.

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

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

With no output schema, the description correctly explains what the tool returns: an install snippet with the tracker key embedded, plus a dashboard link and reporting behavior. It also covers prerequisites, success criteria, and the required owner consent. Nothing essential is missing for an agent to invoke and act on this tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value by mapping the platform parameter to concrete stacks (Node/Express, Next.js, PHP, Cloudflare Worker) and reinforcing that the owner's email is required. It does not add domain-specific detail, but the schema already describes that field adequately.

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

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

The description opens with a specific purpose: 'Set up free Engagemii AI-crawler monitoring for a site' and immediately explains what the tool provisions (account, tracker key, install snippet). It is clear and concrete, but it never explicitly distinguishes itself from sibling tools like data_signup or free_kit, so it misses the top score for sibling differentiation.

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

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

The description gives clear context: use this when setting up AI-crawler monitoring, requires the owner's email, and should only run if the owner accepts the data-licensing terms. It also provides installation guidance by stack. It does not explicitly discuss when to prefer an alternative tool, but the context and one when-not condition ('Only connect if the owner is fine with that') are strong.

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

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

With no annotations, the description carries the full burden and does so well. It discloses quota deduction per record, default and maximum limits, fingerprinting, the need for an API key, and the existence of a bulk alternative. This is strong behavioral disclosure beyond the minimal 'pull records' phrasing.

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

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

The description is dense but every sentence earns its place: purpose, metering warning, default/max limits, bulk API alternative, auth requirement, and free alternatives. It is front-loaded with the core purpose and immediately surfaces the critical cost constraint.

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 and no output schema, the description covers the important operational context: quota impact, auth, limits, output shape, bulk endpoint, and free alternatives. The only residual gap is detailed filter semantics, but those parameters are optional and reasonably self-explanatory, so the tool is still safely invocable.

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 17%, so the description needed to compensate for the five undocumented parameters: scope, states, scoreMax, scoreMin, and industries. It clarifies limit's cost semantics and mentions 'filters' generally, but does not explain filter behavior, accepted values, or interactions, leaving most parameters semantically underspecified.

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: 'Pull full licensed records from the Engagemii dataset.' It also distinguishes this tool from the free-browsing siblings by noting it returns the same shape as a purchased file, so an agent can tell it apart from dataset_sample and search_companies.

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

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

The description gives explicit usage context: it is metered, limits should stay small, bulk pulls should go through the raw API, and free browsing should use search_companies or dataset_sample instead. It also names the required API key, leaving little ambiguity about when this tool should be selected.

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 provided, the description carries the full burden of behavioral disclosure. It openly states that rows are random, live, free, and require no authentication, and it clarifies that the output matches the cleaning and columns of the purchased file. It does not mention rate limits, but for a read-only sample retrieval this is a reasonable and transparent description.

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

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

The description is a single, well-structured sentence that front-loads the core outcome (15 random live rows) and then adds relevant fidelity and access details. There is no filler or redundant phrasing; every clause earns its place.

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

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

Given the tool has no parameters, no output schema, and no annotations, the description sufficiently tells an agent what to expect: 15 rows with the same columns and cleaning as a purchased file. It does not enumerate exact column names or output format, but for a zero-argument sample tool this is adequate context for correct invocation.

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

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

The input schema has zero properties and is fully described (100% coverage), so the description does not need to explain parameters. Per the rubric, 0 params warrants a baseline of 4, and the description correctly implies no invocation arguments are needed.

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

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

The description clearly states the tool returns 15 random live rows from the Engagemii dataset, which is a specific verb-resource pair. It also differentiates itself from siblings by emphasizing it is a sample with the exact shape of a purchased file, so an agent can distinguish dataset_sample from data_records or search_companies.

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

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

The description gives clear context for use: it is a free, no-auth way to get a representative sample of the dataset. It does not explicitly name alternatives or state when not to use it, but 'exactly the shape a purchased file delivers' implicitly positions it as a preview tool, which is sufficient guidance for this simple case.

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 excels: it discloses email verification, the inactive API key until link click, the key appearing in the portal, and the unlock of search_companies and data_records. It also flags the license acceptance requirement, so the agent understands the side effects and gating 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 sentences, each earning its place: purpose, activation behavior, and required inputs with the critical compliance caveat. Information is front-loaded and there is no filler.

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

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

For a no-annotations, no-output-schema tool, the description covers what the tool creates, the verification/activation flow, the required inputs, and the compliance constraint. It does not specify response/return details, but that is not needed to invoke correctly. One small gap is that it does not state what the agent should do if the user has not accepted the license.

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 describes only password and license_accepted (50% coverage). The description compensates by explaining all four parameters in context: user's email, user-chosen password of 8+ characters, company name, and explicit license confirmation. It adds the requirement that license_accepted only be true upon explicit user agreement, beyond the schema's wording.

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

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

States a specific action and resource: 'Create a free Engagemii data account.' It also explains the account activation flow, which distinguishes data_signup from data-access siblings like search_companies and data_records.

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

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

The description clearly establishes the context: use it to create a new data account and obtain an API key. It does not name alternatives, but no sibling tool overlaps with signup, and the trigger conditions (user email, chosen password, company name, explicit license acceptance) are explicit. A small deduction for not explicitly saying 'use when the user wants to sign up.'

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 present, the description bears the full burden and excels. It discloses the asynchronous email flow, that kits are queued, that delivery is via email rather than in-chat, and that repeat requests resend the stored kit. It also explains what the kit contains, so the agent knows the outcome a user can expect.

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

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

The description is fairly long (about 120 words) but every sentence serves a purpose: first the core purpose, then contents, then flow, then constraints. The most important information ('Request the FREE Customized Fix Kit') is front-loaded, and the rest builds upon it without redundancy. Slightly dense but well-organized.

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

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

For a tool with no output schema and no annotations, this description is remarkably complete. The agent learns what triggers the tool, what the kit includes, how delivery works (email, not chat), the one-per-domain limit, and what happens on repeat calls. Nothing essential for correct invocation is missing.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds some contextual color—'pass the owner's email' and 'repeat requests resend the stored kit'—but does not materially go beyond the schema descriptions for domain, email, or owner_confirmed. It earns the baseline without exceeding it.

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

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

The description opens with a precise verb and resource: 'Request the FREE Customized Fix Kit for a domain.' It enumerates the exact contents (eight fix files and a PDF audit) and the one-per-domain scope, making it immediately distinguishable from siblings like kit_checkout and kit_download. No ambiguity exists about what this tool does.

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

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

The description gives a clear flow (owner email → verification → email delivery) and states key conditions like one kit per domain and queued email delivery. It does not explicitly name alternative tools or say when not to use it, though the schema hint about agencies using the data portal is a close complement. Overall the context is strong but lacks an explicit when-not-to-use statement.

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 so excellently. It discloses that the tool is retired, that there is nothing to buy, that it remains as a fallback, and what the replacement flow is. This is exactly the behavioral insight an agent needs.

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

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

Three tightly-written sentences, with the critical RETIRED status front-loaded. Every sentence adds value: what changed, what to call instead, and why the tool still exists. 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 retired redirect tool with one optional parameter and no output schema, the description is complete. It fully explains the state change, the replacement action, and the expected outcome, so an agent can handle this tool correctly without further information.

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

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

The schema already provides 100% coverage for the single parameter, describing it as 'The site, e.g. example.com.' The description does not add meaning about the domain parameter itself; its mention of an email applies to the replacement tool, not to this one's parameters. A 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 immediately marks the tool as RETIRED and explains its purpose: it exists only so older conversations get a helpful redirect. It explicitly names free_kit as the intended alternative, clearly distinguishing this tool from its sibling.

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 explicit when-to-use context ('older conversations'), and tells the agent exactly what to do instead: call free_kit with the owner's email. It also explains what will happen after that call, leaving no ambiguity about routing.

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 gating prerequisite, the exact output (eight files plus badge embed as plain text), and the intended follow-up action (apply to codebase and re-run aeo_audit). It doesn't cover error behavior or idempotency, but those are secondary for a single-param download.

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

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

Two sentences, no filler. The first sentence fronts the purpose and outcome, and the second delivers the required input. Every clause earns its place.

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

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

For a tool with one required parameter, no output schema, and no annotations, the description is complete: it explains the precondition, the parameter, the delivered content, and the post-call verification step. Nothing essential is missing for correct invocation.

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

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

Schema description coverage is 0%, and the description compensates fully: it explains that session_id is the Stripe session id, gives the expected format (cs_...), and names its source (checkout success URL). This is exactly the meaning an agent needs beyond the bare 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 verb ('receive') and a concrete resource ('all eight Customized Fix Kit files plus the badge embed'), and frames it as the post-paid-checkout counterpart to kit_checkout. It is clearly distinguishable from sibling tools like free_kit, kit_checkout, and aeo_audit.

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

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

It explicitly conditions usage on 'After a paid kit_checkout' and tells the agent to pass the Stripe session id from the checkout success URL. It doesn't explicitly name alternatives or exclusions, but the context makes the correct occasion 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 transparency burden. It does disclose an authentication requirement, a response cap, and a lightweight row format, which is meaningful. It does not reveal filter combination semantics (AND/OR), default scope, sort order, or whether score bounds are inclusive, leaving notable behavioral gaps.

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

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

Two sentences, front-loaded with the core action and filters, then the limit and auth requirement. There is no filler or repetition of the tool name, and every sentence contributes actionable 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?

The description covers the main call surface: filters, scope, result cap, and API key requirement. However, for a tool with no output schema, 'light rows' is vague, and useful details like state code format, default scope, or filter combination behavior are absent. It is adequate for a basic query but not fully self-sufficient.

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 50%, so the description must partially compensate. It maps 'score range' to scoreMin/scoreMax and 'scope us|all' to the scope enum, and it implies the limit through 'up to 100.' But it adds little beyond restating the schema's existing meaning for industries and does not explain states format, leaving those to the agent to infer.

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

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

The description uses a specific verb ('Query') and resource ('scored dataset'), and enumerates the filter dimensions (industries, states, score range, scope). It also states the result shape ('up to 100 light rows'). It does not explicitly differentiate from sibling tools like data_records or dataset_sample, so it stops just 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?

The description implies usage: query this dataset when you need filtered company data, with a scope switch between US and worldwide and a 100-row cap. It also gives a prerequisite ('Requires an Engagemii data API key') and clarifies that results are 'light rows.' However, it does not say when to prefer another sibling tool or provide explicit exclusions.

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