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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the prioritization logic (recurrence-review > critical > warning > info; newest within a tier), output format (markdown for copy-pasting), fallback behavior (returns next scheduled scan time), and authentication requirement (API key). It does not mention rate limits, error handling, or response structure details, but covers essential operational context.

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, followed by prioritization, output format, fallback behavior, and authentication in efficient sentences. Every sentence adds value without redundancy, making it highly concise and well-structured for quick comprehension.

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 no annotations and no output schema, the description does a good job covering the tool's behavior, output format, and authentication. It explains what is returned in both pending and non-pending cases. However, it lacks details on error scenarios or the exact structure of the markdown output, leaving some gaps for a tool with no structured output documentation.

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 schema already documents both parameters (apiKey and domain). The description adds marginal value by reiterating the API key requirement and its source URL, but does not provide additional semantics beyond what the schema states. The baseline score of 3 is appropriate as the schema does the heavy lifting.

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: 'Get the single most actionable SEO todo for the user's site.' It specifies the verb ('Get'), resource ('SEO todo'), and scope ('single most actionable'), distinguishing it from siblings like 'get_scan' (likely returns scan results) and 'scan_website' (likely initiates a scan). The prioritization logic further clarifies what 'most actionable' means.

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 for when to use this tool: to fetch the next SEO task, with fallback behavior when nothing is pending. However, it does not explicitly state when NOT to use it or name alternatives among sibling tools (e.g., 'get_scan' for raw scan data). The guidance is practical but lacks explicit exclusions.

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.