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

No annotations are provided, so the description carries the full burden. It mentions one behavioral trait — that include=['content'] inlines bodies — but does not disclose read-only intent, return format, pagination behavior, or error conditions. For a search tool this is a significant gap.

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?

Four short sentences, each carrying distinct information. The purpose is front-loaded, filtering options are summarized, the include behavior is noted, and the alternative tool is named. No waste.

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 9 parameters, no output schema, and no annotations, the description is insufficient. It omits pagination, sorting, match semantics, and the context parameter. An agent cannot reliably know how to paginate or what the result structure looks like.

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 44% (low). The description adds meaning for q, tags, providers, and include, but leaves page, sort, limit, match, and context undocumented both in schema and description. It partially compensates but not enough to guide correct invocation of all 9 parameters.

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 states the resource ('example payloads') and the verb ('Find') clearly, and differentiates from the sibling find_artifacts by noting it is for cross-type search. It conveys that this tool returns real request/response examples, making its purpose unambiguous.

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 description explicitly names find_artifacts as an alternative for cross-type search, giving a clear when-not-to-use-this signal. It does not enumerate other alternatives, but the provided distinction is actionable and sufficient for most agents to route correctly.

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