Agent Ready by WorkPods (hosted)

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

Adds substantial context beyond the readOnly/openWorld annotations: the checks are deterministic, involve no AI model, no account, and pages are fetched by Agent Ready by WorkPods. It discloses retention (reportUrl kept 30 days, null for tools that keep none), error format (one plain sentence), and exactly what is recorded (domain and path, never query string, IP or page text).

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?

Front-loaded with the core question and the use-case trigger, then evidence sources, then caveats and return shape. It is dense but nearly every clause carries information; the verdict enumeration and privacy/recording tail make it longer than strictly needed for tool selection.

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?

No output schema exists, and the description compensates fully by describing the return shape (summary, reportUrl, result with per-bot verdicts and robotsTxtAllows/pageDirectives) and the error format. Combined with the rich annotations, an agent has everything needed to call this correctly and set expectations for the person.

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 baseline is 3, but the description clarifies scope that the schema does not: it is one URL at a time, and the bot token may name specific crawlers whose robots.txt rules are honored ('including ones naming the crawler'). The per-bot behavior is further implied by result.bots listing each crawler.

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 precise verb and resource: 'Answers whether AI crawlers may read one URL.' It also names the exact evidence sources (robots.txt, robots meta tags, X-Robots-Tag, HTTP status), which separates it from siblings like check_page or check_site_files that operate on pages or whole sites.

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?

Gives a concrete trigger ('Use it when the person asks whether ChatGPT, Claude, Perplexity or Google can see a page') and clear exclusions (firewalls blocking by user agent or IP, rankings, keyword volumes, backlinks, brand mentions in AI answers). It stops short of naming a specific sibling tool to use instead for those out-of-scope questions, which keeps it below a 5.

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

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

Beyond the readOnlyHint/openWorldHint annotations, the description discloses that checks are deterministic, fetched from public pages, use no AI model and require no account, that registry lookups are cached 6 hours, that reportUrl is retained 30 days and may be null, that errors return as one plain sentence, and that only domain/path (never query string) is recorded with no IP or page text. This is unusually rich operational and privacy context that annotations alone could not convey.

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?

Purpose is front-loaded in the first clause and every sentence carries non-redundant information about checks, output shape, retention, limits, and privacy. The cost is a dense single block with long compound clauses (the result/field enumeration is especially heavy), which slightly hurts scannability for an agent parsing it quickly.

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 no output schema, the description carries the full burden and does so: it names the top-level JSON fields (summary, reportUrl, result), explains the checks/webMcpTools/markdownVersion/agentFiles/mcpRegistry structure including null-vs-empty-list semantics, and covers error format and caching. Nothing an agent needs to call this single-parameter tool correctly appears to be missing.

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% and the single url parameter is well documented in the schema, so the baseline would be 3. The description adds genuine meaning by noting that the checks extend to 'a page and its site' (the domain is inspected too) and that the query string is never part of the recorded/checked identifier, which is not stated in the schema.

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 gives a specific verb (checks) and resource (whether AI agents can use a page and its site) and enumerates the concrete dimensions: labelled forms and buttons, declared WebMCP tools, a Markdown version, agent files and MCP server cards under /.well-known, and MCP Registry listings. That scope is distinctive enough to separate it from most siblings, but overlapping tools such as can_ai_fetch, check_site_files and check_page are never named, so the boundary is inferred rather than stated.

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?

It gives a clear trigger: 'Use it when the person asks whether agents can complete tasks on the site or find its MCP server.' It also lists out-of-scope areas (rankings, keyword volumes, backlinks, how AI answers mention the brand), which helps prevent mis-selection. It stops short of explicitly routing to alternative tools for narrower checks like fetching or site-file inspection.

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

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

Beyond the readOnly/openWorld annotations, it discloses that checks are deterministic, fetch public pages only, use no AI model and need no account, and that errors come back as one plain sentence. It also names exactly what is recorded (domain and path, never query string or IP) and that the report URL is kept for 30 days, which is real operational context an agent cannot infer.

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 purpose and scope lead, followed by output shape, exclusions and data handling in a logical order. It is dense and some clauses run together (the NAP/result sentence is long), but almost every sentence carries information an agent would otherwise lack.

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?

There is no output schema, so the description carries the return contract itself: summary, reportUrl with retention, and the full result structure including null semantics for localSchema. Combined with the error format and recording disclosure, nothing essential for calling or interpreting the tool is missing.

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% and the schema already explains that phone and address default to none and are left unchecked, so the description adds little on inputs. Its detail about status values (match, mismatch, not_found, profile_missing) describes outputs rather than parameters, so the baseline 3 holds.

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 names a specific verb and resource set: it checks whether a business page states name, address and phone (NAP consistency) plus LocalBusiness schema, tel links and an embedded map. That is concrete enough to separate it from siblings like check_page or check_agent_readiness without opening either schema.

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?

It gives a clear usage context ("local SEO questions about a shop, clinic, restaurant or office's website") and explicit exclusions: it does not read the Google Business Profile and does not cover rankings, keyword volumes, backlinks or AI-answer mentions. What's missing is routing to a specific sibling for those excluded cases.

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

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

Beyond the readOnly/openWorld annotations it discloses a great deal: results are cached 15 minutes, the checks are deterministic with no AI model and no account, pages are public and fetched by Agent Ready by WorkPods, errors return as one plain sentence, and the reportUrl persists 30 days. It also states exactly what is recorded (domain and path, never query string, tool, failed checks, app name; never IP or page text), which is the kind of behavior an agent cannot infer from annotations.

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?

Purpose and when-to-use are front-loaded, and every block (layers, scope exclusions, return shape, privacy) carries information the agent would otherwise have to guess. It is still one dense run-on paragraph with a mid-sentence pivot into return fields, which makes it harder to scan than it needs to be.

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?

There is no output schema, so the description takes on the full burden and meets it: it documents the return shape (summary, reportUrl, result with url, status, per-layer scores, problems, passed, notApplicable), the error format, cache lifetime and the data recorded. For a two-parameter read-only tool this leaves nothing an agent needs in order to call it correctly.

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%, and both parameters are already documented with examples, so the schema carries the semantics. The description adds only an indirect hint that a page may redirect ('url (where the page landed)') and otherwise adds no new meaning about how brandName changes the run. Baseline 3 is appropriate.

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 gives a specific verb and resource ('Checks one web page') and then enumerates the exact layers inspected: indexing status, robots, canonical, title, meta description, headings, copy, JSON-LD, links, alt text and AI readiness. The phrase 'one web page' plus the explicit note that rankings, keyword volumes and backlinks are out of scope separates it cleanly from siblings like compare_pages, check_site_files and start_site_crawl.

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?

It states the triggering situation clearly ('Use it when the person asks how a page does in search or AI answers, or what to fix on it') and draws useful scope boundaries by naming what it does not cover. It never names an alternative tool for the adjacent cases (multi-page comparison, site-level crawl, crawler policy), so routing between siblings is left to inference rather than made explicit.

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

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

Beyond the annotations (readOnly, openWorld, non-destructive), it discloses that results are cached for 1 hour, that the checks are deterministic with no AI model and no account, that null status means the site gave no answer, that errors come back as one plain sentence, and that reports are retained 30 days. It also states the privacy/recording model (domain and path recorded, never query string, IP or page text), which is exactly the kind of context annotations cannot carry.

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 capability is front-loaded in the first sentence and the exclusion list follows logically, with no filler or marketing language. It is dense and long, however, and the result-shape information is split between the inline '(url, status, contentSignals)' style listing and the later 'Returns JSON: summary..., reportUrl... and result' sentence, which creates mild redundancy.

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?

There is no output schema, so the description correctly carries the return shape itself, naming the result keys (robotsTxt, aiCrawlers, sitemaps, agentFiles, markdownVersion, findings), the agentFiles outcome enum, and the top-level summary and reportUrl. Caching, error format, and data-retention notes round out everything an agent needs to call it and interpret the answer.

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 baseline is 3, and the description earns an increment with 'Only the origin of the URL is used' — telling the agent that the path in the input does not affect the fetch, a behavior the schema does not convey. The later note that the path is recorded but the query string is not reinforces this, though the interaction between those two statements takes a careful read.

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 opens with a specific verb and resource: 'Reads a site's own files', then enumerates exactly which files (robots.txt, Content-Signal lines, sitemaps, llms.txt, /.well-known agent files, Markdown home page). It also draws a boundary against unrelated capabilities (rankings, keyword volumes, backlinks, AI answer mentions), though it never names a sibling tool it might be confused with, which keeps it at 4 rather than 5.

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?

'Use it to see whether AI crawlers may read the site and what it offers agents' gives a clear task-level context, and the exclusion sentence tells the agent what this tool will not answer. What is missing is an explicit routing statement — siblings like can_ai_fetch and check_agent_readiness overlap conceptually, and the description does not say when to prefer them.

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

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

Goes well beyond the readOnly/openWorld annotations: discloses that checks are deterministic with no AI model and no account, defines the result shape (mine/theirs with status, scores, problem count, word count, headings, schema types, plus differences), gives report retention (30 days), error format (one plain sentence), and precisely what is logged versus never logged (no IP, no page text).

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?

Purpose and trigger are front-loaded, then output shape, then coverage limits, then privacy. Every sentence carries information, though the final 'Recorded:' clause is dense and slightly legalistic for its place in a tool description.

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 no output schema, the description supplies the full return contract (summary, reportUrl, result with mine/theirs and differences) and error behavior, plus the verification provenance and limits an agent needs to set expectations when answering a user.

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% and both parameters already specify absolute http/https URLs with examples. The description only reinforces the mine-versus-theirs framing and the 'same search or task' matching constraint, which the schema already states, so it adds little new meaning.

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 specific verb and resource ('Runs the check_page checks on the person's page and a competitor's page') plus the output scope ('lists the checks where they differ'), which cleanly separates it from the sibling check_page that audits a single page.

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?

Gives an explicit trigger ('Use it when the person asks why a competitor shows up in search or AI answers and they do not') and delineates out-of-scope questions (rankings, keyword volumes, backlinks, brand mentions). It does not explicitly say 'use check_page instead when you only have one URL', so a small amount of routing is left implicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered; 'It fetches nothing' is consistent with that rather than new information. What the description does add beyond annotations is real but secondary: the 30-day report retention (with null when none is kept), the one-sentence error format, and the fact that unrecognised override tokens surface in unknownOverrides. Useful behavioral context, though the description never says what happens to overrides that reference a crawler outside the three roles.

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?

Front-loaded with what is produced and from what input, then usage, then return shape — a sensible order. Slightly dense: the final sentence reads as a comma-chained list of return fields and the 'kept 30 days; null for tools that keep none' aside adds parenthetical clutter, but no sentence is wasteful.

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?

There is no output schema, and the description compensates fully by enumerating every result field (robotsTxt, contentSignal, decisions, unknownOverrides) plus the top-level summary and reportUrl, and by stating how errors are returned. For a drafting tool with four optional parameters and nested overrides, an agent has everything it needs to call it and interpret the response.

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% and each parameter already names its enum values, the concrete crawler tokens in each role, and the defaults, so the description adds little beyond restating that roles are allowed-or-blocked and that overrides win over role choices — which the schema's own 'overrides' description already states. Baseline 3 is appropriate when the schema does the heavy lifting.

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 specific verb and artifact ('Drafts robots.txt groups ... and a Content-Signal line') plus the input concept it works from, and implicitly distinguishes itself from the fetching siblings ('It fetches nothing'). The three crawler roles are enumerated, so an agent knows exactly what class of output this produces versus draft_llms_txt or draft_json_ld.

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?

Gives an explicit trigger and prerequisite: 'Use it after check_site_files or can_ai_fetch shows crawlers blocked or allowed against the owner's wishes.' It names the alternative tools by name and the condition that selects this one, leaving little to infer.

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

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

Goes well beyond the annotations by disclosing precedence rules ('Values the person gives win over values read from the page'), the heading-with-question-mark extraction rule for FAQPage, that reportUrl is kept 30 days and may be null, and exactly what is recorded versus never recorded (no IP, no page text). Annotation-consistent and unusually forthcoming on privacy and side effects.

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?

Front-loaded with purpose and usage, and each clause carries information, but the single dense paragraph bundles purpose, precedence, return shape, error behavior and data-recording policy into one block that is harder to scan than it needs to be.

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 no output schema, the description supplies the return shape (jsonLd, scriptTag, filledFrom, missing, existingTypes, plus summary and reportUrl) and error format, which is what an agent needs. Slightly compressed, but complete enough to call the tool correctly.

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 most parameter meaning is already carried by the schema. The description adds some value by stating the generic precedence rule and how page-derived defaults are sourced, but it does not explain individual parameters beyond that.

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 specific verb and resource ('Drafts schema.org JSON-LD for a page') and enumerates the four supported types (Organization, WebSite, FAQPage, LocalBusiness), so an agent knows exactly what comes out of the call. It is distinguishable from siblings like check_page and draft_llms_txt, which address different artifacts.

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?

Explicit trigger given: 'Use it when check_page reports missing or incomplete structured data,' which ties it directly to a sibling tool's output. It does not state when *not* to use it (e.g. when the page already declares complete markup), which keeps it just short of a 5.

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

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

Annotations already declare readOnlyHint, openWorldHint and destructiveHint=false, so the safety profile is covered; the description adds substantial context beyond them. It discloses the reporting side effects (shareable reportUrl retained 30 days, null for tools that keep none), the error format (one plain sentence), and an explicit data-recording boundary (domain and path only, never query string, IP, or page text). Those are exactly the details an agent cannot get from annotations.

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?

Purpose and trigger are front-loaded in the first two sentences, with return shape and recording policy following. It is dense rather than padded, but the return-shape sentence ('result has llmsTxt..., saveAs..., links, sitemapUrls and existingLlmsTxt') and the 'details below' phrasing overlap slightly with the JSON return sentence.

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?

There is no output schema, so the description carries the full burden of explaining returns, and it does: both the top-level envelope (summary, reportUrl, result) and the result fields are enumerated, including what existingLlmsTxt means. Combined with the usage condition and edit-before-publish caveat, an agent has everything needed to call this and interpret the response.

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% and both parameters are documented there, including the origin-only behavior of url and the 5-50 range of maxLinks, so the baseline is 3. The description reinforces that content comes 'from its home page and sitemap' and that links are grouped by section, but adds no format or edge-case detail beyond the schema.

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 specific verb (drafts) and resource (a starter llms.txt) and immediately spells out what the artifact contains: an H1 site name, description as summary, and main pages grouped by section. That resource-level specificity separates it from siblings like draft_json_ld and draft_ai_crawler_policy without needing to name them.

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?

Gives an explicit triggering condition: 'Use it when the site has no llms.txt or a broken one,' which is actionable and non-obvious. It also warns that the person should edit the result before publishing. It stops short of naming alternatives such as check_site_files (for diagnosing an existing file) or draft_ai_crawler_policy, so the selection boundary is inferred rather than stated.

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

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

Annotations only say read-only and non-destructive; the description goes far past that by disclosing the status state machine (queued/running/done/failed), the polling interval, the 10-pages-per-call page size, the reportUrl retention of 30 days, error shapes for failed crawls, and that an unknown or expired job id is an error.

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 purpose is front-loaded and no sentence is filler, but the middle is a dense multi-clause run-on about status, paging and errors that takes a second pass to parse. Tightening the paging clause would cost nothing in completeness.

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?

There is no output schema, and the description compensates fully by describing the return envelope (summary, reportUrl, result), what result contains at each stage, and how errors are surfaced. Nothing needed to call it correctly is missing.

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 baseline is 3, but the description adds real semantics the schema lacks: cursor comes from nextCursor, advances the page window by 10, and its null counterpart signals the last page. That is the meaning of the field, not just its type.

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 opens with a specific verb and resource ('Reads a crawl started by start_site_crawl'), which immediately ties it to the sibling that creates the job and marks it as the retrieval half of a two-tool pair.

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?

It gives explicit polling guidance ('call again in 20 to 30 seconds'), explicit pagination guidance ('pass nextCursor back as cursor for the next 10'), and the termination condition ('nextCursor is null on the last page'). The reader knows both when to call and how to keep calling.

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

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

Beyond the annotations, it discloses that WorkPods staff manually review the request, email the report within 3 working days, and that there is no charge. It also states the result fields and clarifies that the email goes to WorkPods and is not stored by this service.

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 front-loaded with the purpose, then usage condition, then operational details and result shape. Every sentence carries useful information, with no repeated or filler wording.

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?

Although there is no output schema, the description explains the result fields, the turnaround time, the no-charge policy, the privacy handling, and the user prerequisite. That is complete enough for an agent to decide and invoke the tool correctly.

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%, and the schema already describes both parameters as the person's own work email and the site to audit. The description reinforces the "own work email" condition but adds no syntax, format, or validation detail beyond the schema.

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 uses a specific verb and resource: "Files a request for a full WorkPods audit of a site." It then details what that audit covers, including AI answer mentions, competitors, search rankings, and a prioritised fix list, which clearly distinguishes it from sibling check/crawl/draft tools.

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?

It gives explicit when-to-use and when-not-to-use guidance: only when the person asks for it and provides their own work email. It does not name a specific sibling alternative, so it falls short of the top score, but the practical trigger is unambiguous.

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

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

Goes well beyond the readOnly/openWorld annotations: async background execution returning jobId immediately, robots.txt compliance and inter-page pausing, minutes-scale latency for 50 pages, 24-hour result retention, and explicit exclusion of rankings, keyword volumes, backlinks and AI answer mentions. It also discloses what is logged (domain and path, never query string, IP or page text), which is material for an agent handling user URLs.

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?

Front-loaded with the action and scope, then the polling contract, latency, retention and exclusions in a sensible order with no filler sentences. It runs long and the privacy/logging sentence is dense, but every clause carries decision-relevant information.

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 an async job tool with no output schema, the definition supplies the return contract (jobId), the polling cadence and terminal status, expected duration, retention window, and explicit out-of-scope checks. An agent can start the job, track it, and set user expectations without any further reference.

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 baseline is 3; the description adds meaning by stressing "one site" and "up to 50 pages", which clarifies that pinned URLs must stay on the same domain and bounds the limit parameter. No further detail on url syntax is offered, but the schema already covers formats and ranges.

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 specific verb and resource ("Starts a crawl of up to 50 pages of one site") and enumerates the exact problem classes it surfaces (broken links, duplicate titles, orphan pages, soft 404s). The phrase "the problems one page cannot show" implicitly carves it away from the single-page sibling check_page.

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?

Gives a clear activation condition ("Use it when the person wants the whole site checked") and a concrete follow-up loop: call get_site_crawl with the returned jobId every 20-30 seconds until status is done. It does not name check_page or request_full_audit as explicit alternatives, so the boundary with those siblings is inferred rather than stated.

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