Skip to main content
Glama

Search papers (multi-query)

search_papers_many
Read-only

Use for a LITERATURE SWEEP or survey: a research question broad enough to need several angles, e.g. "what's been done on X", a related-work section, or a state-of-the-field summary. One call returns one merged, ranked list of the papers the angles found, with the passages that matched. For a single focused question, use search_papers instead. Runs 1 to 25 query variants in ONE call and gets back a single deduped, RRF-merged ranked list with per-paper provenance (matched_queries: which of your queries, by index into the echoed queries, surfaced each paper, and at what rank): supply several genuinely different angles on the topic (rephrasings, sub-questions, alternate terminology) and the server fuses their ranked lists so the merged result covers more of the corpus than any single query would. Each variant runs the same hybrid retrieval as search_papers (Cohere Embed v4 + BM25 + Cohere Rerank v3.5) without its server-side rewrites, because your variants are the expansion: spell out abbreviations and synonyms in the variants themselves. Filters (conference, year, year_min, year_max, venues) are SHARED across all queries. The envelope reports queries_run and, for any variant whose pipeline failed, queries_failed (so one bad variant never sinks the batch). has_more is always false: the merged shortlist is bounded; widen the query set or filters for more coverage. Each hit carries metadata, abstract, ids, and the matched contexts spans to ground or quote from; detail: false returns concise hits with one snippet. paper_id is a handle for YOU to fetch full text via get_paper_fulltext; cite papers by title, authors, and venue, never by id. Billing: each query variant counts as one search against your quota (an 8-query call costs 8), since the server runs a full search pipeline per variant; prefer a focused set of genuinely distinct angles over padding the list.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "queries": "<queries>",
      "limit": "<limit>",
      "detail": "<detail>"
    },
    "name": "search_papers_many"
  }
}

Input Schema

NameRequiredDescriptionDefault
yearNoShared across every query: restrict to a single publication year.
limitYesMax papers in the merged, deduped result list (default 10, max 50).
detailYestrue (default): include the full abstract, ids, and contexts[] non-abstract matched spans for grounding. false: concise hits (title, authors, year, venue, citations, score, and a single grounding snippet) for token-saving triage. `matched_queries` provenance is always present. For the complete paper text call get_paper_fulltext.
venuesNoShared across every query: restrict to these conference short names (e.g. ["NeurIPS", "ICML"]).
queriesYes1 to 25 query variants to run in ONE call. Phrase each the way you would ask a human research assistant (full natural-language questions beat keyword bags). Supply genuinely different angles on the topic (rephrasings, sub-questions, alternate terminology) so the merged list covers more of the literature than any single query would. The server runs each variant through the full hybrid pipeline and RRF-fuses the ranked lists into one deduped result set.
year_maxNoShared across every query: only papers published in this year or earlier.
year_minNoShared across every query: only papers published in this year or later.
conferenceNoShared across every query: filter to this conference short name, e.g. "CCS", "NeurIPS".

Output Schema

NameRequiredDescriptionDefault
queriesYesYour query variants, once each and in the order you sent them; each hit's `matched_queries` points into this list.
resultsYesOne deduped, RRF-merged ranked list across all query variants; each hit carries `matched_queries` provenance.
has_moreYesAlways false: the merged shortlist is bounded, so there is no cursor to page past it. Widen the query set or filters for more coverage.
queries_runYesHow many of the submitted query variants completed successfully.
queries_failedYesVariants whose pipeline raised; recorded here instead of sinking the whole batch. Empty when every variant ran.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the read-only, open-world, non-destructive annotations, the description discloses RRF merging, deduplication, per-paper `matched_queries` provenance, shared filters, `queries_failed` handling, and that `has_more` is always false. It also discloses billing behavior: each query variant counts as one search against the quota. These are material behavioral traits an agent needs before invoking the tool.

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?

The description is front-loaded with the primary use case and the sibling alternative, and most sentences carry actionable detail. It is admittedly dense and repeats some points about deduplication, RRF merging, and producing genuinely different query angles. Still, the length is largely justified by the tool's complexity.

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 the output schema, annotations, and 8-parameter surface, the description covers the remaining gaps an agent needs: merge behavior, provenance, failure handling, quota cost, citation guidance, and when to use the single-query alternative. Nothing essential for correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents each parameter, including that filters are shared and that `queries` accepts 1-25 variants. The description reinforces useful semantics, such as supplying genuinely different angles and spelling out abbreviations and synonyms, but it largely repeats the schema rather than adding new parameter-level details.

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 states a specific verb and resource: multi-query paper search for literature sweeps and surveys. It explicitly distinguishes itself from `search_papers` by explaining that this tool runs 1-25 variants in one call and returns a merged, deduped ranked list. An agent can tell exactly what this tool does and when it differs from its closest sibling.

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?

It gives explicit when-to-use guidance: broad research questions, related-work sections, and state-of-the-field summaries. It also gives a direct alternative for a single focused question: use `search_papers` instead. The distinction is concrete and actionable.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.