SEOLint

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

States the basic retrieval action but omits behavioral details like error handling for invalid IDs, caching, or result freshness given no annotations exist.

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?

Single sentence is appropriately sized, front-loaded with action, and contains no redundancy for this simple tool.

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?

Adequate for a simple getter with one parameter and no output schema, though mentioning error cases (e.g., expired scans) would improve completeness.

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?

Mentions 'by its ID' creating semantic link to scanId parameter, but with 100% schema coverage already explaining the UUID format, this meets the baseline without significant additional context.

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 ('Get') and resource ('results of a previous SEOLint scan'), with 'previous' implicitly distinguishing it from sibling scan_website, though explicit contrast is missing.

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?

Implies retrieval workflow via 'previous' but lacks explicit when-to-use guidance or contrast with scan_website 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?

With no annotations provided, the description carries the full burden. It compensates by detailing the specific intelligence components returned (site goal, ICP, sitemap gaps, template issues, coverage by page type), effectively describing the output. However, it lacks operational details like safety profile, caching behavior, or rate limits.

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 tightly constructed sentences with zero waste. The first front-loads the action ('Get the full intelligence picture') followed by a colon-delimited list of specific outputs. The second sentence provides clear 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?

Given the lack of output schema and annotations, the description appropriately compensates by enumerating the five specific intelligence components returned. However, it could further improve by indicating the structure/format of the returned data (e.g., JSON structure, nested objects) since no output schema exists to document this.

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 'domain' parameter clearly documented as 'The domain, e.g. example.com'. Per guidelines, with high schema coverage the baseline is 3. The description references 'for a domain' which aligns with the schema but does not add additional semantic context beyond the schema definition.

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 specific verbs ('Get') and resources ('intelligence picture') and explicitly lists the specific data returned (site goal, ICP, sitemap structure, cross-page patterns, scan coverage). It clearly distinguishes from sibling tools 'get_scan' and 'scan_website' by positioning this as an intelligence/overview tool rather than a scanning operation.

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 temporal guidance ('Call this at the start of any SEO session') indicating when to invoke the tool. However, it does not explicitly mention when NOT to use it or directly contrast with sibling alternatives like 'get_scan' for specific scan retrieval.

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?

Discloses output format ('structured issues with LLM-ready fix instructions') compensating for missing output schema, but omits execution time, async behavior, or side effects.

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

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

Two sentences, front-loaded with action, no redundancy—every clause delivers essential 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?

Adequately covers functionality and return values for a single-parameter tool despite lacking formal 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?

Description adds no parameter details, but schema has 100% coverage with clear descriptions, meeting baseline expectations.

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 specific action ('Scan') and target resource with four distinct issue categories, though lacks explicit differentiation from sibling 'get_scan'.

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?

No guidance on when to use this versus the sibling 'get_scan' tool or workflow sequence (initiate vs retrieve).

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