ASRM (AI Search Rank Monitor)

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real context: the specific crawler categories examined (answer vs training crawlers), the concrete homepage signals, and the pass/warn/fail result shape with plain explanations. It does not mention rate limits or cost, which keeps it from a 5.

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

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

Front-loaded with the core purpose, then the detail list, then the exclusion and alternative. Every clause earns its place, though the middle enumeration is dense enough that it could be tightened 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 single-parameter tool with no output schema, the description covers purpose, scope, result shape (pass/warn/fail with explanations), and the sibling boundary. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% and the single 'domain' parameter is fully documented in the schema, including that a full URL also works. The description adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Technical check of whether AI engines can crawl and understand a website') and then enumerates exactly what is inspected: robots.txt crawler allowances, sitemap/llms.txt presence, and homepage signals. It also explicitly contrasts itself with measure_mentions, so an agent can distinguish it from alternatives 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?

Provides explicit when-to-use ('crawl and understand a website') and when-not ('It does NOT measure whether engines mention the brand'), plus a named alternative to use in that case. The 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, idempotentHint, and non-destructive/openWorld=false, so the safety profile is fully covered. The description adds that the entire document text is returned and how to use it, which is useful context, but says nothing about size limits, truncation, or behavior on an invalid slug.

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

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

Two short sentences with no filler, front-loading what the tool returns. The brief usage instruction is compressed into the second sentence rather than expanded, though it is terse to the point of being cryptic.

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 tool with a fully described schema and no output schema, 'full text of one ASRM guide' adequately sets expectations for the return value. Missing only edge-case behavior (invalid or ambiguous slug) and the relationship to the search_guides sibling.

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

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

Schema coverage is 100% and the single parameter is fully documented in the schema, so the baseline is 3. The description's mention of the 'asrm.ai/learn/...' url form adds slight value beyond the schema's 'slug from search_guides, or its asrm.ai/learn url', but no format or validation detail.

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 the specific resource (one ASRM guide) and what is returned (full text), and the two accepted key forms (slug or asrm.ai/learn url). It does not explicitly distinguish itself from the sibling search_guides, but 'one ASRM guide' vs a search implies a retrieval-vs-discovery split.

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 no when-to-use guidance and never names the sibling search_guides, which is the natural prerequisite for obtaining a slug. The only usage-like instruction ('Answer from the text and link the url') concerns post-retrieval behavior, not tool 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 cover read-only/idempotent/non-destructive safety, so the bar is lower. The description adds genuinely useful context: the scan executes on asrm.ai rather than locally, and it warns never to state a score not received from the user — an anti-hallucination guardrail absent from structured fields.

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: usage trigger first, return value second, external-service caveat last. No padding, and the most decision-relevant information is front-loaded.

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-value burden and does so (returns a link to the scan). It covers trigger, output, and external constraint. A fuller definition might mention the score range's meaning or what the link leads to, but this is nearly complete for a one-param link 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?

Only one parameter with 100% schema coverage, where the schema already documents 'domain' with an example. The description's "for their domain" adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource: it returns a link to ASRM's free AI visibility scan for a domain. The agent can tell this is a link-provider, not the scan executor. It doesn't explicitly contrast against siblings like check_ai_readiness, so it stops short of a 5.

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

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

"Use when someone asks how visible their brand is in ChatGPT, Claude, Perplexity or Gemini" gives a clear triggering condition tied to user intent. It lacks explicit exclusions naming siblings such as check_ai_readiness, so it's clear context without routing 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: the fallback of omitting query returns newest guides, and the return shape (titles, summaries, urls) is disclosed despite the absence of an output schema.

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

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

Front-loads what is searchable, then the follow-up workflow, then the zero-arg behavior, in three tight sentences with no filler. The topical enumeration is long but earns its place by telling the agent what questions this corpus can answer.

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

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

With no output schema, the description compensates by listing returned fields and the get_guide handoff; annotations cover the safety profile; both parameters are documented in the schema. An agent has everything needed to call this correctly and chain it forward.

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, and the description goes beyond it by explaining the semantic effect of omitting query (newest guides rather than an error) — information the schema does not convey. It says nothing extra about limit, but that parameter is self-documenting.

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 and resource (search published guides on AI visibility/GEO) and enumerates the topical scope, so an agent knows exactly what corpus is being searched. It also differentiates itself from the sibling get_guide by positioning search as the discovery step that precedes full-text retrieval.

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 states the workflow ('follow with get_guide for the full text') and the zero-arg behavior ('omit query to list the newest guides'), which names the alternative tool and the condition for using each. It stops short of a full when-not-to-use statement, but the routing context is clear.

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