Outrings Web Intelligence

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint true and destructiveHint false, clearly establishing safe, read-only behavior. The description adds value by stating execution time ('2-8 seconds'), which is not in annotations. No contradictions.

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

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

Three sentences, each serving a distinct purpose: (1) what it does and returns, (2) when to use with examples, (3) timing and sibling comparison. Could be slightly more concise but is well-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?

Given zero output schema and moderate tool complexity (2 params, one with enum), the description fully covers what the tool returns (scores, categories, ranked list), how it works (200 checks), constraints (2-8 seconds timing), and when to prefer alternatives. No gaps.

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 parameters are fully documented in the schema. The description goes beyond by showing that a bare domain works and by explaining each detail option's purpose (e.g., 'summary: scores plus priority actions (default, best for most answers)'). Adds real meaning beyond 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?

Clearly describes the tool as running a 'full 200-check audit of a website' and lists specific outputs (overall score, category scores, ranked fix list). Differentiates from sibling tool check_category by stating it's for broad questions about a site.

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 says when to use this tool ('user asks a broad question about a site') and provides examples of such queries. Also gives when-not-to-use guidance ('If user only cares about one area, check_category is faster') and names the alternative (check_category).

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, openWorldHint, idempotentHint, and destructiveHint=false, so the safety and idempotency profile is fully covered. The description goes beyond annotations by detailing what inputs it accepts (a URL with a bare domain treated as https://), what exact checks it performs, and what limitations exist (it doesn't predict ranking/citation). One point is deducted because it doesn't mention rate limits, cache behavior, or whether the check is synchronous vs asynchronous, but the annotations cover the most critical behavioral traits.

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 three well-structured sentences. The first sentence states the core purpose and scope. The second sentence details the exact mechanisms checked. The third sentence clarifies boundaries and caveats. Every sentence adds unique value, and there is no fluff or repetition. The front-loading of the primary action is excellent.

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

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

Given the tool has only one parameter with 100% schema coverage, no output schema, and no nested objects, the description provides thorough context: it names 11 crawlers, explains the different checks (robots.txt, HTML, structured data, llms.txt), and clarifies the tool's scope boundary (no ranking/citation prediction). The annotations cover read-only idempotent behavior fully. There is no gap for the agent to infer incorrectly.

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%, providing a baseline of 3. The description adds value by explaining that a bare domain works and is treated as https://example.com, which is a helpful interpretation detail not present in the schema. This pushes the score to 4, but no further because the schema already fully describes 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 specifies a very precise verb and resource: 'measures technical crawler access and the page signals' that affect AI system retrieval. It lists 11 specific crawlers and the exact artifacts checked (robots.txt, HTML vs JS, structured data, llms.txt). The purpose is immediately distinguishable from siblings like 'audit_website' (which presumably covers a broader range of issues) and 'get_score' (which quantifies something else).

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

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

The description explicitly states when to use this tool ('to rule out or confirm a technical blocker') and what it does NOT determine ('whether an assistant will rank, select, mention or cite the page'), with a clear alternative framing: 'access is a precondition for citation, not a cause of it.' It also provides nuance between crawlers (e.g., OAI-SearchBot vs GPTBot for different OpenAI purposes), helping the agent choose the right interpretation of results.

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, destructiveHint=false, and idempotentHint=true, so the description does not need to restate these. The description adds useful behavioral context beyond annotations by explaining the return value structure (verdict, failing checks, why each matters, how to fix) and that it returns both passing and failing checks (with an option to filter). This is strong enhancement, though it doesn't mention any limits or side effects (which are not needed given 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?

The description is two sentences: the first states the tool's action and output, the second lists categories and usage guidance. There is no wasted text. However, the first sentence could be slightly more concise by removing 'and return its verdict', as the tuple of outputs is already implied by the verb. Still, it is very efficient.

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 inspection tool with 3 parameters (all with schema descriptions, 2 required, 1 boolean defaulting to false), the description completely covers purpose, usage scope, category enumeration, and guidance vs sibling. No output schema exists, but the description explains what the output contains (verdict, failures, importance, fixes). The tool is simple and the description addresses all agent needs.

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 significant value by giving the full list of 20 valid category options and explaining the return structure for each category, which the schema's enum descriptions alone do not provide. It also implicitly clarifies that 'url' accepts bare domains, which the schema explicitly describes as 'A bare domain works — "example.com" is treated as https://example.com.'. The added value exceeds the baseline, 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 clearly states the tool inspects a single area and returns verdicts, failures, impacts, and fixes. It lists 20 specific categories (seo, ai, security, etc.), establishing a precise verb-resource relationship and distinguishing it from siblings like audit_website.

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

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

The description explicitly tells the agent to 'Use this rather than audit_website when the question is narrow' and provides concrete examples of narrow questions ('is my site secure', 'why is my SEO bad', 'can ChatGPT see my site'). This is exemplary alternative 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, idempotentHint=true, and destructiveHint=false, so the description carries less burden. The description adds key behavioral context: it's a real audit that takes several seconds per URL. This helps set expectations for latency and cost, which annotations cannot convey.

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

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

Three sentences, each delivering distinct value: purpose and output, example use cases, and latency warning. No filler words or redundant 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 the simple schema (1 parameter, no output schema), the description sufficiently covers purpose, input, behavior, and performance. Minor gap: it doesn't describe the output format (e.g., is it just scores, or also text?), but since there's no output schema, the description could add a bit more structure. An agent might infer the output from the ranked gaps mention.

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%, with the single parameter 'urls' described as 'The sites to compare. Bare domains are fine.' The description adds value by clarifying the minimum and maximum (2–4 sites) and the time cost per URL, which the schema doesn't convey. Combined, this gives the agent full understanding.

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 scores two to four sites, returns them ranked with category gaps, and provides specific example queries. This distinguishes it from siblings like audit_website (which likely audits a single site) and get_score (likely returns a single score for one site).

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 when-to-use guidance with examples ('how do I compare to my competitors' or 'which of these is better built'), and implicitly warns about time cost ('takes several seconds per URL'). It does not explicitly state when not to use it or mention alternatives among siblings.

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 the safety profile is clear. The description adds valuable behavioral context: the badge renders a live SVG with a score that refreshes every six hours and links to the full audit. This goes beyond what annotations provide. However, it doesn't mention that the badge is server-rendered or any caching implications, which would be minor improvements.

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 three sentences, all essential: first states the output, second describes the badge's features and behavior, third states the usage context. No wasted words. Front-loaded with the core purpose ('Produce the HTML...'). Perfectly sized for the tool's complexity.

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 4 parameters with solid schema descriptions, clear annotations, and no output schema, the description covers the key behavioral aspects (refresh, link, display). It's complete for the tool's purpose. Minor gap: it doesn't mention that output is HTML/Markdown text (vs. binary) or that the user must be the site owner to use the badge meaningfully, but these are inferred.

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 25%, so the description should compensate but does not describe parameter meaning beyond the schema. The schema already provides solid descriptions for 'url' (with example handling), 'style', 'theme', and 'metric' (with defaults). The description adds no parameter-specific information, so it relies on the schema. Baseline 3 is appropriate given the schema does most of the work.

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 produces HTML/Markdown for an embeddable badge showing a live SVG score that refreshes every six hours and links to the full audit. The verb 'generate' is specific and the resource 'embeddable verification badge' is distinct from sibling tools like audit_website or get_score, though it could more explicitly contrast with get_score which returns raw data rather than embed code.

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 says 'Use this when someone wants to display that their site was checked,' which provides clear context for when to use this tool. However, it does not explicitly mention when not to use it (e.g., if the user just wants a score number, use get_score instead) or name alternatives. The sibling tools list includes get_score which could be confused for this purpose, so more explicit exclusions would help.

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, openWorldHint, idempotentHint, and destructiveHint. The description adds valuable behavioral context beyond annotations: it is 'the cheapest useful call' (indicating low cost/impact), and specifies that it returns only scores/grades without 'findings or prose'. This tells the agent what data is omitted, which is helpful.

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

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

The description is two sentences, no wasted words. The first sentence defines what the tool does and what it omits; the second provides usage guidance. Both sentences are front-loaded and 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?

Given only one parameter, full schema coverage, and no output schema, the description is sufficiently complete. It explains the output (score, grade, categories) and usage context. Some minor additional detail about the return structure could help given the lack of an output schema, but the description already does well.

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 the url parameter already well-documented (including domain handling). The description adds general context ('when comparing sites') but does not provide additional parameter-level semantics beyond what the schema already states. Per guidelines, 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 tool returns 'overall score, letter grade and every category score' and explicitly says it provides 'no findings or prose', which distinguishes it from sibling tools like audit_website or check_category that would offer detailed findings. The 'cheapest useful call' phrasing further differentiates it as a lightweight option.

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

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

The description provides explicit guidance: 'Use it when comparing sites, when the user only wants a number, or as a first step before deciding which category to look into.' This clearly states when to use it, and implicitly suggests alternatives for other needs (e.g., when findings are needed). It could be improved by naming sibling tools directly, but is very clear already.

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, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds non-obvious behavior: the collector does not execute JavaScript, and reports only what is in served HTML and fetched responses. This goes beyond the annotations. The description does not discuss rate limits or authentication needs, but for this informational tool the added behavioral context is strong. Score 4 (not 5 because annotations already carried the main 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 two sentences long, with the first sentence front-loading the core purpose and scope. The second sentence adds behavioral nuance and use cases. Every clause adds value; there is no filler. One minor point: the second sentence could be slightly more scannable if split, but it remains effective and economical. Score 4 (concise overall, but not as punchy as the calibration example's two-sentence structure).

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

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

Given the tool has 3 parameters with 100% schema coverage, no output schema, and a complex enum-driven behavior, the description adequately explains the output semantics (column-like list of items) and the limitation of non-JavaScript execution. However, it does not describe the output format (e.g., JSON array, each item's fields), and since there is no output schema, that gap is notable. The description is very strong for a read-only listing tool, but without any output shape hints, an agent may not know how to parse results. Score 4.

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 baseline is 3. The description adds value beyond schema: it explains what each inventory type returns in words (e.g., 'externalDomains is the deduplicated hosts they point at; endpoints are API paths found in scripts; discovered are paths seen in sitemaps and robots.txt'). This helps an agent choose the correct enum value. Also clarifies that 'limit' caps returned rows but total count is always reported. No credit for 'url' since the schema already explains bare domain handling. Score 4 for going measurably beyond schema.

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

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

The description begins with a specific verb and resource ('Return a complete inventory of what the Outrings collector observed on a page') and immediately clarifies the scope ('not a sample'). It enumerates all 14+ inventory types, leaving no ambiguity about what the tool covers. The distinct resource and action also help distinguish it from siblings like 'audit_website' or 'get_score'.

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

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

The description explicitly states when to use the tool via several concrete use cases: 'what third-party scripts am I loading', 'which email addresses are exposed on my site', 'how many images are missing alt text', 'what does my page link out to'. It also includes an important exclusion: 'The collector does not execute JavaScript… not necessarily everything a real browser would end up loading'. This provides clear when-not guidance. While no sibling tool is named, the use-case framing substitutes effectively.

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 description goes far beyond the annotations by detailing the write behavior ('stores a durable snapshot'), snapshot retention policy ('at most once per site per six hours'), the meaning of 'comparable', and that ruleset changes affect comparisons. This information is critical for correct use and is not present in the annotations alone.

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, then provides usage guidance, behavioral details, and caveats in a logical order. Every sentence adds value, though the length could be slightly trimmed without losing substance. Very 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?

Given the tool's complexity (write action, snapshot retention, comparability flag) and the simplicity of the input schema (one string parameter), the description covers all necessary context: when to use, what it does, what the output indicates (comparable), and important pitfalls (baseline timing, ruleset changes). No gaps remain.

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

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

The input schema already fully describes the single parameter 'url' (including the bare domain handling). The description adds no further parameter-specific semantics, but with 100% schema coverage, no additional detail is needed. A baseline score of 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 tool's purpose: 'Re-audit a site and report what moved since it was last checked: which findings are new, which were resolved, and how each category score shifted.' It uses a specific verb ('re-audit' and 'report') and a clear resource ('site'), and distinguishes itself from siblings by noting 'Unlike the other tools this one WRITES'.

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

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

The description explicitly states when to use it: 'Use it after the user says they fixed something, or to verify that a deployment did not regress anything.' It also provides guidance on how to interpret results, such as checking 'comparable' and not assuming baseline is the last change.

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