insync_list_forms

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely non-structured context: only form names are surfaced, and the form markup plus the portal-embedded login credentials are never returned — an important privacy boundary for an open-world read. Pagination/ordering behavior is not mentioned, keeping it short of a 5.

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?

Three short sentences, front-loaded with the resource and then the most decision-relevant fact (the default filter), with the privacy caveat last. Slight redundancy with the schema's own status wording, but no wasted material.

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?

No output schema exists, and the description does compensate by characterizing the return shape: form names only, with markup and credentials excluded. For a zero-required-parameter read tool that is nearly complete; ordering, pagination, and result-size expectations are the remaining gaps.

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 100%, and both enum parameters are already fully documented in the schema, including the 'pending' default and the compact/full/raw projection meanings. The description largely restates the status semantics already in the schema rather than adding new meaning, so the baseline 3 for high-coverage schemas applies.

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 gives a specific verb and resource: list patient intake/consent forms the practice has sent. It is clear about scope (forms sent by the practice) but never distinguishes itself from near-neighbor siblings like insync_list_documents or insync_list_surveys, which an agent could plausibly confuse with form listings.

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?

Usage guidance exists only at the filter level: 'pending' is what still needs completing, 'all' includes submitted ones. There is no statement of when to prefer this tool over sibling list tools (documents, surveys) or when it is not appropriate, leaving the alternative selection to inference.

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