netintel_web_search

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

With no annotations, the description carries the full burden. It discloses that results are live/ranked, lists the returned fields, and hints at a keyless x402 payment model ("Keyless x402, pay…"), which is real behavioral value. However the sentence is truncated before any cost, rate-limit, or failure-mode detail lands, so key operational traits remain undisclosed.

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 definition is dense and front-loaded — purpose, payload, and modes come first — with no filler sentences. But it terminates mid-clause ("pay…"), so the final thought never completes, which is a structural defect rather than conciseness.

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?

It helpfully lists return fields, which partially substitutes for the absent output schema, and gestures at the payment model. Yet with no annotations, 8 undocumented parameters, and a truncated trailing sentence, an agent still lacks the cost, paging, result-count, and mode-value details needed to call this competently.

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 coverage is 0%, so the description must compensate, and it does partially: "Neural + keyword modes" maps to type, and "category/domain/date filters" maps to category, include_domains, start/end_published_date. It says nothing about num_results, the snippets parameter's string type, or accepted values/formats for any filter, leaving several of the 8 parameters under-specified.

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 specific verb+resource ("Web search") and enumerates the return payload (title, url, published_date, author, score, optional snippets), which is unusually informative. It only partially differentiates from the many NetIntel siblings — the explicit contrast is to a path ("/exa/answer") rather than the sibling name netintel_exa_answer, and other search-adjacent tools like netintel_web_fetch are untouched.

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?

"For a direct answer use /exa/answer" is a genuine when-not/alternative signal, and "Neural + keyword modes" hints at mode selection. But it never names the actual sibling tool, gives no guidance on when to prefer this over netintel_exa_search or netintel_web_fetch, and offers no exclusions or preconditions beyond the dangling payment note.

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