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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description contributes the 'cross-forge unified feed' scoping concept but says nothing about pagination behavior, default page size, whether cursor is opaque, or what a result row looks like, so it adds only modest context beyond the structured fields.

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 sentences, purpose front-loaded, followed by a dense filter list and a sort enumeration. There is essentially no filler; every clause conveys usable information.

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 twelve-parameter search tool with no output schema and zero schema description coverage, the description is too thin: it omits the four remaining parameters entirely, explains nothing about pagination or result shape, and gives no hint about how results are ranked or paged. The annotations relieve some of the burden, but an agent still lacks enough to call this confidently across the full parameter surface.

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 0%, so the description must compensate, and it does partially by naming eight of the twelve parameters (forge, source, repo, min_usd, currency, escrow, max_competition, sort) and giving the sort enum values inline. However, q, limit, cursor, and domain are never mentioned, and none of the named params get format detail such as currency codes, USD units, or what max_competition counts, so the gap is narrowed but not closed.

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 opens with a specific verb and resource: 'Search the unified cross-forge funded-work feed.' That is concrete and distinguishable from a single-item fetch or an aggregate-stats call, though it never names feed_get or feed_stats to make the routing explicit.

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: the enumerated filter and sort options suggest 'reach for this when you want to narrow the funded-work feed,' but there is no explicit when-to-use/when-not guidance or comparison to the feed_get and feed_stats siblings. An agent can infer intent but must decide for itself when this tool is the right entry point.

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