check_linksCollect all links on a page and verify their HTTP status to report broken, unreachable, 4xx, or 5xx links so you can fix navigation and SEO issues.
Collect every link on a page and check each one's HTTP status. Reports broken (4xx/5xx/unreachable) links.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Page whose links should be checked | |
| max_links | No | Maximum number of links to check | |
| include_external | No | Also check links to other domains |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so the safety and external-network profile is covered. The description adds genuine value beyond that by defining what counts as broken (4xx/5xx/unreachable) and stating that every link is checked, which tells the agent to expect a full crawl of the page rather than a sample.
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, the core action first and the result definition second. There is no filler, and the reporting behavior is front-loaded rather than buried.
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 only three flat parameters, full schema coverage, and no output schema, the description is nearly sufficient: it says what is collected and what is reported. It stops short of describing truncation behavior when max_links is hit or how redirects and timeouts are classified, which matters for an open-world checker but is a minor gap.
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 url, max_links, and include_external are already fully documented in the schema. The description adds no extra meaning about how max_links truncation affects the reported results or what include_external changes about the output, leaving it at the baseline for schema-complete tools.
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 pairs a specific verb (collect and check HTTP status) with a specific resource (every link on a page) and states the output (broken 4xx/5xx/unreachable links). It is clearly distinct from a page audit in spirit, but it never names check_site_files, audit_site, or audit_page, so the differentiation from siblings is left implicit.
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?
"Collect every link on a page" implies the single-page scope, which is the main usage signal, but there is no explicit statement of when to prefer this over audit_page or check_site_files, and no prerequisites or exclusions. The agent must infer the boundary from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.