crawl_website

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

With no annotations provided, the description carries the behavioral burden. It is reasonably transparent that crawling is a read-only data collection operation and mentions delayMs/concurrency to signal server-impact awareness. However, it does not disclose how long a crawl may take, whether large sites may be rate-limited or blocked, whether results are stored or returned directly, or what happens if the site is unreachable. For a potentially long-running crawl tool, more behavioral context would be valuable.

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 a single dense sentence that front-loads the main verb and target, then packs the full deliverable list. It earns its place without fluff. It is slightly long but justified by the breadth of data points collected; no redundant or filler wording is present.

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 crawl tool with 9 parameters and no output schema or annotations, the description does not fully specify the return format, report size limits, runtime expectations, or failure modes. The parameter list is fully documented in the schema, but an agent is left uncertain about how results are delivered (e.g., raw JSON vs stored report vs file). The presence of sibling export_crawl_report suggests results may be later exported, which is useful context the description does not connect.

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 every parameter's meaning, type, and default. The description adds a high-level list of the data points collected but does not map those data points to specific parameters or explain interplay between parameters (e.g., mode vs sitemapUrl, maxDepth vs maxPages). Baseline 3 is appropriate because the schema does the heavy lifting and the description adds only modest conceptual value.

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 precise verb ('Crawl') and a concrete resource ('website'), and enumerates the exact data points collected: URL, Title, H1-H4, Meta robots, Canonical, Word count, Inlinks/Outlinks, Anchor texts, Bold keywords. It is immediately distinguishable from sibling tools (e.g., audit_seo_issues, analyze_site_structure, classify_content_topics) which address different post-crawl analyses rather than raw crawling.

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 the starting point for gathering on-page data, and the parameter enums ('full', 'sitemap', 'fast') give hints about modes of use. However, it does not explicitly state when to prefer this over sibling tools such as analyze_site_structure or classify_content_topics, nor does it provide exclusions or alternatives. The usage context is derivable but not explicitly guided.

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