search_webDiscover current public sources with up to four focused searches. Search snippets are discovery aids; open the strongest pages before citing substantive claims.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | ||
| max_results | No |
| Name | Required | Description | Default |
|---|---|---|---|
| failures | Yes | ||
| searches | Yes | ||
| budgetReached | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already cover read-only and open-world behavior. The description adds that search snippets are 'discovery aids' and advises opening pages for citation, subtly indicating the tool returns snippets rather than full content. This is a useful behavioral hint, but it does not disclose rate limits, pagination, or other traits beyond the annotations.
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 description is concise—two sentences—with the primary purpose stated first in the opening clause. It avoids unnecessary detail and is well-structured, fitting the expected format for a tool description.
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 tool with an output schema (not shown) and multiple parameters, the description lacks crucial context: it does not specify the output format, explain parameter semantics, or provide usage scenarios. It leaves the agent to infer how to construct queries and interpret results. The annotations provide safety context but do not fill these gaps.
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?
The input schema contains parameters (queries, max_results) with no descriptions, and the tool description does not explain their meaning or usage. The mention of 'up to four focused searches' repeats a schema constraint (maxItems: 4) but does not clarify what a 'focused search' entails or how parameters like site, publishedAfter, or publishedBefore should be used.
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 clearly states the tool's purpose: discovering current public sources via web searches. It specifies the verb 'discover', the resource 'current public sources', and a constraint (up to four searches), making the intent unambiguous even without relying on the tool name.
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 provides no explicit guidance on when to use this tool versus siblings like search_article or search_feeds. It implies general web search but does not differentiate conditions or alternatives. The only usage hint ('open the strongest pages before citing') addresses post-search behavior, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a largely distinct job: discovery (search_feeds, search_web), content retrieval/search within URLs (get_article, search_article), and library/feed management (save_article, follow_feeds, update_library_item, create_monitor). The only mild overlap is get_article vs open_web_pages, both of which extract content from public URLs, but their different output styles and intended use cases keep them mostly separate.
All nine tool names follow a consistent imperative verb + object pattern in snake_case: create_monitor, follow_feeds, get_article, open_web_pages, save_article, search_article, search_feeds, search_web, update_library_item. There are no mixed conventions, vague verbs, or surprising abbreviations.
Nine tools is well-scoped for a reading and summarization product: three search/discovery tools, three content-retrieval tools, and three library/feed management tools. Each tool contributes a distinct workflow step and the set avoids bloat.
The set covers discovery, fetching and searching content, saving to a library, following feeds, monitoring page changes, and updating library items. However, there are no removal operations (unfollow feed, delete monitor, delete library item) and no direct way to list or read the user's saved library or followed sources, creating noticeable lifecycle gaps.