seo_link_check

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

No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions it's a read/crawl operation (non-destructive), tests links concurrently, and defaults to 50 links. While the concurrent behavior and default limit are helpful, it doesn't disclose whether external links are followed, whether redirects are followed or reported, or how long a crawl might take — significant gaps for a network-bound tool with no annotation coverage.

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 filler. Every clause adds information: crawl behavior, three specific checks (broken, redirects, anchor text), default limit, and concurrency. This is a model of efficient description writing.

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 performs network crawling with concurrency but has no output schema and no annotations, placing a heavy burden on the description. It explains what is checked (broken, redirects, anchor text) and the concurrency/default limit, but omits return format, which checks are exhaustive versus sample-based, and implications of the 50-link limit (e.g., are only the first 50 checked?). For a tool that could produce varied outputs, more completeness would help—yet the description is reasonably solid for the parameter complexity.

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 schema already documents both parameters (url and max_links). The description adds the '50 links by default' detail beyond the schema, and mentions redirects/broken/missing-anchor as check dimensions. However, it doesn't clarify how max_links relates to total discovered links vs. tested links, or what format the URL must take. Baseline 3 is appropriate when schema carries the load with modest description additions.

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: 'Crawl a page and check all links for broken URLs, redirects, and missing anchor text.' This precisely distinguishes it from siblings (seo_meta_analyze, seo_keyword_density, etc.) which handle different SEO aspects. The specific link-checking scope is unambiguous and well-differentiated.

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 implies the tool is for SEO link auditing but doesn't explicitly state when to use it versus alternatives. It does add some context about the 50-link default and concurrent requests, which hints at scale considerations, but there's no exclusions and the sibling tools are not compared. For an SEO tool suite, some guidance on when link-checking is appropriate would help.

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