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

Annotations already indicate read-only/non-destructive behavior. The description adds valuable hierarchical navigation context: omitting menuUrl returns top-level categories while providing it drills into categories, and that URLs must be 'copy[ied] from previous responses' indicating stateful pagination behavior. It also lists concrete vertical examples showing the menu structure domain.

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 core tool description is well front-loaded and structured, but the inclusion of the extensive <agent-mandatory-instructions> XML block significantly increases length. While these workflow instructions may be necessary for agent operation, they reduce overall conciseness and contain information that might ideally reside in system prompts rather than tool descriptions.

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 hierarchical navigation tool with no output schema, the description adequately explains the interaction pattern (copying URLs from previous responses to drill down) and provides concrete input examples. It covers the discovery workflow comprehensively, though explicit mention of return value structure would strengthen it further.

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?

Input schema has 100% description coverage establishing a baseline of 3. The description adds significant value by providing concrete example URLs for 11 different Wix verticals (Stores, Bookings, CMS, etc.) which illustrates the expected URL patterns and domain structure beyond the generic 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 a specific verb and resource ('Browse the Wix REST API documentation menu hierarchy') and immediately distinguishes from sibling tool SearchWixRESTDocumentation by clarifying this is for 'navigating the menu structure instead of searching by keywords.' This provides exact scope and differentiation.

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 identifies the alternative tool (SearchWixRESTDocumentation) and provides clear when-to-use guidance: use this for 'explore and discover APIs by navigating' versus search for keywords. Also includes specific instructions on parameter omission versus inclusion for different navigation modes.

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 annotations (destructiveHint: true), the description adds critical behavioral context: specific error handling for 'WDE0110: Wix Code not enabled', allowed API URL domains, the requirement to never guess URLs or make up request bodies, and that app installation checks are unnecessary in advance. Does not describe response format, but this is less critical for a generic API proxy.

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 lengthy and includes some repetition (conversation context requirements appear multiple times), but it is well-structured with bold headers, bullet points, and clear sections. Given the tool's complexity and destructive capabilities, the verbosity is justified by the need for precise safety instructions, though it could be slightly tightened.

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 complex generic API tool with no output schema, the description is exceptionally complete: it covers error handling workflows, integration with the broader tool ecosystem (WixREADME, BrowseWixRESTDocsMenu), mandatory agent instructions, URL validation rules, and specific constraints for all 6 parameters.

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?

While the schema has 100% description coverage, the description adds crucial usage constraints and examples beyond the schema, such as specific JSON body formatting examples for POST/PATCH/PUT, emphasis that URLs must be absolute and never guessed, and that the sourceDocUrl must be validated against documentation.

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 explicitly states the tool performs CRUD operations ('create, read, update, and delete') on Wix entities and clearly distinguishes itself from siblings by directing users to 'Prefer using the ListWixSites tool' for site listing and 'ReadFullDocsArticle' for reading documentation URLs.

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 when-to-use/when-not-to-use guidance (prefer ListWixSites for simple listing), detailed prerequisites ('The API endpoint url param MUST ALWAYS be taken from the conversation context'), and comprehensive workflow descriptions (Recipe Based, Conversation Context Based, etc.) covering multiple execution paths.

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 establish readOnlyHint=true (safe read operation). The description adds valuable context about what documentation is returned (template selection, Editor vs Studio, API endpoints, post-creation steps) and clarifies the two-step workflow (documentation then action). Does not contradict 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?

Well-structured with markdown headers (When to Use, What This Tool Contains, Important Notes), but suffers from significant repetition in the 'Important Notes' section where the same warning about not using other tools is restated three times with slight variations. Could be more 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?

Since no output schema exists, the description appropriately lists the documentation contents (templates, editor options, API details, post-creation steps) and explains the relationship to sibling tools in the workflow. Minor gap: does not specify the return format (markdown vs structured data).

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?

Input schema contains 0 parameters (empty properties object). Per calibration rules, 0 params baseline is 4. No parameter explanation needed or provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it 'Provides comprehensive documentation for creating a new Wix Business' and explicitly distinguishes itself from siblings like WixREADME and SearchWixRESTDocumentation by stating they should NOT be used before this tool. Also clearly differentiates from ManageWixSite (which actually creates the site) by positioning itself as documentation-only.

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?

Contains explicit 'When to Use This Tool' section ('when the user requests to create a new Wix site'), clear exclusions ('Do NOT use WixREADME or SearchWixRESTDocumentation'), and named alternatives for the workflow ('After reading this documentation: 1. Use ManageWixSite to create the site'). Provides complete decision framework.

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 indicate destructiveHint=true, and the description confirms mutation with the hasMutations parameter. It also discloses that auth is handled automatically and warns against setting certain headers, adding behavioral context beyond 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 long but well-structured with sections, examples, and bullet points. While every sentence serves a purpose, it could be slightly more concise without losing clarity.

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 of a code-execution tool with multiple request methods and no output schema, the description comprehensively covers usage, error handling, pagination, and output formatting, leaving little ambiguity.

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%, but the description adds rich context for each parameter: code parameter includes full example blocks, reason explains its purpose, siteId details how to obtain it, and hasMutations clarifies the mutating nature. The examples illustrate usage patterns.

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: 'Execute JavaScript code against the Wix REST API.' It distinguishes this tool from its siblings (CallWixSiteAPI, ManageWixSite) by specifying when to use it: for tasks requiring loops, pagination, branching, or chaining.

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 guidance on when to use this tool vs. alternatives, including how to choose between siteRequest and accountRequest based on curl headers, and mentions the prerequisite of inspecting endpoint shape via REST documentation 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 indicate read-only, non-destructive, and closed-world behavior, which the description doesn't contradict. The description adds minimal context beyond annotations by specifying it's for 'suggested domain names,' but doesn't detail rate limits, authentication needs, or output format. With annotations covering safety, it meets baseline expectations without rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that directly states the tool's function without redundancy. It's front-loaded with the core purpose and appropriately sized, with no wasted words or unnecessary elaboration.

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 has annotations covering safety (read-only, non-destructive) and a simple input schema with full coverage, the description is minimally adequate. However, with no output schema, it doesn't explain return values like suggestion format or examples, leaving gaps in completeness for a tool that generates domain names.

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% with one parameter ('siteId'), so the schema fully documents it. The description adds no additional parameter details beyond implying the site name influences suggestions, but doesn't explain format or constraints. Baseline score of 3 is appropriate as the schema handles 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?

The description clearly states the action ('Get suggested domain names') and the resource ('for a Wix site based on the site name'). It specifies the verb and target, but doesn't differentiate from sibling tools like 'ManageWixSite' or 'ListWixSites' which might also involve domains. The purpose is clear but lacks sibling distinction.

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?

No guidance on when to use this tool versus alternatives is provided. The description implies usage when needing domain suggestions, but doesn't mention prerequisites, exclusions, or when to choose other tools like 'ManageWixSite' for domain management. It's a basic statement with no contextual advice.

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 read-only/non-destructive operations, but the description adds valuable behavioral context: it notes the tool 'returns all sites' by default, handles the 'correct API' internally, and manages everything needed for the operation. No contradictions 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?

While the first section is well-structured, the description is severely bloated by a massive XML-like block of 'agent-mandatory-instructions' (including flow descriptions and system guidelines) that constitutes the majority of the text. This content belongs in system prompts, not tool descriptions, creating significant noise.

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?

Adequate for a simple listing operation with good annotations, but lacks description of return values (what site properties are returned?) despite having no output schema. The filtering behavior and default scope are covered, making it minimally complete.

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?

With 100% schema description coverage ('optional filer by name'), the schema adequately documents the parameter. The description mentions 'you can filter by name' which aligns with but does not substantially augment the schema's explanation. Baseline 3 appropriate since schema carries the load.

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 explicitly states the tool 'lists Wix sites for the current user' with specific trigger verbs (list, show, get, find). It clearly distinguishes itself from siblings by stating it is the 'dedicated tool for listing' and explicitly contrasting with CallWixSiteAPI and WixREADME.

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 exceptional guidance with explicit 'Do NOT use WixREADME before this tool' and 'Prefer this tool over CallWixSiteAPI' instructions. It defines exact fallback conditions ('Only fall back to CallWixSiteAPI if...') and specifies when to skip documentation reading entirely.

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 annotations (destructiveHint: true), the description adds critical behavioral constraints: URLs must be sourced from conversation context (never guessed), and body parameters must never be fabricated but derived from documentation tools. These warnings about parameter sourcing add valuable safety 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 excessively verbose, embedding system-level agent instructions (XML-like tags for <goal>, <guidelines>, <flow-description>) that belong in the system prompt rather than tool description. The high signal-to-noise ratio makes it difficult to extract the core tool contract 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?

For a destructive 3-parameter tool without output schema, the description adequately covers input requirements and sourcing constraints. However, it omits any discussion of return values, error handling patterns, or idempotency considerations expected for site management operations.

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?

With 100% schema coverage, the baseline is 3. The description adds significant value by specifying that the URL must come from specific documentation tools (WixREADME, BrowseWixRESTDocsMenu, etc.), explaining body format with concrete JSON examples, and warning against stringified JSON—content not present in the raw 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 states the tool creates, updates, and publishes sites, but conflates this specific purpose with generic HTTP client capabilities (accepting any URL/method). It fails to clarify the scope relative to sibling tool CallWixSiteAPI, leaving ambiguity about which API caller to use for site management versus other operations.

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?

While the description provides extensive workflow instructions (when to use WixREADME, flow descriptions), it offers no explicit guidance on when to choose this tool over CallWixSiteAPI or other siblings. The 'agent-mandatory-instructions' focus on general agent behavior rather than tool selection criteria.

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, which the description confirms with 'Poll.' The description adds valuable behavioral context beyond annotations: it clarifies the tool works for 'editing' jobs as well as creation (resolving ambiguity in the tool name), and imposes the critical behavioral constraint requiring explicit user consent for polling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, zero waste. The first states purpose immediately; the second states the critical usage constraint. Information is front-loaded with no filler, qualifying as excellent technical writing for agent consumption.

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 low complexity (1 param), high schema coverage (100%), and safety annotations covering the read-only nature, the description provides adequate context. It appropriately clarifies scope (creation + editing). Minor gap: lacking description of return values/status formats since no output schema exists, though 'Poll the status' provides sufficient hint for basic usage.

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?

With 100% schema description coverage for the single 'jobId' parameter ('The job ID to pull'), the schema carries the semantic burden adequately. The description implies the jobId relates to creation/editing jobs but does not add syntax details, format requirements, or provenance guidance (e.g., where the jobId comes from) beyond the schema 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 clearly states the tool 'Poll the status of a site creation or editing job,' providing a specific verb and resource. It distinguishes from siblings like ManageWixSite or CallWixSiteAPI by specifying this is for asynchronous job status polling. However, it could explicitly mention this handles long-running/asynchronous operations to fully clarify the polling context.

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-not guidance: 'Do not call this tool unless the user explicitly asks for status polling.' This strong constraint prevents inappropriate auto-polling behavior and clearly defines the invocation condition, satisfying the requirement for explicit usage boundaries.

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. The description adds that the tool retrieves 'code examples' alongside articles, which hints at return content structure. However, it lacks disclosure of error behaviors (e.g., invalid URL handling), rate limits, caching policies, or content format (HTML vs Markdown). The extensive XML blocks describe agent workflow, not tool behavior.

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?

While the core description is concise (first two sentences), the majority of the text consists of extensive XML-tagged agent instructions (<agent-mandatory-instructions>, <flow-description>) that severely bloat the description. Despite being useful for agent routing, this structure sacrifices conciseness—the tool's actual behavioral description is less than 10% of the total text.

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 lacking an output schema, the description adequately compensates by specifying that the tool returns 'full' articles containing 'code examples,' giving the agent sufficient context to understand the return value's utility. Given the single parameter (100% documented) and clear read-only annotations, the description provides enough context for correct invocation, though it could specify the content format (JSON, HTML, etc.).

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?

With 100% schema description coverage for the single articleUrl parameter, the baseline is 3. The description mentions that 'Docs articles looks like this: https://dev.wix.com/docs/...' which reinforces the URL format expectation, but adds no additional validation rules, required prefixes, or semantic constraints beyond what the schema already provides.

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 'Fetches the full Wix docs article or method article with code examples,' providing specific verb (fetches), resource (docs articles), and scope (full content with code examples). The embedded flow instructions explicitly distinguish it from siblings like ReadFullDocsMethodSchema (used when no code examples found) and BrowseWixRESTDocsMenu (used for discovery).

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 <flow-description> and <guidelines> sections provide explicit when-to-use instructions across multiple scenarios (Recipe Based, Example Based, Schema Based Fallback), detailing exactly when to invoke this tool versus alternatives like ReadFullDocsMethodSchema, BrowseWixRESTDocsMenu, or WixREADME. It includes clear exception handling and decision trees.

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, establishing this is a safe read operation. The description adds value by disclosing what the return payload contains ('entire request/response schema'), but does not elaborate on rate limits, caching behavior, or error conditions beyond what the annotations imply.

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 bloated, mixing extensive XML agent-mandatory-instructions (goals, guidelines, flow descriptions) with the actual tool definition. While the first two sentences are appropriately front-loaded, the massive instruction block creates poor information architecture; operational workflows belong in system prompts, not tool descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description compensates by explaining the return value ('entire request/response schema'). Combined with 100% input parameter coverage and comprehensive workflow context explaining when/why to invoke the tool, it provides sufficient information for correct agent operation.

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?

With 100% schema description coverage, the baseline is 3. The schema fully documents both articleUrl (with format example) and reason (with usage rationale). The description provides workflow context that indirectly supports the 'reason' parameter's purpose, but adds no direct semantic information beyond the schema definitions.

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 first two sentences clearly state the tool 'Fetches the full method schema for a given method' and specify it returns 'the entire request/response schema with all the fields and their descriptions.' It distinguishes from sibling ReadFullDocsArticle within the flow description section (used when code examples aren't found), though this differentiation is buried in the XML instructions rather than in the opening definition.

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 workflow guidance under 'SCHEMA BASED, FALLBACK' and 'FULL SCHEMA BASED' sections, clearly stating when to use this tool versus ReadFullDocsArticle (used when 'no method code examples found'). It outlines the exact fallback position in the decision tree and contrasts with recipe-based and example-based approaches.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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 that the environment is read-only, consistent with annotations. It explains the code execution model, access to globals like lightIndex, and behavioral traits such as handling circular references. No contradictions 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 lengthy due to the tool's complexity, but it is well-structured with clear sections, examples, and front-loaded purpose. Every part adds value, though it could be slightly more concise without losing essential guidance.

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 is remarkably complete. It covers purpose, usage, globals, examples, warnings about URLs and circular refs, and explains return values through examples, leaving no significant gaps.

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 description adds extensive meaning beyond the input schema, detailing that `code` is an async function expression with access to specific globals, and `reason` is a one-sentence explanation. It provides numerous code examples and best practices, far exceeding the schema's basic 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's purpose as searching and inspecting Wix REST API documentation by writing JavaScript code in a sandboxed read-only environment. It lists overlapping sibling tools and provides guidance on when to use each, distinguishing it effectively.

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 and when-not-to-use guidance, including preferring URL-first results and preferring this tool over ReadFullDocsMethodSchema for method schemas. It also includes detailed examples showing typical use 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?

Annotations confirm readOnlyHint=true and destructiveHint=false, which align with the 'search' operation described. The description adds behavioral context about rephrasing search terms if results are insufficient, but does not describe the return format, result structure, or pagination behavior beyond the maxResults parameter.

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 functional description is front-loaded and efficient, but the field contains a massive block of agent-mandatory-instructions (XML-like tags with workflow flows) that appears to be generic system guidance rather than tool-specific description. This severely bloats the description and buries the relevant content.

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 100% schema coverage and read-only annotations, the description adequately covers the tool's purpose. However, it lacks description of return values (no output schema present), and the embedded workflow instructions, while providing some contextual integration, are improperly placed within the description field.

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?

While the input schema has 100% description coverage, the description adds valuable concrete examples of search terms ('wix dev command', 'CLI authentication', 'wix deploy') that guide the agent toward effective query formulation beyond the generic 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 'Searches the Wix CLI documentation' with specific focus on 'website development and CLI commands', distinguishing it from sibling documentation search tools (REST, SDK, Headless, etc.) by the 'CLI' qualifier. However, it could more explicitly contrast when to use CLI docs versus other documentation types.

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 when-to-use guidance ('Use this tool when you need information about Wix CLI commands...') with concrete examples ('wix dev command', 'local development setup'). Includes troubleshooting advice (rephrasing, maxResults). Lacks explicit 'when not to use' comparisons to sibling documentation 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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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, establishing the safe read-only nature. The description adds context about the search scope (official Wix REST API documentation) and suggests rephrasing search terms if results are insufficient, but does not disclose search behavior specifics (fuzzy matching, ranking algorithm, result format) beyond what the annotations imply.

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 extremely bloated due to the large <agent-mandatory-instructions> block containing workflow documentation. While every sentence may be necessary for agent operation, the overall size is inappropriate for a tool description field, creating signal-to-noise issues. It is appropriately front-loaded (actual description first), but the XML-structured instructions severely harm readability.

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 of the Wix ecosystem (17 sibling tools), the description provides comprehensive contextual mapping by explicitly referencing related tools (BrowseWixRESTDocsMenu, ReadFullDocsArticle, CallWixSiteAPI, WixREADME) and documenting four distinct usage flows. No output schema exists, so return value explanation is not expected.

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?

With 100% schema description coverage, the baseline is 3. The description adds significant value by providing concrete search term examples ('get site details endpoint', 'create data collection', 'REST authentication') that clarify expected input syntax, and explicitly mentions the maxResults parameter in the retry guidance ('use bigger maxResults value').

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear specific verb and resource ('Searches the official Wix REST API documentation'), distinguishing it from sibling search tools like SearchWixSDKDocumentation. However, the purpose is diluted by the massive embedded agent instruction block that follows, which shifts focus from tool description to operational workflow.

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 when-to-use guidance ('whenever you need to interact with the Wix platform via HTTP requests') and concrete search examples. The embedded flow-description section extensively documents how this tool fits into alternative workflows (Example-Based vs Schema-Based) and when to use sibling tools like BrowseWixRESTDocsMenu or WixREADME instead, though this guidance is buried in XML-like tags.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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 indicate readOnlyHint=true (safe operation). The description adds crucial behavioral context beyond annotations: it clarifies this is a formatting/preparation step that 'formats it in order to another tool to actually send it,' which prevents the agent from assuming the feedback is immediately transmitted.

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 somewhat wordy and contains a run-on sentence ('for example they used the tools provided, and they reflected satisfaction or dissatisfaction with the tools'). However, it is appropriately front-loaded with the main purpose, and the bold 'IMPORTANT NOTE' effectively highlights the critical behavioral constraint.

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 simplicity (2 parameters, no output schema, clear annotations), the description is complete. It addresses the primary risk (agent thinking it sends feedback directly) and provides sufficient context for the parameters. No significant gaps remain for this utility tool.

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%, establishing a baseline of 3. The description adds value by contextualizing the parameters: it links the 'message' parameter to feedback scenarios and the 'requestId' parameter specifically to failed API call errors, guiding the agent on when to populate each field.

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 identifies the tool's purpose: collecting user feedback about Wix MCP tools. It distinguishes itself from operational siblings (like CallWixSiteAPI or ManageWixSite) by specifying it handles 'good or bad' feedback about the tools themselves, not site management.

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 when-to-use scenarios: (1) user expresses satisfaction/dissatisfaction with tools, and (2) encountering too many API errors. It also clearly states what the tool does NOT do (actually send the message), though it doesn't name the specific sibling tool that handles sending.

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 write operation; description adds that it modifies the Media Manager and returns a URL and media ID. Could add more about error handling or authorization, but sufficient given 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?

Well-structured with bullet points, warnings, and clear front-loading of purpose. No redundant sentences.

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?

Provides return value information despite no output schema, covers input options and mutual exclusivity. Lacks error handling or size limits, but adequate for an upload tool.

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?

Adds value beyond schema by grouping parameters into two options, explaining mutual exclusivity, and clarifying mimeType requirement when imageBase64 lacks prefix. Schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it uploads an image to a Wix site's Media Manager, specifies return values (URL and media ID), and distinguishes itself from sibling tools that are documentation or management related.

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 warns that image data is required, provides two input methods with clear conditions (base64 for file-reading clients, URL for public URLs), and explains mutual exclusivity.

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. The description adds valuable behavioral context explaining the tool returns 'output (including relevant linked documents)' and 'recipes' for API calls, which helps the agent understand what data to expect despite no output schema existing. It does not describe rate limits or caching, but covers the essential return behavior.

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?

While structured with clear sections (Directive, Goal, Guidelines, Flow Description), the description is excessively verbose and repetitive. Phrases like 'NON-NEGOTIABLE,' 'YOU MUST,' and lengthy XML-tagged flow descriptions create bloat. The core directive could be conveyed in 2-3 sentences rather than the extensive markup-heavy text provided.

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 has no output schema, the description compensates by explaining what the output contains ('relevant linked documents,' 'recipes'). It also comprehensively covers error-handling scenarios ('If the WixREADME tool is not available to you...') and provides complete decision trees for four different usage flows, leaving no ambiguity about how to proceed after 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 contains zero parameters (empty properties object), so there are no parameter semantics to describe beyond the baseline. With 100% schema coverage trivially satisfied and no parameters needing clarification, this meets the baseline expectation for a zero-parameter tool.

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 explicitly states this is the 'MANDATORY FIRST STEP for all Wix-related tasks' that 'provides foundational context for all other Wix tools.' It clearly distinguishes itself from siblings by specifying explicit exceptions when to skip it (e.g., 'If the user asks to create... a new Wix site... skip WixREADME and call WixSiteBuilder').

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 exhaustive guidance with explicit when-to-use ('YOU MUST USE IT AT THE BEGINNING OF ANY CONVERSATION') and when-not-to-use exceptions ('If the user asks to list... their Wix sites, skip WixREADME'). Names specific sibling alternatives (WixSiteBuilder, ListWixSites) and describes fallback flows if the tool is unavailable.

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?

CRITICAL CONTRADICTION: Description states the tool performs write operations ('creating/building/generating a Wix site') but annotations declare readOnlyHint=true, which claims the tool does not modify its environment. While the description adds useful constraints (6000 character limit for sitePrompt), the annotation contradiction is fatal.

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?

Perfectly structured with bold headers front-loading importance ('PRIMARY tool', 'Do NOT use', 'IMPORTANT'). Every sentence provides actionable instruction. No redundant or wasted language despite length.

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?

Comprehensive for a site creation tool: covers primary use case, sibling differentiation, prerequisite workflow (don't search docs first), mandatory invocation requirements, and input constraints. Absence of output schema is acceptable given the directive nature of the tool.

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 has 100% coverage, but description adds critical semantic constraints beyond schema: the sitePrompt must be 'under 6000 characters' and instructions to 'summarize and condense' if longer. This operational guidance is not present 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?

Explicitly states specific verbs (creating/building/generating) and resource (Wix site/website). Clearly distinguishes from sibling CreateWixBusinessGuide with direct instruction: 'Do NOT use CreateWixBusinessGuide for site creation — use this tool instead.'

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 when-to-use ('whenever the user asks to build, create, or generate a site'), explicit exclusions ('Do NOT use WixREADME or SearchWixRESTDocumentation before this tool'), and mandates against alternatives ('Do NOT suggest HTML code...instead of actually building the site').

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