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

No annotations are supplied, so the description carries the full behavioral burden. It discloses the data source (Vysion) and that a 200 returns JSON, but says nothing about pagination behavior, result ordering, whether the wallet feed is read-only in practice, rate limits, or auth requirements — all material for a feed tool with page/page_size/batch parameters.

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 core sentence is short and front-loaded with zero padding. However, the trailing '### Responses: 200 ... Content-Type: application/json' block is boilerplate that conveys almost no actionable information for this tool and displaces space that could have described pagination or batching.

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?

Six parameters, three of them undocumented, no annotations, and no output schema — the description would need to do real work and does not. An agent still cannot tell what 'batch' means, how paging terminates, or how this feed differs from get_telegram_feed when platform='telegram'.

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 only 50%: gte, lte, and platform are documented in the schema, but page, batch, and page_size have no description anywhere. The description repeats the platform values already present in the schema and adds no meaning for batch (an ambiguous field), pagination, or how gte/lte interact with the feed window.

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 concrete verb and resource: 'Get cryptocurrency wallet feed from Vysion filtered by platform,' and enumerates the allowed platform values. It does not distinguish itself from siblings like get_telegram_feed or get_onion_feed, even though the 'telegram' platform value appears to overlap with get_telegram_feed, leaving the agent to guess which is appropriate.

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 when-to-use or when-not-to-use guidance and no alternative tool is named. The only routing hint is the platform enumeration, which is a parameter constraint rather than usage guidance, so nothing tells the agent when this feed should be preferred over the sibling feeds.

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