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

Annotations already establish read-only, idempotent, non-destructive, open-world behavior, so the bar is lower. The description adds real value by disclosing the returned structure with no output schema present: per-funnel ordered steps, conversion window in hours, and a stable identifier. It does not cover ordering, pagination, or behavior when a funnel has zero 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?

Two short sentences, front-loaded with the resource and its contents. The second sentence on stable identifiers is mildly redundant with 'each with its ordered steps' but plausibly clarifies that ids are reusable, so it mostly earns its place.

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 one-parameter read tool with no output schema, the description adequately conveys the return contents, which is the main missing piece an agent would otherwise lack. Only routing guidance versus get_funnel_results and create_funnel is absent.

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 the single app parameter is fully documented in the schema as an application id or orgSlug/appSlug. The description only alludes to it with 'for an application', adding nothing beyond the schema; baseline 3 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 clearly states the resource returned (saved funnels for an application) and its shape (ordered steps, conversion window, stable identifier). It never uses an explicit verb like 'list', and it does not distinguish this from siblings such as get_funnel_results or create_funnel, leaving the agent to infer that this returns definitions rather than results.

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 no statement of when to use this tool, when not to, or which alternative to pick when the agent wants funnel performance data versus funnel definitions. The only routing hint is indirect, in the schema description that references list_apps.

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