Skip to main content
Glama
ymylive
by ymylive

research

Read-only

Search the web, fetch top results, and synthesize them into a research brief with source references, replacing multiple search+fetch calls.

Instructions

One-shot research: search the web, fetch the top results, return both.

Best for:
- Open-ended questions that need finding sources AND reading them
  ("what's new with X", "summarize the controversy around Y").
- Replacing a `search` + N x `fetch` chain with one call.
- Producing a citable brief with [n]-style source references.

Not recommended for:
- You only need links -> `search` (cheaper, no fetching).
- You only need to read one URL you already have -> `fetch`.
- You want to query previously-fetched cached pages -> `cache_search`.

Returns:
- markdown (default): a "Research brief" with a Sources index then the
  full Markdown body of each fetched document, separated by horizontal
  rules; includes a token estimate.
- json: {question, engines, sources:[{rank,title,url,snippet,...}],
  documents:[...], tokens_estimated, errors}.

Common mistakes:
- Using `depth=8` for a quick lookup — that's 8 page fetches; 2-3 is
  almost always enough.
- Calling `research` for a known URL — that's `fetch` territory.
- Forgetting that `fetch=False` returns sources only (much cheaper if
  the LLM only needs to pick which one to read).

Args:
    question: What you want to know, in natural language.
    depth: How many top results to fetch (1-8). 3 is a good default.
    engines: Override the engine set (see `engines()` for names).
    fetch: If False, return source list without reading them.
    use_cache: Reuse cached search/page data within TTL.
    max_age_hours: Treat cached search results older than this as a miss
        (0 = force-refresh search; None = server default TTL).
    format: "markdown" or "json".

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
questionYes
depthNo
enginesNo
fetchNo
use_cacheNo
max_age_hoursNo
freshnessNo
include_domainsNo
exclude_domainsNo
categoryNo
include_textNo
exclude_textNo
formatNomarkdown

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior4/5

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

Discloses behavior beyond annotations: depth default 3, fetch=False returns sources only, caching semantics (max_age_hours, use_cache). Returns include a token estimate. Annotations already state readOnlyHint=true and openWorldHint=true, so description adds substantial context without contradiction.

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?

Well-structured with sections (best for, not recommended, returns, common mistakes, args). Slightly long due to extensive param descriptions, but every sentence adds value for a complex tool. Could tighten some redundant phrasing.

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?

Given 13 parameters, 0% schema description coverage, and no output schema, the description is remarkably complete. It explains all key behaviors, edge cases (fetch=False, caching TTL), and return format. Common mistakes section preempts usage errors. Output schema exists server-side but description still describes return structure.

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 description coverage is 0%, so description must compensate. It does: explains question (natural language), depth (how many results, good default), engines override, fetch boolean, caching params, format (markdown/json). Adds meaning like depth=8 is heavy, fetch=False cheaper. Some params (freshness, include_domains) are not described but schema enums cover them partially.

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?

The description clearly states it's a one-shot research tool that searches the web, fetches top results, and returns both. It distinguishes from siblings like `search` (cheaper, no fetch) and `fetch` (single URL) with specific use cases.

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?

Explicitly lists best-for scenarios (open-ended questions, replacing search+fetch chain) and not-recommended cases (only need links -> search, known URL -> fetch, cached pages -> cache_search). Also provides common mistakes and alternative tool names.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ymylive/free-search-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server