Engagemii Citation Watch

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), and the description adds concrete operational context beyond them: the exact resources fetched, the six-category scoring model, and a rate limit (5 live audits/hour) plus 'free, no auth'. These are non-obvious constraints 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 dense sentences with no filler; the core action and fetch list are front-loaded, followed by the sibling differentiation and the operating constraints. Every clause carries information.

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

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

With no output schema, the description still indicates the return content ('scored on the six on-page categories with concrete recommendations'). Combined with the live-vs-stored distinction and rate limits, nothing an agent needs to call 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?

Only one parameter and schema description coverage is 100%, so the schema already documents 'domain' with an example. The description adds no additional syntax or format guidance, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb (run) and resource (live AEO audit) and enumerates exactly what is fetched and how it is scored. It explicitly distinguishes itself from the sibling aeo_score by contrasting live fetch vs stored index value.

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?

Names the alternative tool (aeo_score) and the condition that selects it ('returns the stored score from the index; that score updates when Engagemii next reads the site'), so an agent can route between live and cached audits without inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond the annotations: it is free, requires no authentication, and the data comes from a 70M-company index. It does not mention latency or rate limits, keeping it 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?

One dense sentence that front-loads the core result (score 0-10) and then the supplementary return components, closing with the access constraint. 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 what comes back (overall score, sub-scores, authority signals, llms.txt verdict) and confirms no auth is needed for a single-parameter read tool. It is nearly complete; only guidance on failure cases (e.g. unknown domain) is absent.

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 well-documented required parameter, so the schema carries the semantics. The description's 'any company domain' adds only marginal framing beyond the schema's 'Company domain or URL, e.g. example.com'.

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 (get) and resource (Engagemii AEO score) with scope (any company domain) and enumerates the exact return contents: overall 0-10 score, six on-page sub-scores, seven off-page signals, llms.txt verdict. This is distinguishable from siblings like aeo_audit and search_companies 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?

The phrase 'for any company domain' and 'Free, no auth' give useful context for when the tool applies, but it never names an alternative (e.g. aeo_audit or search_companies) or states when not to use it. Usage is implied rather than routed.

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

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

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds valuable context beyond annotations: server-side IP-verified logs, free access with no auth, and the time windows returned (10 minutes, 24 hours, all time, plus a daily series). It does not cover pagination or exact output format, but the added provenance and auth details are substantive.

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, followed by data source, return windows, access model, and example use cases. It is efficient and every sentence adds information, though it is slightly verbose and could tighten the final sentence.

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

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

For a simple read-only tool with one fully documented optional parameter and no output schema, the description supplies enough context: data source, return windows, auth model, and example questions. It does not detail output structure, but with no output schema that is a minor 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 description coverage is 100% and the single 'days' parameter is fully documented in the schema. The description mentions a daily series but adds no syntax, range, or default details beyond the schema, so baseline 3 is appropriate.

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

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

The description clearly states the resource: AI engine reads from crawler logs across business pages. It does not name a specific verb (e.g., 'get', 'list'), but the scope and data source are specific enough to distinguish it from siblings like aeo_audit or citation_watch. Sibling differentiation is implicit rather than explicit.

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

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

It provides concrete example questions the tool answers, such as which AI crawler is most active and how engines compare. This gives clear usage context, but it does not name alternatives or say when not to use the tool, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool is free and requires no auth, and that it returns AI-crawler visit counts, which is useful behavioral context beyond the annotation set. It does not, however, describe caching, rate limits, or error behavior for unknown domains.

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 sentence front-loads the resource and enumerates the return contents, and a second short sentence covers access terms. No filler, no restatement of the name or title.

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, no-output-schema read tool with rich annotations, the description covers what an agent needs: what is returned, that it is free, and that no auth is required. A minor gap is the domain format and what happens when no profile exists for a domain.

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

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

With 0% schema description coverage and a single required parameter, the description implies that the profile is keyed by company domain. It does not state domain format (bare vs. URL) explicitly, but the parameter is self-evident from context and the rest of the description. Baseline for a single param with no schema docs is well served here.

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 (get) and resource (full public profile for a scored company) and enumerates exactly what the profile contains. An agent can distinguish this from siblings like aeo_score or aeo_audit, which are action-oriented, 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?

The description implies usage by listing what's returned and noting it's free with no auth, but it never states when to prefer this over siblings such as search_companies or aeo_score. The condition that selects this tool is left to inference.

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

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

Annotations already declare read-only, idempotent, open-world behavior, but the description adds substantial context: 30-minute refresh cadence, real non-branded buyer questions with live web search, the pre-question timing of visibility scores, a 48-hour window, and no auth or cost. This is unusually rich behavioral 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?

Front-loads the core value ('What ChatGPT is recommending right now') and then layers in mechanism, constraints, and examples efficiently. The four sentences are compact, though the final example sentence is somewhat redundant with the opening.

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

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

With no output schema, the description carries the burden of explaining what is returned: brand names alongside AI visibility scores, limited to the last 48 hours. Annotations cover safety, and parameters are fully documented by the schema, so it is nearly complete, though it does not describe result ordering or structure.

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 limit and category. The description mentions category in a use case but adds no syntax, defaults, or filtering details beyond what the schema provides.

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

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

States a specific resource and action: seeing which brands ChatGPT recommends, with data refreshed every 30 minutes. It clearly describes the output and use cases, but does not distinguish itself from siblings such as aeo_score or ai_readstream.

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 implied usage through example questions ('which brands AI recommends in a category' and 'whether an AI visibility score relates to being recommended'), but offers no explicit when-to-use, when-not-to-use, or sibling alternatives.

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

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

Goes well beyond annotations (readOnlyHint=false, idempotentHint=false) by disclosing that it provisions an account, that the returned snippet embeds the key, that data collection is licensable/aggregated and domain-identifiable unless opted out, and that only bot visits are recorded. This is unusually rich behavioral and data-handling context for a mutation 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-loads the core action and outcome, then layers requirements and terms; every sentence carries information. The licensing sentence is dense and slightly long, keeping it from a 5.

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

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

With no output schema, the description compensates by explaining exactly what is returned (an install snippet with the key embedded, in one of four stacks) and what happens after installation. Nothing an agent needs to call this 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?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the email belongs to the owner, and omitting platform yields all four snippets rather than an error. That clarifies enum omission behavior beyond the schema text.

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+resource ('Set up free Engagemii AI-crawler monitoring for a site') and spells out the concrete outcome: provisioning an account and key plus returning an install snippet. It is clearly distinguishable from siblings like aeo_audit or aeo_score, which measure rather than provision.

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

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

States the precondition (owner's email required) and the install-then-report workflow, giving clear context for when this tool applies. It does not name any sibling alternative or say when not to use it, so it falls short of a 5.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false; the description adds real value beyond them by disclosing the metered quota consumption (one unit per record) and the API-key requirement. It does not contradict the annotations — quota consumption plausibly explains the non-read-only hint.

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

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

Four dense sentences with the core capability and cost model front-loaded, then limits, then the REST fallback and auth requirement. Each sentence carries weight; no padding.

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

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

For a 7-parameter, no-output-schema tool it covers quota, limits, auth and a scale-out path well, but neglects the semantics of five filter parameters, which is the main thing an agent needs to shape a useful call.

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 29% (just limit and api_key are documented), leaving scope, states, scoreMax, scoreMin and industries unexplained in structured data. The description restates the limit/quota relationship but adds nothing for the five undocumented filters, so it fails to compensate for the coverage 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 and resource ('Pull full licensed records from the Engagemii dataset'), specifies the column shape ('all columns, fingerprinted, the same shape a purchased file delivers'), and is distinguishable from siblings like dataset_sample and search_companies. An agent knows exactly what this returns without consulting another tool.

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?

Explains the quota cost per record, the default (25) and in-chat ceiling (100), and routes larger pulls to the REST endpoint. It does not explicitly contrast with sibling tools such as search_companies or dataset_sample, so there is no when-not guidance, but the operational context is clear.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context: no authentication required, data is live rather than a static fixture, and the output matches purchased-file columns and cleaning. It does not mention whether repeated calls return the same 15 rows (relevant given 'random' vs idempotentHint), a minor gap.

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 sentence with zero filler: count, sampling method, dataset, output shape, and access cost all front-loaded. Nothing to trim.

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 characterizes the return shape (same columns and cleaning as a purchased file) and the no-auth condition, which is what an agent needs to call it cold. Only the variability of 'random' across calls is left unstated.

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?

Zero parameters, so per the rubric the baseline is 4. The description correctly spends no words on parameters and instead characterizes the returned row set.

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 (sample of the Engagemii dataset) with hard scope qualifiers: 15 rows, random, live. An agent can distinguish it from siblings like data_records or kit_download 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?

'Free, no auth' implies a low-commitment preview use case before purchasing, but the description never explicitly says when to choose this over siblings such as data_records (full data) or free_kit. Usage is implied rather than routed.

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

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

Annotations only declare readOnly=false, openWorld=true, idempotent=false, destructive=false; the description adds substantial behavior beyond that: a verification email is sent, the API key (edk_...) stays inactive until the link is clicked, and the key then surfaces in the portal. This async, state-dependent side effect is exactly the context an agent needs and is not derivable from the annotations.

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

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

Three sentences, purpose front-loaded, with the consequence (key unlocks other tools) stated early and prerequisites last. Dense but every clause carries information; the final requirements sentence is long though still load-bearing.

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 covering the return value, the description still explains the outcome (key appears in the portal) and the activation flow. What is missing is only granular detail like retry/re-request behavior, which is minor for a signup 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 50%, so the description must compensate — and it does, enumerating all four required inputs (email, 8+ char password, company name, license acceptance) and supplying the license URL that the boolean refers to. This adds meaning (what must be accepted and where) beyond the bare schema types.

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 (create) and resource (Engagemii data account), and differentiates from siblings by explaining the account it creates unlocks search_companies and data_records. An agent can place this action relative to the other tools 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?

The description clearly conveys the context of use — sign up to obtain a key that unlocks search_companies and data_records — and describes the prerequisite flow (email verification before the key activates). It does not explicitly state when NOT to use it (e.g. if the user already has an account), so it stops short of full when/when-not guidance.

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

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

The annotations only cover safety flags (readOnly false, non-idempotent, non-destructive, open-world), leaving the real behavioral story to the description, which delivers it: email verification link, kit built only after owner clicks, delivery by email not in-chat because kits are queued, and resend semantics for repeat requests.

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 offer and contents, then the flow, then the edge cases (queued delivery, one kit per domain). Dense and mostly waste-free, though the parenthetical file list and repeated 'free' emphasis run slightly long.

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

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

With no output schema, the description must explain what happens after the call, and it does: verification email, post-click build, automatic download-link email. Permissions, ownership gating, and repeat behavior are all covered.

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 all three parameters are already documented, so the schema carries the load. The description reinforces the email/domain/ownership meaning but adds no syntax or format detail beyond it, making 3 the correct baseline.

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

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

States a specific verb and resource (request the free Customized Fix Kit for a domain) and enumerates exactly what the kit contains. It is clearly distinguishable from siblings kit_checkout and kit_download, which handle payment and retrieval rather than request.

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 constraints: one kit per domain, one kit is free, repeat requests resend the stored kit, and agencies on client sites should use the data portal instead. It does not explicitly say when to prefer this over the kit_checkout/kit_download siblings, so routing among the kit family is left partly to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds beyond that by disclosing the actual runtime behavior: it returns a short notice rather than performing work, which tells the agent not to expect side effects.

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

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

Three short sentences, front-loaded with 'Retired.' and the replacement pointer. No wasted text.

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-op retired stub with one documented optional param and no output schema, the description covers everything an agent needs: status, behavior on call, and the correct alternative.

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?

Only one optional parameter (domain) and schema description coverage is 100%, so the schema fully documents it. The description adds no syntax or meaning beyond that, making the baseline 3 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+resource and its status: this is the retired Fix Kit checkout, which no longer performs checkout. It explicitly distinguishes itself from the sibling free_kit that now handles the request.

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

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

Explicitly tells the agent when not to use it (retired, no longer starts a checkout) and names the replacement (free_kit) for the Customized Fix Kit. Routing 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description still adds real behavioral value beyond them: the exact return payload (eight files plus badge embed as plain text) and the purchase-gating requirement that the session id come from the checkout success URL. It does not mention failure behavior for an invalid or expired session.

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 with no filler, and the precondition and output payload are front-loaded before the parameter requirement. Every clause carries information an agent needs.

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, but the description compensates by describing the returned content. Combined with annotations that cover safety, the definition is nearly self-sufficient; the only gap is what happens when the session id is invalid or unpaid.

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 carries the parameter burden — and it does: it identifies session_id as the Stripe session id, shows its 'cs_' prefix format, and points to where it is obtained (the checkout success URL). That is meaningful compensation for an otherwise bare string parameter.

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 and resource ('receive all eight Customized Fix Kit files plus the badge embed as plain text') and implicitly contrasts with the sibling kit_checkout by making a paid checkout the precondition. An agent can distinguish this retrieval step from the purchase step without inspecting either schema.

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

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

It clearly states when the tool applies ('After a paid kit_checkout') and what input is needed ('the Stripe session id (cs_...) from the checkout success URL'). It does not name an explicit alternative for unpaid users (e.g., free_kit), so it stops short of full 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?

Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description only needs to add operational context. It does add two useful facts — a 100-row result cap and the API-key requirement — but the key requirement is largely duplicated by the api_key schema field, and 'light rows' is unexplained jargon rather than a real disclosure of 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?

Three compact, front-loaded sentences with no filler; the core capability leads and the constraints follow. Slightly terse to the point of relying on abbreviations ('scope us|all', 'light rows') that compress meaning at the cost of clarity.

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

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

With no output schema the description does state the return cap and auth need, which is the right instinct for a 7-param search tool. But it leaves out pagination/ordering behavior, how filters combine, what 'scored' means, and any differentiation from sibling data tools, so it is only minimally 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 coverage is 57%, and the description groups the filters (industries, states, score range, scope us|all), which usefully names the otherwise-undocumented scoreMin/scoreMax pair. It adds no format, range, or semantics detail beyond that grouping, and omits limit and api_key entirely.

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 (query the scored company dataset) and enumerates the filter dimensions, so an agent knows exactly what it does. However, it never distinguishes itself from close siblings like dataset_sample or data_records, which could easily serve as alternatives for the same dataset.

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 choose this tool over dataset_sample, data_records, or the aeo_* siblings, and no explanation of when a filtered search is appropriate. The only usage-adjacent content is a hard precondition (API key required), not a use/when-not rule.

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