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

Annotations already declare destructiveHint=true, readOnlyHint=false and idempotentHint=false, so the safety profile is partly pre-supplied. The description still adds genuine value beyond them: forms are publicly linked, submissions write to contacts, delete breaks the public link and requires confirmation, and submissions returns only the latest 200 — a real behavioral constraint not encoded anywhere else. It doesn't say what 'update' does to unspecified fields or what permissions are needed.

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

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

Front-loaded one-liner plus a compact action grammar with zero filler; every clause carries information. The terse 'create (name?, templateId?)' / 'update (id + changes)' notation is efficient but slightly ambiguous about which of the 13 fields 'changes' covers.

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 13-parameter, no-output-schema, destructive tool, the description covers action routing, the write side effect on contacts, the delete consequence and the submissions cap. Remaining gaps (return shapes for list/get, required field structure, pagination) are modest but present given no output schema exists to cover them.

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?

Description maps parameters to actions (id for get/delete/submissions, name+templateId for create, id+changes for update), which the schema does not do on its own. At 54% schema coverage, several params (tags, fields, style, createTask, redirectUrl) rely on schema text, and the description gives no additional meaning for them, so it stops at a solid 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?

States the resource (lead-capture forms), the key mechanism (public link) and the side effect (each submission creates or updates a contact), then enumerates every action verb. An agent can immediately tell this apart from siblings like campaigns_manage or contacts_manage.

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 action grammar doubles as usage guidance: 'templates' is implicitly the source of templateId, 'get' vs 'submissions' vs 'list' are distinguished by argument, and delete carries an explicit warning ('the link stops working; confirm'). It doesn't name alternatives or state exclusions, so it stops short of a 5.

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