pull_ai_crawler_watchGiven a watchId from watch_ai_crawler_access, returns the URLs whose access changed since your last pull (started refusing, a tollgate appeared, a price moved) and nothing for those unchanged. The first pull reports the starting state. Each pull spends one credit whether or not anything changed.
| Name | Required | Description | Default |
|---|---|---|---|
| watchId | Yes | The watchId returned by watch_ai_crawler_access. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Reveals non-obvious behavior beyond annotations: each call consumes one credit even if nothing changed, responses are deltas relative to the caller's last pull, and the first pull returns the starting state rather than changes. This aligns with idempotentHint=false and explains why repeated calls are not equivalent.
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?
Three sentences, front-loaded with the core return behavior before the credit and baseline details. The parenthetical examples of changes are illustrative but compact; there is no filler or restatement.
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?
Despite having no output schema, the description explains what the tool returns (changed URLs, nothing for unchanged), how it behaves on the first pull, and the cost model. For a single-parameter stateful polling tool, this is sufficient context for an agent to invoke it correctly; minor unspecified details like error handling or response serialization are not essential.
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?
Only one parameter and schema coverage is 100%, so the schema already fully documents watchId as returned by watch_ai_crawler_access. The description adds usage context about the pull/cursor relationship but no additional parameter-level detail, so the baseline 3 applies.
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?
Clearly identifies the tool as a stateful pull operation: it returns URLs whose access changed since the last pull, given a watchId from watch_ai_crawler_access, and explicitly says unchanged URLs yield nothing. This distinguishes it from the watch-creation sibling (watch_ai_crawler_access) and from check/verify tools by focusing on deltas.
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?
Usage context is clear: this is the pull/consume counterpart to watch_ai_crawler_access, and the first-pull sentence tells the agent what to expect on initial use. It does not explicitly compare against alternative siblings such as check_ai_crawler_access or verify_ai_crawler, so it stops short of full when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools map cleanly to a distinct action and resource: single-URL lookup, batch triage, watch/pull lifecycle, and the entity-name operations are each clearly separated. The only likely confusion is between check_ai_crawler_access and verify_ai_crawler, but the descriptions draw that boundary well.
Tool names overwhelmingly follow a verb_noun convention such as calculate_gst, verify_email_address, and normalise_entity_name. The non-verb award_pay_rate and the slightly awkward total_invoice and pull_ai_crawler_watch are minor deviations from an otherwise consistent pattern.
Fourteen tools sits comfortably in the well-scoped range, and each cluster earns its place: entity matching, Australian compliance, email verification, and AI crawler access all have distinct tool groupings. Nothing feels redundant, and the count reflects the server's broad verification purpose without bloat.
The surface covers the core verification workflows well, including batch and watch variants for crawler access and a full set of entity-name operations. The main gap is that the server name promises routing but the tools mostly verify and triage rather than actively route; minor lifecycle niceties like unwatching are also absent.