Cluefinch MCP

Official

Overview Schema Source Related Servers Discussions Admin

web_search

Read-only

Discover candidate sources when the needed source or URL is unknown, using query, domain, and recency filters; returns previews, not fetched page content.

Instructions

Discover candidate sources through search; this does not fetch page content.

USE THIS when the needed source or URL is not yet known, when you need a new
independent source, or when search-engine discovery itself is required.
DO NOT search again merely to find another page inside a strong source when
that page is likely linked from the current page; use web_links instead.

Domain filtering example: web_search(query="asyncio", domain="python.org",
exclude_domains=["discuss.python.org"], max_results=20). Domain operators
depend on the provider. Search pagination is not supported.

Results are candidates, not verified page evidence: snippet is a search-engine
preview and result.url has not been fetched. For a candidate:
- web_links(url=result.url): inspect chapters, pagination, references or related
  pages exposed by that source without crawling them;
- web_fetch(url=result.url, max_chars=500): preview/read the selected document;
- research_collect(urls=[...]): collect bounded evidence from selected URLs.

Returns results, query_used, unresponsive_engines and cached. Always inspect
unresponsive_engines: nonempty means incomplete search coverage. Expected
failures return {error, hint}.

Input Schema

TableJSON Schema

Name	Required	Description
`query`	Yes	Search terms. For several query variants and fetched excerpts, use research_collect instead.
`domain`	No	Include site:domain in the query, e.g. docs.python.org. Use a hostname, not a page URL. Can be combined with exclude_domains.
`engines`	No	Optional engine subset: google, google cse, brave, wikipedia, wikidata. Omit to use SearXNG defaults.
`language`	No	Language/locale such as en or ru. Omit for any language.
`time_range`	No	Optional recency filter: day, week, month or year.
`max_results`	No	Requested candidates. Default 10; configured cap 20. This is a result limit, not search pagination.
`safe_search`	No	0=off, 1=moderate, 2=strict. Omit for provider defaults.
`exclude_domains`	No	Exclude domains with -site: operators, e.g. ['pinterest.com', 'example.org']. Provider support varies; verify returned URLs.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.4Oct 4, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover read-only/open-world safety, and the description adds substantial context beyond them: no pagination, results are unfetched candidates with preview-only snippets, unresponsive_engines must be inspected for incomplete coverage, and failures return {error, hint}.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and routing before examples and result caveats. The follow-up bullet list is longer than strictly necessary but each item maps to a real next-step decision, so waste is limited.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an output schema existing, the description adds actionable value by flagging unresponsive_engines as a coverage signal. With 8 params, sibling routing, and result-interpretation guidance all covered, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 8 params (baseline 3). The description adds a concrete combined-call example (query + domain + exclude_domains + max_results) and the caveat that domain operators are provider-dependent, which is meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Discover candidate sources through search') and immediately negates the sibling behavior it does not perform ('this does not fetch page content'), which cleanly separates it from web_fetch.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit USE THIS when-conditions are given (source/URL unknown, need independent source, discovery required) plus an explicit DO NOT with the alternative named ('use web_links instead'). research_collect is also routed to for multi-variant queries, so the agent never has to infer tool choice.

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

Deploy Server