List Mitr funnels

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered; the description adds real value by stating that it returns ALL saved funnels in the workspace along with their id, name, and step definitions, which is useful disclosure given there is no output schema. It stops short of stating result limits or pagination behavior, though 'every saved funnel' suggests a complete, unpaginated listing.

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?

A single front-loaded sentence that names the resource, its scope (workspace), and the exact returned fields, with no filler. The routing hint is embedded compactly rather than padding the text.

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?

With no output schema and no parameters, the description carries the burden of explaining return values, and it does so by naming the id, name, and step definitions of each funnel. The remaining gap is minor: no statement about ordering or result-size limits for very large workspaces.

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?

The tool takes zero parameters, so the baseline is 4 and there is nothing in the schema for the description to compensate for. The description correctly describes a parameterless workspace-scoped listing rather than implying any filters that don't exist.

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 every saved conversion funnel in your Mitr workspace') and enumerates the returned fields (id, name, step definitions). It hints at the read-vs-detail sibling boundary by referencing get_funnel_results as the consumer of the ids, but it never explicitly contrasts itself with the create/update/delete funnel siblings.

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 parenthetical '(needed by get_funnel_results)' implies the intended workflow: call this first to obtain an id before fetching results. Beyond that implied sequencing, there is no explicit when-to-use/when-not guidance or mention of any alternative listing tool.

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