agentimus

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable detail that it returns a pass/warn/fail row per check plus a tally. However, since there are no annotations about return behavior or freshness recency thresholds, the description omits some behavioral context, but with annotations present the bar is met at a 3.

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 waste. The first sentence is front-loaded with the verb+resource and action verbs ('grades'), and the second sentence provides explicit call-to-action usage guidance. 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 an output schema present, return values needn't be enumerated. The tool is single-parameter and well-annotated (read-only, non-destructive), and the description covers what it grades and how results are surfaced (pass/warn/fail + tally). Minor gap: no mention of freshness thresholds or authentication needed, but overall complete for a read-only checklist tool.

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

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

Schema coverage is 100% and only one parameter (post_id) exists, so the schema already fully documents the only input. The description adds context by clarifying the tool grades ONE post/page at a time, which reinforces the post_id parameter's semantics beyond the bare 'The post/page ID to grade.'

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+resource ('Checks ONE post/page's readability for AI') and enumerates the exact grading dimensions (word count, opening summary, concrete figures, heading structure, quotable length, link density, image alt text, freshness). It clearly distinguishes this from siblings focused on traffic, visibility, indexing, and scanning.

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 states clear when-to-use guidance ('Use it when asked to check a page's readability, or to tell an author exactly what to improve on a specific page'). It provides context but doesn't explicitly name alternatives or exclusion cases distinguishing it from the many other agentimus- tools, hence not a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is covered. The description adds valuable behavioral context beyond that: the verdict coding (0/1/2), what 'forward-confirmed' means, and that it can detect impersonators. This is substantive additive behavior 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?

Two sentences with dense, useful content. It packs the PTR hostname, network, engine-match check, verdict scale, and impersonator-detection capability into concise prose. Slightly verbose given the verdict detail, but efficient overall.

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 tool takes a single param with 100% schema coverage, has clear read-only annotations, and an output schema exists, so the description's job is lean. The description effectively explains the return verdict scale and the tool's unique value (imposter detection), which is complete for a single-input lookup tool with this setup.

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% (single param 'ip' is described as IPv4 or IPv6). The description reinforces the parameter's usage by framing it as a crawler-identifying context. Since schema fully covers the parameter, baseline is 3; the description's verdict-scale explanation adds context that helps interpret the ip's purpose, earning a 4.

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

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

The description uses a specific verb ('resolves who it really belongs to') plus clear resource (IP address) and a well-defined verdict scale. It also distinguishes itself from siblings by naming the key differentiator — forward-confirmed reverse DNS and the AI-engine matching verdict, which no sibling tool's name suggests.

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 concrete use-case example ('is this crawler that claims to be GPTBot actually OpenAI?') which implies when to use it. It doesn't explicitly name alternatives or exclusions, but the purpose is niche enough that the use case strongly implies appropriate context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered structurally. The description adds that it returns plain Markdown and is a preview of a single post (not the index), which adds context beyond annotations. However, it doesn't describe pagination, response size limits, or what happens for non-existent post IDs, but with readOnlyHint covering safety, this is acceptable.

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 waste. Every clause earns its place: what it returns, who it's for, that it's read-only, single-post scope, and where the index lives.

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 tool has one parameter (fully documented), an output schema, read-only annotations, and a focused purpose. The description adequately covers what the agent needs: what it does, why it exists, the read-only nature, and scope (single post vs index). For a simple single-purpose tool, this is complete.

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

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

Schema coverage is 100% — the single post_id parameter is fully described in the schema as 'The post/page ID to render as Markdown.' The description adds minimal additional meaning beyond confirming the parameter maps to the post being previewed. Baseline 3 is appropriate since the schema fully documents the one 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 clearly states the tool returns the plain-Markdown version of a post, distinguishing it from rendered HTML previews. It explicitly identifies the '.md twin' and notes the site-wide index has a different location, which helps differentiate from siblings like agentimus-preview-schema.

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

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

The description provides clear context on when to use this tool (for AI clients preferring clean text over rendered HTML) and notes it's a read-only preview of a single post. It doesn't explicitly exclude alternatives or name when not to use it, but the purpose is sufficiently distinct from the 14 sibling tools to guide selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description reinforces this with 'Read-only preview: it reflects the current draft, and changes nothing.' The description also adds the truthful disclosure that it previews based on the current draft state, which is useful context beyond the annotation. Could explicitly note any auth/rate-limit requirements, but with annotations covering safety, this is 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?

Two sentences, purpose explained in the first, dual-mode behavior in the same sentence, and the read-only safety note appended cleanly. Zero wasted words. Front-loaded with the core purpose verb immediately.

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 an output schema present and 100% parameter coverage, the description covers the tool's purpose, two usage modes, and safety profile. It's complete for a single optional-parameter preview tool. Minor gap: doesn't note whether the pretty-printed string vs structured object availability depends on anything, but the output schema likely covers return shape.

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

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

Schema description coverage is 100% — the post_id parameter already documents its semantics (omit/0 for site-wide). The description echoes the same info in the overview section. This meets the baseline of 3 since the schema does the heavy lifting; no additional format or edge-case meaning is added beyond what the schema already provides.

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

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

The description states a specific verb (returns/preview) and resource (JSON-LD @graph Agentimus would emit), and clearly distinguishes the two modes: per-post (pass post_id) vs site-wide identity graph (omit/0). This differentiates it from siblings like agentimus-preview-markdown and agentimus-read-* tools, which cover other preview/read concerns.

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 specifies when to pass post_id vs omit/0, with clear instructions for both scenarios. The read-only framing plus the distinction from the broader family of read tools ('preview' vs 'read') clarifies context. It does not name an alternative tool explicitly, but the two-mode usage guidance is sufficient for single-parameter tool with no obvious competing alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety profile is covered. The description adds that it returns a diagnostic of 'unrecognised referrers', implying some heuristic matching happens, and notes default date ranges. Could add more (e.g., whether 'path' matches exact prefixes only, data freshness), but annotations carry the main behavioral burden.

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, well-structured sentence that front-loads the core purpose then enumerates the return payload and filtering options. Zero wasted words, all clauses earn their place.

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

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

There is a rich output schema and 100% param coverage, so the description need not restate return formats. For a read-only analytics tool with well-annotated safety and 4 optional params, describing the output facets and filter behavior is complete. No critical behavioral gaps identified.

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 explaining what 'path' (landing-path prefix; '/blog') and 'source' (exact label from facets) mean in context, and clarifies default date behavior is governed by to/from. The match on 'source' being 'exact label' is genuinely useful beyond the schema's restatement.

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

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

Clear verb+resource: 'Returns real visits this site received FROM AI assistants' with specific scope (AI referrers vs general traffic). Lists the full output surface (totals, leaderboard, landing pages, daily series, diagnostic) and distinguishes itself from siblings like read-edge-traffic which handles non-AI referral traffic. Distinguishes from 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?

Describes what the output contains (per-assistant leaderboard, landing pages, daily series, unrecognised-referrer diagnostic) which helps the agent select it for AI-referral analytics. Names the source parameter as a facet-like value. Doesn't explicitly state when NOT to use it or name the sibling alternative, but the AI-specific scope is clear enough to guide selection.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: the empty state (hasData=false until a run completes), the cost implication of running (credits), and the fact that it returns the 'latest' run rather than triggering one. This adds meaningful context beyond annotations.

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

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

Two sentences, no wasted words. The first sentence enumerates the exact return contents, and the second covers the empty-state and credit-warning behavior. Every clause earns its place, and the most important info (read-only, no run triggered) is front-loaded in the second 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?

Despite having no parameters and an empty input schema, the description thoroughly documents the return payload (mentions, citations, score, rate, share-of-voice, trends) and behavioral nuances (hasData=false empty state, credit cost of triggering runs). With a rich output schema present and annotations covering safety, this is a complete description for a zero-parameter read 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?

With 0 parameters and 100% schema coverage, the description has no parameter burden to carry. The description explains the output semantics in detail (what the returned data represents: mentions, citations, share-of-voice, trends), which is valuable given the tool takes no inputs. The empty-state behavior (hasData=false) is explicitly disclosed.

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

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

The description clearly states the verb+resource (returns the AI Visibility run) and enumerates specific result contents: AI assistant mentions/citations, overall visibility score and citation rate, per-product share-of-voice, and trend across runs. This distinguishes it from siblings like agentimus-read-search-visibility by explicitly targeting AI assistant visibility rather than search-based visibility.

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

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

The description provides clear contextual guidance: it notes the read-only nature and explicitly warns that this tool does NOT start a run (which would spend AI credits). This helps the agent choose this tool to check existing results rather than trigger new work. However, it doesn't explicitly name alternative tools for different needs, though the sibling set includes starting/invoking tools implicitly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context: it discloses the conditional dependency (requires a connected Cloudflare zone), explains what connected=false means, and clarifies the data scope (edge vs. server). For a read tool with strong annotations, this adds useful context without redundancy.

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

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

The description is dense but efficient - covers purpose, data scope, tie-in to sibling tools, and conditional behavior in roughly four sentences. It earns its length by communicating the tool's unique value proposition without fluff. Slightly long, but every sentence adds meaningful information.

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

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

Given that an output schema exists (covering return structure) and annotations cover the safety profile, the description adequately covers what remains: the semantic distinction from the request log, the edge-vs-server framing, and the connected=false conditional. It's complete for a read-only reporting tool with one parameter and an output schema.

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

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

Schema coverage is 100% - the single 'days' parameter is fully documented in the schema (1-30, default 7). The description adds minimal parameter-level detail beyond what the schema provides, which is acceptable since schema handles the heavy lifting. 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?

Description uses a specific verb ('Returns') with a clear resource (Cloudflare edge traffic from AI crawlers) and distinct scope (per-crawler totals, per-company rollups, edge-vs-policy conflicts). It differentiates from sibling agentimus-read-ai-traffic by explicitly framing this as 'the missing before-the-server half' vs. 'The request log only sees what reached the server.'

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 explains the when-to-use context clearly: this tool is for seeing what happened BEFORE the request reached the server, complementing the request log. It also states the conditional on Cloudflare zone connection and the connected=false return. However, it doesn't explicitly name alternative tools or say when NOT to use it, though the contrast with the request log implies the sibling distinction.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond that: the shared inspection budget, the paging/rotation mechanics, the connected=false fallback when no key is connected, and the stable ordering of problem pages. Rich transparency beyond annotation baseline.

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

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

The description is information-dense but quite long and complex for what could be more simply stated. The three-tier explanation and rotation mechanics are valuable but the prose is meandering with many parenthetical asides. It earns its content but could be tighter and better structured.

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

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

This is a structurally complex tool (three tiers, budgets, cadence, paging, fallbacks) with an output schema present. The description thoroughly covers the bounded sharing, the paging mechanism, the healthy/healed semantics, and the disconnected state. Everything the agent needs to invoke and interpret this correctly is present. Output schema covers return-value details.

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

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

Schema description coverage is 100%, so both parameters (problemsPage, problemsState) are fully documented in the schema. The description reinforces their meaning (state becomes one page of exactly that state's rows, problemsPage is ignored without problemsState) but doesn't add format/syntax beyond what the schema states. 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?

Clear verb+resource: 'Get Google index status'. The description states exactly what it returns (whether Google's index holds pages when Search Console is connected), distinguishes from siblings by noting 'read-search-performance has the traffic', and explains the Google/Bing parallel. This clearly separates it from the traffic/visibility 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?

Explicitly describes the three-tier mechanism (watchlist, promoted problems, whole-site rotation) with honest caveats: shared 2,000-inspections/day budget, no bulk index report, bounded problem rows, and how to page through all of one state's rows via problemsState+problemsPage. It names the sibling with traffic (read-search-performance) as the alternative. Strong when-to-use guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context by detailing the exact return structure (score, band pillars, action plan, and full check list with statuses), which goes beyond what the annotations alone convey. No contradiction with annotations. It could add response-size/format notes, but with an output schema present the bar is reasonably met.

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

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

Front-loaded with the primary deliverable ('Returns the site's AI-visibility health'), then enumerates subcomponents in a dense but efficiently-parsed list, and closes with a practical use-case question. It is a moderately long sentence but every clause earns its place by enumerating distinct output elements. Slightly verbose with the pillar enumeration, justifying a 4 rather than 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 zero parameters, clear annotations (readOnly/destructive safety), an output schema present, and no nested objects, the description covers everything needed. The wide-ranging output elements (score, bands, action plan, check statuses, fixes) are all stated, and the tool's complexity is low. Given the rich schema+annotation context, the description is complete for agent use.

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

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

The tool has zero parameters and schema description coverage is 100% (an empty object), so there are no parameter meanings to add. The baseline for 0 params is 4, which the description fully earns by making clear the operation is a whole-site report with no inputs 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 uses a specific verb ('Returns') with a clear resource ('the site's AI-visibility health') and enumerates the exact output elements: blended 0-100 AEO/GEO score with band pillars, impact-ranked action plan, and full readiness check list with pass/warn/fail status and fixes. This distinguishes it well from siblings like agentimus-read-ai-visibility by focusing on the actionable readiness report against the score-only alternatives.

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?

Includes an explicit use-case quote ('Use this to answer `how ready is my site to be found and cited by AI, and what should I fix first?`'), clearly framing when the tool is appropriate. It does not explicitly name alternatives/exclusions, but the question-oriented framing and focus on 'what should I fix' implies the decision guidance. Given zero parameters, the usage context is sufficient.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds valuable behavioral context beyond annotations: stale cursor pagination (newest first, cursor-based), the verdict meaning (0/1/2), and that the network field is only populated when 'identify every bot' is on. This adds real behavioral nuance beyond what structured fields give.

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, dense but efficient. The first sentence packs scope, endpoint types, ordering, pagination, row structure, and verdict legend; the second lists the filters. Zero wasted words while conveying substantial 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 output schema exists and documents return values, and the input schema covers all 9 parameters at 100%. The description ties it together with the discovery-endpoint scope, pagination contract, and the network-population caveat. For a read-only filtered log tool with strong schema and output schema, this is complete.

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

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

Schema coverage is 100% and all 9 parameters already have rich descriptions (date formats, enum meanings, pagination cursor semantics, clamping behavior). The description reinforces which filters exist but doesn't meaningfully extend beyond the schema. At high schema coverage, baseline 3 is correct since the description adds the discovery-endpoint context but no param-level details 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?

Very specific: verb 'returns' + resource 'individual requests AI crawlers and agents made to discovery endpoints' + exact endpoint list + clear ordering and pagination. Distinguishes clearly from siblings like agentimus-read-ai-traffic (broader) and agentimus-read-edge-traffic (edge-level). The detailed scope of what these requests are (discovery endpoints) makes it 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?

Clearly states the domain (discovery-endpoint requests), the ordering, and pagination behavior. It doesn't name explicit alternatives or when-not-to-use, but the list of filter dimensions and the distinctive scope (specific discovery endpoints) implicitly differentiates it from read-ai-traffic. Could explicitly point to the sibling for broader traffic, but the context is strong enough.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context: possible return states ('not_connected', 'collecting', 'too_thin' when no honest verdict is possible) and clarifies no industry-benchmark comparison occurs. However, it doesn't disclose pagination behavior, exact output volume, or search-source election details beyond the optional parameter — but with annotations covering safety, this is adequate.

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

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

The description is information-dense with zero filler, but it's a long single block of prose without clear visual structure. It front-loads the main purpose in the first sentence, which is ideal. The two-group explanation and state-return note are all substantive content; while compact, breaking it into bullet points would marginally improve scannability.

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?

Has an output schema, so return value structure doesn't need description coverage. The description covers what each returned page carries (searches, totals, qualification basis), when states appear, and downstream actions. For a single-parameter read tool with schema and annotations present, this is reasonably complete, though it could mention whether results are sorted or capped.

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

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

Schema description coverage is 100% — the single 'source' parameter is fully documented in the schema ('Which engine to read: google or bing. Omit for the richer one that has data.'). The description adds the semantic that omitting source selects the richer data source, which reinforces the schema. Baseline 3 is appropriate since the schema handles parameter documentation.

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?

Describes a specific verb+resource: 'Returns the pages that already rank in classic search but under-earn — the worklist behind the Search Opportunities screen.' It clearly identifies the tool's function and defines the two qualification groups (almostThere and seenNotClicked) with specific ranking/click-rate thresholds. It distinguishes itself from siblings by positioning this as the 'under-earning pages' worklist versus read-search-performance or read-ai-traffic.

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

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

Provides explicit when-to-use context by explaining the two qualifying groups and that the click benchmark is the site's OWN page-one median, never an industry benchmark — a critical nuance that prevents misuse. It also explicitly names an alternative path ('Pair it with write-description / update-content to act on what it finds'), giving clear guidance on downstream actions and when this tool is appropriate.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description builds on this by explaining the data provenance (engine's own numbers, never estimated, never blended across engines). It discloses the subtle counting difference in Bing reports — a genuine behavioral quirk beyond what annotations convey. This is rich, non-obvious context that materially helps the agent.

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

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

The description is dense but front-loaded with the core purpose, then progressively adds edge cases and caveats. It's longer than the calibration example but every sentence carries meaning — the Bing reconciliation quirk is important. No wasted words, though it could be trimmed slightly.

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

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

For a read-only analytics tool with an output schema, full schema coverage, and readOnlyHint annotations, the description covers the purpose, return values (top searches, top pages), edge cases (source=''), and the problematic Bing counting discrepancy. This is complete enough for an agent to invoke and correctly interpret results.

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 source parameter is fully documented. The description adds the value context of 'Omit for the richer one that has data' (referenced in the schema) and explains what each source returns, but doesn't add significant new parameter-level semantics beyond the schema. Baseline 3 is appropriate when schema fully documents the 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 is highly specific: verb ('Returns'), resource ('classic search performance'), and scope ('total times shown, visits, click rate, impression-weighted average rank, top searches, top pages'). It clearly distinguishes from siblings like 'agentimus-read-search-opportunities' and 'agentimus-read-search-visibility' by specifying this is the classic-search performance metric. The purpose is unambiguous.

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

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

It explicitly states when to use ('Use it to answer "how is this site doing in search?"'), explains the source='' edge case, and provides detailed guidance on interpreting source='bing' discrepancies. It explicitly tells the agent to state the split rather than reconcile numbers, which is actionable guidance no other tool provides.

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 readOnlyHint=true and destructiveHint=false already in annotations, the bar is lowered, and the description adds value by disclosing the conditional behavior (connected=false when no key is connected) and the data source dependency (Bing Webmaster Tools connection). It also frames the return values in a memorable way (daily trend, conflicts, etc.). Minor gap: doesn't describe pagination or error behavior, but annotations cover the safety profile.

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

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

The description is a single focused paragraph that front-loads the core action and then enumerates specific return values. It earns its length by adding substantive behavioral and purpose context rather than filler. Slightly longer than strictly necessary but every clause adds information.

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

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

Given that readOnly annotations are present, an output schema exists, a single fully-documented parameter, and no nested objects, the description is complete for an agent to select and confidently invoke this tool. It covers purpose, data-source dependency, conditional behavior, return-value summary, and distinct positioning amid 14 siblings.

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% (days parameter fully documented). The description doesn't add parameter-level detail beyond the schema, but it does contextualize the time window idea with 'daily trend' for pages in the index. Per the rubric, baseline 3 is correct when the schema carries the parameter documentation burden.

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

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

The description clearly states the verb ('Returns') and the resource (how much of the site sits in Bing's index and crawler access cleanly). It enumerates specific output contents (pages in index, pages crawled, crawl errors, robots.txt blocks, policy conflicts) and explicitly distinguishes it from siblings by tying it to AI-search visibility (ChatGPT/Copilot), connecting the tool's purpose to a concrete user question about AI search findability.

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 prerequisite context: requires the owner to have connected Bing Webmaster Tools, and notes it returns connected=false when no key is connected. It gives a distinctive angle versus sibling tools by positioning this as the closest measurable answer to 'can AI search find this site', but doesn't explicitly enumerate exclusions or alternative tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only safety profile is covered. The description adds critical value by disclosing that it does NOT fetch URLs — a key non-obvious behavioral trait — and flags the same-origin requirement. This transparently manages agent expectations about what the call will and won't do.

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

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

The first sentence delivers the core purpose efficiently. The NOTE section adds required behavioral guidance. Slightly dense wrapping but logically structured: purpose first, then critical caveat.

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

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

Output schema exists, so return-value explanation is not required. For a zero-parameter informational tool, the description covers purpose, scope, execution caveat, and security rationale. Completeness good given the tool's simple read-only nature.

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

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

There are zero parameters, so the baseline is 4. The description compensates by explaining what the output conceptually covers (sensitive paths, debug posture, environment), which contextualizes the return shape for the agent despite no inputs or output schema detail being 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?

Description clearly states it returns a list of sensitive paths probed plus debug posture and environment detection. Distinguishes from siblings by emphasizing it's a listing/scoping tool, not an action tool. Slightly dense but specific verb+resource and differentiated from the many 'read-*' 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?

Explicitly clarifies when to NOT use this tool versus the live probe, noting the probe must run same-origin from the admin browser and explains the server-loopback masking rationale. This gives clear usage boundaries beyond raw purpose.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, which the description reinforces with 'READ-ONLY: it suggests'. The description adds meaningful context beyond annotations: it explains the output format (target post, exact phrase to link, empty-phrase fallback to 'See also' line, one-line reason) and clarifies the local-signals-only constraint and that no AI call is spent — useful behavioral specifics that annotations don't provide.

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

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

The description is a single dense paragraph but front-loads the core purpose immediately. All sentences earn their place: scope, signal source, cost implication, output format, and the read-only clarification. Slightly verbose but justified given the output-shape details it conveys; could be split into two sentences for readability.

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

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

There is an output schema present, so the description needn't detail return values exhaustively, but it usefully summarizes the shape (target, phrase, reason). The tool has a single simple parameter, clear annotations, and a good description. The behavior around the empty-phrase/append-'See also' edge case is a nice completeness touch. Minor gap: it doesn't mention what happens if no candidates are found, but overall adequate.

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

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

Schema description coverage is 100% — the single post_id parameter is fully documented in the schema. The description adds marginal context by implying post_id selects the page to analyze, but the schema already covers the parameter meaning. Baseline 3 is appropriate given full schema coverage.

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

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

The description uses a specific verb-resource combination ('Suggests which of the site's OWN posts this post should link to') that precisely scopes the operation. It clearly distinguishes from siblings (all the agentimus-read-* and agentimus-scan-* tools) by focusing on internal link suggestions with local-only signals, and explicitly calls out that no AI call is spent — a meaningful differentiator.

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 explains what the tool does (suggests internal links from local signals) and what it does NOT do (no AI call, read-only, doesn't insert links). It mentions the governed update tool as the alternative for actually inserting links. It doesn't explicitly state when-not-to-use or when-to-prefer alternatives, but the boundaries are reasonably clear.

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