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

Annotations declare readOnlyHint=true for a tool named 'create_lead,' and the description resolves that apparent tension by stating it 'opens nothing by itself' — a genuinely valuable disclosure. It also adds plan/eligibility context for the official API that annotations cannot express, though it says little about the shape or length of the returned steps.

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 middle clause about returning step-by-step screens, buttons and fields is well-placed, but the trailing API sentence is repetitive ('Perfect Venue's official API: Perfect Venue has one public API') and the verified-date parenthetical reads as noise. The most important fact — that nothing is actually created — should lead, not follow the misleading imperative.

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 0-param tool with no output schema, the description adequately covers what comes back (ordered UI steps with screens, buttons, fields) and what the agent should do next. Missing only a sense of step volume or how to recover if a screen differs from the described steps.

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 and the schema is fully covered, so there is no parameter meaning for the description to add. Baseline for a 0-param 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 opening sentence says the tool will 'Create lead in the user's own Perfect Venue account,' which reads like a write action, and only later does the description reveal that it actually returns step-by-step instructions and opens nothing. The clarifying clause does eventually pin down the real behavior and points at the cotlet_browser_* siblings, but the front-loaded framing sends the agent in the wrong direction for a beat.

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?

There is explicit workflow guidance: call this to get the steps, then execute them with cotlet_browser_* tools in the Perfect Venue Cloud Browser. The API note (write-only Leads endpoint, Enterprise plan only) usefully explains why a guided UI path is offered, though it never states outright when to skip this tool and go straight to the API.

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