One question searched in science, world news, Internet Archive, GitHub and discussions. Free.
Scored across 2 tools
The two tools have clearly distinct purposes: deep_search performs the actual multi-source search, while list_deep_sources only documents available sources. There is no realistic risk of an agent confusing one for the other.
Both names use snake_case, but they do not follow the same convention: list_deep_sources uses a clear verb_noun pattern, while deep_search is more of a branded action phrase. The names are readable but only partially consistent.
Two tools is borderline thin, though the server has a narrow search-focused purpose. The source-listing helper supports the main search tool, but the surface still feels minimal.
The core deep-search workflow and source discovery are covered, which fits the stated purpose. Minor gaps remain around pagination, result limits, or date-range filtering, but agents can likely work around them.
Search one question at once in sources a normal web search misses: science (arXiv, Crossref), world news in 100+ languages of the last 3 months (GDELT), Internet Archive, GitHub, Wikipedia, and what people say (Bluesky, Mastodon, Lemmy, Hacker News, forums). Results grouped by source, dated, with links. Use when: you need rich, hard-to-find, sourced information on a subject. Example: {"query":"agentic commerce paid placement","sources":["science","news"],"lang":"en"}
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Optional 2-letter language for news, Wikipedia and discussions, e.g. fr, ja, ru | |
| query | Yes | The subject, any language (sources search it as written) | |
| sources | No | Optional subset; default: all | |
| limit_per_source | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive and open-world semantics, so the bar is lower; the description still contributes the 'one question at once' constraint, the 3-month recency window for news, and the shape of returned results (grouped by source, dated, with links). It does not mention latency, per-source quotas, or behavior when a source fails.
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 tight blocks — what it searches, when to use it, and a worked example — with the differentiating source list front-loaded and no filler. The example earns its place by showing the exact payload shape.
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 no output schema, the description compensates by describing the return layout (grouped by source, dated, linked), and it discloses the recency restriction that would otherwise surprise an agent. Only limit_per_source is unexplained, a minor omission for a tool this well characterized.
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 description maps prose source categories onto the enum values (science→arXiv/Crossref, news→GDELT, code→GitHub, people→social/forum platforms), which adds real meaning beyond bare enum tokens. It leaves limit_per_source — the one schema property with no description at 75% coverage — entirely unaddressed.
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 ('Search') and an explicitly enumerated resource set (arXiv, Crossref, GDELT, Internet Archive, GitHub, Wikipedia, Bluesky/Mastodon/Lemmy/HN), which makes its scope far clearer than a generic web search. It never names the list_deep_sources sibling, so differentiation relies on the reader inferring it from the verb.
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?
'Use when: you need rich, hard-to-find, sourced information on a subject' gives a clear positive trigger, reinforced by a concrete example call. There is no when-not guidance and no pointer to list_deep_sources as the alternative for discovering available sources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The sources searched by deep_search and what each one covers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 fully covered. The description adds that the result is a catalog of sources with their coverage descriptions, but it does not describe the shape of that output (names, URLs, scope text) or that the list is static/fixed.
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?
A single front-loaded sentence with no filler and no repetition of annotation or schema content. It is efficient, though extremely terse for a tool whose output shape is unstated.
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 no-argument, read-only catalog tool with no output schema and full annotation coverage, the description conveys enough to select and call it correctly. The only gap is a hint about what the returned source entries actually contain, which is minor at this complexity level.
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 tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; no parameter-level information is expected or missing.
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 the resource (sources searched by deep_search) and what it returns (what each source covers), and explicitly references the sibling deep_search, so an agent can distinguish this catalog tool from the search tool. It is a noun phrase rather than a verb+resource, which slightly weakens the statement of action, but the intent is 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 link to deep_search implies you call this to understand which sources that tool covers, but there is no explicit when-to-use, no prerequisites, and no statement of alternatives. Usage is inferable rather than directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
deep_searchlist_deep_sourcesSearch research and community sources. Queries logged for research; optional purpose. No secrets.
Public knowledge and news search. Unmatched public queries may be retained for research.
Search a billion+ documents — papers, books, code, legal cases, forums, Wikipedia, and more.
Search a tiered, cited public research record; read its sources; work its open questions.
Add one secure layer between your agents and this server.