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

Annotations already declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: personal-data access depends on workspace release, leads_retrieval permission is required, foreign form/page combinations return no leads, and exceeding the limit produces a warning alongside results.

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 dense but appropriately front-loaded with the core operation and important privacy constraints before the parameter notes. It includes return-field detail despite an output schema existing, which is slightly redundant, but the overall text remains purposeful.

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 five-parameter, permission-sensitive listing tool, the description covers data scope, required permissions, ownership constraints, error cases, pagination-limit behavior, defaults, and parameter sources. Although an output schema exists, the description goes beyond it to explain access and failure conditions.

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 0%, so the description must carry all parameter meaning. It does: form_id comes from meta_list_lead_forms, page_id follows the same pattern, days is 1–90 with default 30, limit defaults to 100 and maxes at 500 with a warning if more exist, and workspace is optional when only one workspace exists.

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 a specific verb and resource: listing leads from an Instant Form for the last N days, and enumerates the returned fields. It is clearly distinguishable from meta_list_lead_forms, which it identifies as the source of form_id and the fallback for lead counts without data permission.

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 explicitly covers the prerequisites (workspace lead-data release and leads_retrieval permission), names meta_list_lead_forms as the alternative for counts without release, and explains when errors such as lead_data_disabled or foreign_object occur.

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