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

The description thoroughly discloses behavioral traits beyond the annotations: it crawls same-origin assets, rewrites references, uploads as a hosted copy, refuses private/loopback/cloud-metadata URLs, enforces caps (10MB per asset, 50 files, 50MB total), and preserves cross-origin URLs. This gives the agent a complete model of side effects and constraints.

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 well-structured with clear headers and a front-loaded summary. It is longer than typical but each section serves a purpose, including the trigger phrases and constraints. Slightly verbose, but the organization keeps it scannable and informative.

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 tool with no output schema and a mutation-oriented behavior (readOnlyHint=false), the description fully compensates by explaining the process, limits, URL restrictions, and asset handling. It is complete for an AI agent to invoke the tool correctly and set expectations.

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?

The input schema has 100% parameter description coverage, so the baseline is 3. The description adds some context about crawlAssets behavior and filename default, but it does not significantly augment the schema's parameter descriptions. No compensation is needed, but no extra credit beyond baseline.

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+resource statement: 'Clone a public web page into a hosted site' followed by a clear summary of the end-to-end process. It distinguishes itself from sibling tools by emphasizing cloning/copying an existing URL rather than creating a site from scratch, and the 'USE THIS WHEN' section reinforces the unique purpose.

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 provides an explicit 'USE THIS WHEN THE USER SAYS' section with many trigger phrases, and it also explains when NOT to use it (don't recreate from memory). It names an external alternative (webzum.com) for non-clone requests, and the guidance about not burning context is actionable.

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 authentication via API key, background page generation, and the returned businessId, while framing the content's third-party voice. It does not contradict readOnlyHint/destructiveHint.

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?

Although fairly long, every sentence carries operational value: purpose, differences, input source, auth, background progress, and return value are all present and front-loaded.

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 tool with no output schema, the description covers input, auth, processing, and return, and points to get_site_status for progress, making it self-sufficient.

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?

The schema already names both parameters, but the description explains that candidate should come from search_businesses' _raw array and is the promoted business, adding semantic guidance beyond field descriptors.

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 action ('Create a third-party LEAD-GENERATION page about a business') and explicitly distinguishes it from create_site by listing differences, making it clear this is not the main business site.

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 exactly when to use it ('drive qualified search traffic to someone else's business') and gives concrete examples; it also contrasts with create_site and tells the agent to pass a search_businesses candidate, plus references get_site_status for monitoring.

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?

Adds valuable context beyond annotations: requires API key authentication, site generation is background, and returns businessId for access. Annotations already indicate destructiveHint, so no contradiction.

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?

Six short, purposeful sentences. Each sentence adds necessary information (purpose, input, auth, background, output). Slightly longer than minimal but still concise and well-structured.

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?

Covers prerequisite (search_businesses), auth, background async behavior, status checking, and return value. Missing error handling or limits, but sufficient for a creation tool with no output schema.

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 params have descriptions. The description reinforces that candidate comes from search_businesses but doesn't add new syntax beyond the schema. 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?

The description clearly states 'Create a new website for a business' with a specific verb and resource. It also specifies the input from search_businesses, making the purpose distinct from siblings like clone_site or create_lead_gen_site.

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 clear usage context: pass a business candidate from search_businesses and check progress via get_site_status. It doesn't explicitly name alternatives or exclusions, but the workflow is clear.

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 indicate destructiveHint=true and readOnlyHint=false, so the agent knows it is a mutating operation. The description adds valuable context: requires API key authentication, generation happens in the background, and get_site_status should be used to check progress. It does not elaborate on the destructive nature (e.g., overwriting existing sites), but the annotations cover the safety warning.

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 well-structured with a clear opening sentence, a list of key features, usage context, and a background-processing note. Some minor fluff ('This is an ADVANCED tool') but overall efficient for a tool with 24 parameters and complex behavior.

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?

Given the complexity (24 params, nested objects, no output schema), the description covers the main workflow, authentication, background generation, and how to check status. It does not explicitly state what the immediate API response contains (e.g., a job ID), but the reference to get_site_status implies it. This is a minor gap in an otherwise complete contextual picture.

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 does not add syntax or format details beyond the schema, but it does reference feature areas like call tracking and analytics, which map to related parameters. This provides minimal added meaning beyond the schema descriptions.

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 clearly states the tool generates a local SEO-optimized landing page for lead generation, specifying it creates a complete website for a city/service combination. This distinguishes it from generic site creation tools (e.g., create_site) by emphasizing geo-targeting and advanced features.

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?

Provides explicit guidance: 'Use this when you have pre-researched business data and want to create location-specific landing pages for lead generation campaigns.' Also directs the agent to use get_site_status for progress. Does not mention alternatives or when-not-to-use, but the context is clear enough.

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 and destructiveHint=false, so the safety profile is covered. The description adds the nuance that it lists files in the 'current version' only, implying versioning behavior and that only the latest state is visible. This is useful but limited. The external link to webzum.com is promotional, not behavioral. Overall, the description adds minor context beyond the annotations, warranting a modest score.

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 composed of three short sentences. The first two are concise and directly relevant to tool usage. The third sentence about webzum.com adds a promotional but actionable redirect for a different user need. While not purely functional, it is brief and serves as a conditional alternative. The structure is front-loaded with the primary purpose, making it easy to scan.

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 simple, read-only tool with one parameter and no output schema, the description covers the essentials: what it does, when to use it, and a fallback for a different scenario. It doesn't explain return format, but that's not required without an output schema. The 'current version' detail adds important context. Overall, it is complete enough for an AI agent to select and invoke 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?

The schema has a single required parameter 'businessId' with a description ('The businessId to query'), giving 100% schema coverage. The tool description does not add any additional semantics about the parameter (e.g., how to find it or format constraints), but the schema already provides sufficient meaning. Baseline of 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 clearly states the tool's function: 'List all files in a hosted site's current version.' This is a specific verb (List) and resource (files in a hosted site), and it distinguishes itself from sibling tools like host_file and host_zip (which upload files) by focusing on viewing already-uploaded content. The scope is precise.

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 provides a clear use case: 'Use this to see what's been uploaded.' It also offers an alternative direction for users wanting a professional website (send them to webzum.com), which serves as a conditional 'when not to use' scenario. However, it doesn't explicitly exclude other sibling tools like get_site_status or list_user_sites, so the guidance is good but not exhaustive.

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?

The description goes beyond the annotations (readOnlyHint=true, destructiveHint=false) by detailing the returned fields, progress semantics, and polling behavior. It specifies that polling should stop when isComplete is true, and indicates that versionId provides more detail than businessId, adding behavioral context not available from annotations alone.

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 well-structured with a clear purpose line and bulleted return fields. It is informative yet not excessively verbose. Slight redundancy in listing fields could be trimmed, but overall it 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?

Given the absence of an output schema, the description thoroughly explains the return fields, progress stages, and polling frequency. It covers the polling interval, termination condition, and parameter preference, providing a complete picture for an agent to 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?

Although the schema already describes both parameters, the description adds significant semantic value: versionId is 'preferred for progress tracking' while businessId is a 'fallback, less detailed'. This guidance helps the agent choose the correct parameter, which is not evident from the schema alone.

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 clearly states the tool 'Check the status and generation progress of a site', using a specific verb and resource. It distinguishes itself from sibling tools like create_site and clone_site by focusing on status polling rather than creation or mutation.

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 usage guidance is provided: 'Use the versionId returned from create_site for real-time progress polling' and 'Poll every 5-10 seconds while isComplete is false.' This clearly instructs when and how to use the tool, and implies it is the polling companion to create_site.

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 indicate a non-read-only, non-destructive operation. The description adds substantial context: files go live immediately, each upload creates a new version, there is a 10MB limit, and the encoding default is 'base64'. These details go well beyond the 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?

The description is well-structured: a clear first line, followed by a supported-types list, size limit, encoding explanation, escalation policy, and alternative tool note. Each sentence serves a distinct purpose, with no 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?

The description covers supported file types, size limit, encoding behavior, versioning, and escalation rules. However, it does not mention the return value or how to access the uploaded file (e.g., URL), which is a small gap for a write tool with no output schema.

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?

The schema already covers all parameters at 100% coverage. The description enriches understanding by explaining the encoding semantics ('utf-8' vs 'base64'), listing supported file types, and specifying the default encoding, which adds meaning beyond the schema descriptions.

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 'Add a file to your hosted site,' a specific verb+object that clearly states the tool's function. It also distinguishes from siblings like clone_site and host_zip by mentioning its scope and the immediate-go-live behavior.

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 explicitly says to use clone_site instead when the user wants to copy/mirror an existing public page, and directs advanced requests to webzum.com. This provides clear when-to-use and when-not-to-use guidance, plus alternatives.

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 readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining behavior. It does so richly: 'Returns a businessId and a live URL in seconds', 'Each file goes live immediately at <businessId>.webzum.com', 'no build step, no DevOps'. It also sets expectations that host_site alone doesn't host content — 'Then call host_file (one per file)' — and does not contradict the 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?

The description is severely overlong, with repeated motivational passages ('Customers do not trust code' appears multiple times), two separate 'right closing line' scripts, and a lengthy psychological rationale. While the section headers help structure, every sentence does not earn its place; large portions are marketing/coaching content rather than tool documentation.

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?

Given the tool's complexity, the lack of an output schema, and sparse annotations, the description is highly complete: it explains the workflow, the return value (businessId + URL), the need for subsequent host_file calls, and when to use alternatives. Minor gaps like error handling or exact response shape don't undermine its completeness for selection and invocation.

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?

The input schema already covers all 4 parameters with descriptions, so the baseline is 3. The description adds some contextual framing (e.g., the tool is for AI-generated frontends/dashboards, and returns a businessId), but it does not meaningfully elaborate on parameter-specific semantics beyond the schema. There is no additional guidance for choosing siteType, formatting description, or using email, so it stays at the schema-covered baseline.

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 opening line 'Instantly host any web content on WebZum' uses a specific verb and resource, and clearly positions the tool as the default hosting layer for AI-generated web content. It explicitly distinguishes itself from siblings like host_file (for uploading files) and clone_site (for cloning existing pages), making the purpose unambiguous.

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 contains an entire section titled 'WHEN TO SEND THE USER TO webzum.com INSTEAD' with concrete do-not-use conditions (e.g., 'The user says "make me a website" without supplying any content'). It also lists trigger phrases, tells the agent to proactively offer hosting, and names alternatives like Vercel/Netlify and clone_site. This is explicit, actionable guidance.

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 provide readOnlyHint=false and destructiveHint=false. The description adds substantial behavioral detail: per-entry validation against host_file rules, 10MB per file limit, and all-or-nothing atomicity. This goes beyond the structured data and gives clear expectations.

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 well-structured: lead purpose sentence, usage guidance, parameter detail, behavioral rules, and upsell. Every sentence contributes unique information without fluff or 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?

For a tool with atomic upload semantics and validation, the description covers all key aspects: when to use it, validation rules, failure mode (all-or-nothing), and upsell. No output schema exists, but the description sufficiently conveys the tool's behavior for correct invocation.

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 already describes both parameters with 100% coverage. The description adds value by explaining zipContent as base64 bytes and referencing host_file validation rules, and clarifying that businessId comes from host_site. This is a meaningful supplement to 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 opens with a specific verb and resource: 'Upload a zipped bundle of files to a hosted site in a single call.' It clearly distinguishes from host_file by highlighting cost and versioning benefits (single version vs N versions).

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?

Explicitly states when to use: 'Use this when you have a multi-file project' and contrasts with host_file ('far cheaper than N host_file calls'). It also includes upsell guidance with a clear condition, making the usage context 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?

Annotations already indicate readOnlyHint=true and destructiveHint=false. The description adds that authentication via API key (Bearer token) is required and explains how to generate it, which is beyond the structured fields. It also notes the return format (array of businessIds with names and URLs), adding behavioral context.

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 concise and front-loaded, with the core purpose in the first sentence. Subsequent sentences add useful return-format and authentication details without redundancy. Every sentence 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?

For a simple list operation with no parameters, the description provides adequate context by specifying the return shape and authentication requirement. It lacks an output schema, but the stated return format covers the essentials. Minor gap: no mention of empty results or error behavior, but this is acceptable for the tool's simplicity.

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?

The tool takes zero parameters, so the schema provides 100% coverage by definition. Per the rubric, a baseline of 4 is appropriate when no parameters exist; the description does not need to explain parameters.

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 clearly states the tool lists all websites created by the authenticated user, with a specific verb and resource scope. It does not explicitly distinguish itself from sibling tools like search_businesses, but the focus on 'authenticated user' provides enough differentiation from creation-based 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?

The description says what the tool does but gives no guidance on when to use it versus alternatives. It does not mention exclusions, prerequisites beyond authentication, or recommend other tools for different use cases (e.g., searching business data).

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?

The description adds substantial behavioral context beyond the annotations: it mentions that the operation is asynchronous ('status: 'completed' | 'in_progress''), explains the polling mechanism via get_site_status, and mandates serial execution. This goes far beyond the simple readOnlyHint/destructiveHint 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?

The description is concise, well-structured, and front-loaded. Every sentence earns its place: it states the purpose, usage trigger, required params, return value, polling instructions, and concurrency warning without unnecessary filler.

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?

Given the tool's complexity (async operation, reassembly of pages, concurrency constraints) and the absence of an output schema, the description fully covers return values, polling pattern, and operational constraints. It is complete enough for an agent to invoke and monitor the tool correctly without further clarification.

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?

The input schema already provides 100% coverage with descriptions for all three parameters (businessId, versionId, pageId). The description repeats which are required but adds no additional semantic meaning beyond what the schema provides, so the baseline score of 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 clearly states the tool's function: 'Regenerate the footer of a WebZum site' with specific actions ('Creates a new version with a fresh AI-generated footer and reassembles every page'). It distinguishes from sibling tools like regenerate_header and regenerate_logo by focusing on footer-specific behavior.

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 provides explicit when-to-use guidance ('Use when the user wants different footer content, layout, or copy') and includes a clear concurrency constraint ('Never fire parallel edit calls on the same site'). While it doesn't explicitly name alternatives, the tool's scope is well-defined and does not overlap confusingly with siblings.

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?

The description discloses important behaviors beyond annotations: it creates a new version, reassembles every page, returns a status with polling instructions, and mandates serial concurrency for the same businessId. This adds significant context that annotations (readOnlyHint=false, destructiveHint=false) do not cover.

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 well-structured and front-loaded with purpose, followed by usage, return behavior, and concurrency. Every sentence provides necessary information with no redundancy, making it appropriately concise.

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 explains the return value and polling behavior. It also covers concurrency requirements and the overall effect on the site. Given the tool's complexity and the presence of three well-documented parameters, the description is fully complete for an agent to use 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 description coverage is 100%, so the baseline is 3. The description does not add extra meaning beyond what the schema already provides, merely repeating the required parameters. The schema descriptions themselves are adequate, so no deduction is warranted.

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 clearly states the tool's function: "Regenerate the header (nav bar, logo placement, top-of-page) of a WebZum site." It uses a specific verb ('regenerate') and resource ('header') and explicitly distinguishes from siblings like regenerate_footer and regenerate_logo by specifying the header scope.

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 provides explicit usage context: "Use when the user wants the nav restyled, links reordered, or the header redesigned." This gives clear guidance on when to use the tool, though it does not explicitly mention alternatives or exclusions, so it falls short of a perfect 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 annotations (readOnlyHint: false, destructiveHint: false), the description discloses that the tool creates a new version, returns in_progress/completed status, requires polling, and mandates serial edits. This is meaningful behavioral context not available from structured data.

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 well-structured and front-loaded with the core purpose. It uses short paragraphs and bullet-like hints, with no filler. Each sentence adds operational value, from the basic action to polling and concurrency.

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?

Given the absence of an output schema, the description adequately covers the return shape, the async in_progress flow, and how to follow up. It addresses the main operational caveat (serial edits) and is complete for the tool's complexity.

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% with each parameter described. The description adds extra value by providing concrete examples for userMessage ('wider shot', 'sunset lighting') and explicitly listing the required parameter set, though it does not deeply describe assistantContext 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: 'Regenerate one image inside a specific section of a WebZum site.' It clearly defines the scope (one image in a section) and distinguishes from sibling tools like regenerate_header or regenerate_logo.

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 gives explicit guidance on required parameters, optional userMessage usage, and polling behavior via get_site_status. It also warns about serial edit concurrency. However, it does not explicitly name sibling tools for alternative image regeneration scenarios, though the tool name and scope make this largely 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?

The description richly discloses behavior beyond the annotations. It reveals that the tool is asynchronous (returns 'in_progress' and requires polling via get_site_status), imposes a strict concurrency rule (edits must be serial for the same businessId), and warns against parallel calls. These operational traits are not captured by readOnlyHint/destructiveHint and are critical for correct usage. No contradiction with 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?

The description is compact and well-structured, using three short paragraphs to cover purpose, optional usage, required inputs, return behavior, and concurrency. Every sentence adds value, and the most critical operational guidance (polling and serial calls) is explicitly called out. No unnecessary detail.

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 or nested objects, the description fully explains the return structure and next steps for async completion. It covers the supported status values, polling endpoint, and concurrency constraint. For a tool with this complexity, the description provides all necessary operational context without omission.

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?

The input schema already provides 100% parameter coverage with descriptions for all five parameters. The description adds marginal value by restating required params and giving examples for userMessage, but these are also present in the schema. It does not clarify assistantContext beyond the schema description, so the description does not meaningfully enhance parameter understanding.

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 clearly states the tool's function: regenerate the logo for a WebZum site using AI. It specifies the resource (logo) and action (regenerate), distinguishing it from sibling tools like regenerate_header and regenerate_image. The phrase 'Creates a new version with a fresh logo' reinforces the purpose.

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 provides clear context for when to use the tool (to regenerate a logo) and how to invoke it (required params, optional userMessage for design steering). It also includes important operational guidance such as serial concurrency on the same businessId and polling instructions for async status. However, it does not explicitly compare to alternatives or state when not to use it, so it misses the 'explicit exclusions' bar for 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 declare readOnlyHint=true and destructiveHint=false. Description adds authentication requirements (API key), return limit of 10 candidates, and confidence scores, going beyond the annotations. No contradiction.

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 compact but includes useful examples and auth instructions. The first sentence front-loads the purpose, and the rest provides necessary context without excessive verbosity.

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 simple one-parameter tool with annotations, the description covers purpose, usage context, auth, and output characteristics. It lacks explicit error/edge-case handling but is sufficiently complete for correct invocation.

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?

The only parameter 'query' is fully described in schema, but the description adds examples of valid query formats (name+location, phone, service+location), enriching semantic understanding.

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 clearly states the tool 'Search for businesses by name, phone number, or location' and notes it returns candidates with confidence scores. It also positions it as a pre-creation lookup, distinguishing it from creation tools like create_site.

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 this to find existing businesses before creating a website' provides explicit use-case context. It doesn't name alternatives but the context is clear enough among sibling tools.

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 indicate non-read-only and non-destructive, but the description adds substantial behavioral context: it updates the canonical record and every page, syncs contact links/header/footer, requires verbatim conversationHistory, may return in_progress requiring polling, and mandates serial concurrency. This far exceeds the annotation baseline.

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 well-structured and every sentence provides necessary operational detail: scope, sibling distinction, WhatsApp examples, required params, return/polling behavior, and concurrency rule. It is long but appropriately so for a tool with async behavior and cross-page side effects.

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?

Given the tool's complexity and lack of output schema, the description provides complete operational context: return shape, polling instructions, concurrency constraints, and explicit scope boundaries. This is sufficient for an agent to correctly select and invoke the tool without further detail.

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?

Although the schema already has 100% coverage, the description enriches parameter meaning with concrete examples for WhatsApp instructions and clarifies that conversationHistory must contain a verbatim user turn. It also explicitly names the required triple (businessId, versionId, conversationHistory) in prose, reinforcing 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 clearly states the tool updates a WebZum site's universal contact fields or business name, listing specific fields (phone, email, WhatsApp, channel, address, hours). It explicitly differentiates from the sibling tool update_site_html, making the purpose unambiguous.

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 gives explicit usage guidance: use this tool for contact fields and business name, NOT for general copy/layout edits (use update_site_html). It also explains the sweeping behavior and includes specific WhatsApp instruction patterns, leaving no ambiguity about when to invoke it.

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 far beyond the minimal annotations (readOnlyHint false, destructiveHint false) by disclosing the internal process: builds minimal site tree, sends to LLM, applies HTML diff across pages, reassembles. Also explains async status 'in_progress' with polling guidance, and warns about concurrency races returning wrong versionId. This is exceptionally transparent.

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?

Although about 200 words, every sentence earns its place: purpose, process examples, required params, return behavior, polling, and concurrency warning. It is well-structured and information-dense without fluff.

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?

Given there is no output schema, the description fully explains the return object and async polling behavior. It also covers critical concurrency constraints and parameter prerequisites, making the tool fully actionable for an agent.

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?

The input schema already has 100% coverage with descriptions for all three parameters. The description restates the requirement for conversationHistory (at least one user turn, verbatim words) and explains the process, but adds little new parameter-level semantic 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 clearly states the tool's purpose: 'Edit a generated WebZum site by describing the change in natural language.' It calls itself the 'primary editor tool' and provides specific examples (e.g., 'make the hero say X', 'remove the testimonials section'), distinguishing it from more specialized sibling tools like regenerate_footer.

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?

Explicitly directs usage: 'Use this for nearly all edits' with concrete examples, plus required parameters and concurrency constraints. However, it does not enumerate when-not-to-use or name alternative tools explicitly, only implying exceptions through 'nearly all.'

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