seegeo

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

Goes well beyond the annotations by disclosing latency (20–40s), default waiting behavior, the id-passing fallback when the wait expires, and the ten-minute result-caching rule — all operationally important facts an agent must know before invoking. The caching note is consistent with idempotentHint=false (a returned cached result is still not a guaranteed side-effect-free repeat) and contradicts nothing.

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 sentences, front-loaded with what the audit covers and returns, then timing and the polling fallback. Every clause carries distinct information; 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 carries the return contract and does so adequately: grade, category scores, findings with fixes, plus the partial-result path via get_audit. Nothing an agent needs to call this tool correctly appears 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 meaning by clarifying that waiting is the default and that timeout expiry produces an id to pass to get_audit, which mirrors and reinforces the wait/timeoutSeconds semantics rather than merely restating them.

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 ('runs SeeGeo's full audit of a domain') and enumerates the audited dimensions (crawler access for 16 AI bots, structured data, content extractability, etc.), then names the return artifact (grade A–F, category scores, findings with fixes). This clearly distinguishes it from crawler_check, get_audit, and list_audits.

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 routes the agent to get_audit when the wait times out and discloses the 10-minute re-audit cache behavior that selects against redundant calls. It does not explicitly contrast itself with crawler_check, so the alternative-selection guidance is strong but not exhaustive.

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 (readOnlyHint, openWorldHint), and the description adds real behavioral detail: the exact crawlers checked, that it fetches the homepage impersonating four specific bots, and the runtime ('a few seconds'). It still doesn't say what happens on unreachable hosts or 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 tight sentences, front-loaded with what is inspected and what is fetched, ending with the scoping caveat. Every clause earns its place 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?

For a single-parameter, read-only probe with no output schema, the description conveys the outcome it produces ('whether a bot wall blocks them') and the cost of calling it. The precise shape of the returned result is left unspecified, which is the only notable 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 100% and the single 'domain' parameter is fully documented in the schema, including that only the host is used. The description adds no parsing or format guidance beyond that, so the 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?

States concrete verbs (reads robots.txt, fetches the homepage as named user agents) and the exact resource (AI crawler access for a domain). The closing 'does not count as an audit' implicitly separates it from the sibling audit_site, so an agent can tell the two apart.

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 scenario clearly: a quick per-crawler access check that is explicitly not an audit, which tells the agent when to prefer this over audit_site. It stops short of naming the alternative tool or stating a hard when-not condition, so it is clear context without 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, but the description adds meaningful behavior: the returned payload differs depending on whether the audit is still running or finished, and includeReport pulls a large report into structuredContent. It stops short of disclosing failure modes (e.g., unknown id) or polling expectations.

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, zero filler, and the primary return contract is front-loaded before the optional-report hint. 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?

With no output schema and a mutation-free read tool, the description carries the return-value burden well by describing both the in-progress and completed response shapes. The gap is maxFindings, whose paging/truncation semantics are explained nowhere.

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 67%: id and includeReport carry schema descriptions, while maxFindings is undocumented in both schema and description. The description reinforces includeReport's effect ('full report object with evidence'), which is slightly beyond the schema's wording, but adds nothing for maxFindings or id.

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 ('Returns an audit's status... or its grade, category scores and findings') and describes the output shape by run state, which clearly separates it from write tools like audit_site. It does not explicitly name a sibling such as list_audits, so differentiation is implicit via 'by id' rather than stated.

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 only usage guidance is conditional and parameter-scoped: 'Set includeReport to get the full report object with evidence.' There is no statement of when to prefer this over list_audits or audit_site, and no prerequisite or rate/auth context, so usage is implied rather than 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the useful disclosure of what fields are returned (domain, status, grade, id), but says nothing about ordering guarantees beyond 'most recent', the default count of 10, or that results are capped.

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 short, front-loaded sentence with no filler, which is appropriate for a simple list tool. It is efficient, though it spends its words on return fields while omitting the only parameter.

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, naming the returned fields is genuinely helpful. However, for a tool whose sole parameter controls result count and whose default and maximum are invisible in the schema, the description leaves the agent unable to reason about result volume.

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 limit parameter has 0% schema description coverage, so the description carries the full burden and it fails: limit, its default of 10, and its 1-100 range are never mentioned. 'Most recent' only loosely implies the recency ordering that limit interacts with.

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 the specific resource (the account's audits) and its scope (most recent), and lists the fields returned, so an agent knows what it gets. The listing verb is only implied by the tool name/title rather than stated, but the resource 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?

There is no guidance on when to use this versus get_audit or audit_site, despite get_audit being an obvious near-sibling for fetching a single audit. Nothing indicates that this is the browse/list entry point and get_audit is the fetch-by-id path.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds useful content context by enumerating the returned fields (plan, audits used, allowance), but says nothing about auth requirements, rate limits, or freshness of the usage counters.

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 compact sentence with zero filler, and the most important content (the key's plan and usage) is front-loaded. Nothing could be removed 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 parameterless, read-only lookup with no output schema, the description adequately enumerates the returned fields so the agent knows what to expect. It stops short of noting whether usage is live or cached, which is a minor omission given the tool's simplicity.

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

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

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. The schema coverage is 100% and empty, so no compensating text is required.

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 the specific resource and its contents — the key's plan, API audits used this month, and the monthly allowance — so an agent knows exactly what data comes back. It is a noun phrase rather than a verb+resource, and it does not explicitly differentiate itself from audit-oriented siblings like list_audits or get_audit, but the scope 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?

There is no statement of when to call this tool versus the audit siblings, nor any prerequisite or trigger condition. An agent must infer from the name alone that this is a quota/plan lookup rather than an audit listing.

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