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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world behavior, so the bar is lower; the description still contributes real context by explaining monetary shape ({ amount, currency }, amount as exact decimal string) and that credit limits are not cash. It also documents pagination continuation via page.nextCursor. It stops short of clarifying what 'owned' scopes, e.g. user versus connection ownership.

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 tight sentences with the capability statement front-loaded before the semantic caveats and pagination rule. Nothing is redundant, though the monetary note reads telegraphically and could be slightly clearer without adding length.

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?

An output schema exists, so return values need no explanation, and the description covers mode selection, money representation, and cursor handling for a four-parameter nested tool. The gap is ownership scope and permission expectations, which an agent might reasonably want before calling.

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?

With 100% schema description coverage the baseline is 3, and most of the description's parameter-adjacent content restates what the schema already says about modes. The one genuine addition is instructing callers to pass page.nextCursor back unchanged, which refines the schema's 'Opaque keyset pagination' note. That is useful but narrow.

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 uses a specific verb and resource ('Find one owned account, list owned accounts, or filter by connection') and enumerates the three access patterns the tool supports. Because the resource is distinctly 'accounts', an agent can separate it from siblings like mofi_cards_get or mofi_transactions_get without reading the schema.

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 is only implied through the mode enumeration; the description never states when to choose this tool over mofi_connections_get or when-not to use it. The per-mode requirements (findOne needs accountId, query needs where) live in the schema rather than the description, so the prose adds little routing guidance.

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