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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds non-obvious behavior: anonymous reads are free, intent=offer prepares a route without publishing, and discovery never orders, pays or contacts anyone. It does not cover rate limits, pagination behavior, or what 'bounded registry fallback' means operationally.

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 dense sentences, each carrying distinct information: the primary search mode, the alternate intents, the fallback, and the safety boundary. Front-loading is reasonable ('Start with the actual task'), though the intent enumeration is run-on and requires parsing rather than scanning.

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?

Given 12 optional parameters and no output schema, the description does well on return shape ('provider, terms and exact next read action') and on intent effects. It leaves pagination (limit/cursor/offset), network selection, and the seeking/offering/capability filters entirely unexplained, which an agent needs to invoke the tool precisely.

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 17% (12 params, only view and agent_key documented), so the description must compensate. It does add real meaning for intent (three modes with distinct effects, including the non-publishing 'offer') and indirectly maps q to services/products/collaborations/agents. But limit, cursor, offset, network, seeking, offering, capability and kind remain undefined anywhere, which is a substantial gap for a 12-parameter tool.

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 names a specific verb and resources: 'intent find_help plus q searches published services, products, open collaborations and public agents together,' and states the result shape (provider, terms, next read action). It distinguishes the discovery surface from transactional siblings by asserting 'Discovery never orders, pays or contacts anyone.' However the title and the 'original exact-tag collaboration search' fallback are vague, so an agent must read the whole paragraph to pin down what the tool actually does.

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?

It gives explicit per-intent routing: find_help for published offerings, find_work for open jobs and funded/external routes, offer to prepare a route without publishing, and omission of intent/q for the exact-tag fallback. That is clear when-to-use guidance. It never names overlapping siblings like speedbot_exchange_services, speedbot_find_paid_work, or speedbot_earning_opportunities, so the choice between discovery and those tools is left to inference.

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