proofpage_start_crawl

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

With no annotations present the description carries the full burden, and it does disclose meaningful behavior: this is a queued/async kickoff rather than a synchronous fetch, and the crawl is bounded to a source origin and path. It says nothing about required permissions, what happens on a duplicate/active crawl, or what the caller receives back (run handle, id), which are material gaps for a write-side kickoff tool.

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, and the scope statement is front-loaded before the workflow hint. 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?

Three required parameters with no schema descriptions, no annotations, and no output schema, yet the description says nothing about the parameters or the return value. For an all-required kickoff tool with zero structured documentation, this is under-specified.

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 0% across three required parameters, so the description must compensate and does not: source_id, max_pages and max_depth are never named or explained. "Bounded" faintly gestures at the page/depth caps but gives no meaning, units, or limits.

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?

States a concrete verb and resource ("Queue a bounded crawl") plus its scope ("within a configured source origin and path"), which is more than a restatement of the name. It implicitly distinguishes itself from the step_crawl sibling, though it doesn't differentiate from other crawl-adjacent siblings like collect or schedule_source.

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 second sentence explicitly routes the agent to proofpage_step_crawl for advancing the crawl without a web server, giving a real alternative and the condition for using it. It stops short of stating prerequisites or when not to start a crawl (e.g., one already running, missing source access).

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