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

Annotations only declare readOnlyHint and idempotentHint; the description goes well beyond by disclosing ordering ('newest first'), the auth requirement ('Requires a key'), and a genuinely non-obvious behavioral rule — an account key sees every form while an agent key sees only the forms it created. That key-scoping behavior is invisible in the schema and annotations and materially changes expected 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 routing instruction ('call this to find a form_id...') is correctly front-loaded and every clause carries information. However, the second sentence is a long comma-and-semicolon chain bundling ordering, field list, key scoping and auth into one run-on, which slightly hurts scannability.

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 zero-parameter, read-only listing tool with an output schema, nothing an agent needs is missing: ordering, credential-scoping rules, auth requirement and sibling routing are all covered. The field list is somewhat redundant with the output schema but harmless.

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?

There are zero parameters, so the baseline is 4 and there is no parameter meaning to add. The enumeration of returned fields is arguably return-value detail rather than parameter semantics, so it does not push the score higher.

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 a specific verb+resource ('list_forms' / 'Lists the forms') and immediately clarifies scope: 'see every form the key reaches with its status and submission count'. It explicitly distinguishes itself from get_submissions, naming it as the tool for reading one form's answers rather than listing forms.

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?

Gives explicit when-to-use ('find a form_id for get_submissions, publish_form, update_form_settings or get_webhook') and an explicit when-not/alternative ('to read the answers of one form, call get_submissions instead'). It even scopes usage by credential type, which is exactly the guidance an agent needs before calling.

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