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

With no annotations, the description carries full burden. It discloses key behavioral traits: the parameter's effect on output, that omitting place_slug yields directory plans (which most sites lack), and that the return includes fields like plan name, price, and a checkout URL. While it implies a read operation, it could be more explicit about being non-destructive and about any authentication requirements. Still, for a simple listing, the transparency is strong.

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 two sentences with no fluff. The first sentence states the core purpose and the second explains parameter usage with a clear preference. Every sentence adds value, and the most important information is 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?

The tool has no output schema, so the description must cover both input and output. It lists the returned fields (name, description, price, billing cycle, perks, checkout URL) which is sufficient for understanding. However, it does not describe the data types or structure of the output. Given the simplicity, this is a minor gap, making a 4 reasonable.

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 a single parameter described in the schema. The description adds context beyond the schema by emphasizing the common use case ('almost every case') and reinforcing the source of the parameter ('from search_places'). This extra guidance improves usability beyond what the schema alone provides, meriting a 4.

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 lists the tool's purpose: to list membership or subscription plans (Wix Pricing Plans). It distinguishes between two modes: with `place_slug` for venue-specific plans and without for the directory's own plans. The verb 'list' is specific and appropriate.

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 each mode: 'Pass place_slug ... to list the plans of a specific VENUE' and 'Omitting place_slug lists the directory site's own plans instead'. It indicates that the venue mode is 'what you want in almost every case'. However, it does not mention alternative tools or explicitly state when not to use this tool, so a 4 is appropriate.

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