Lune Research

Gather evidence and judge sufficiency

gather_evidence

Read-only

Use for a multi-part research task when you need to know whether your gathered evidence is SUFFICIENT, what is still MISSING, and what to search next, without the tool writing the answer. Pass the goal in task and your first search angles in queries; the server runs one corpus search per angle, decomposes the task into evidence requirements (or use your own via requirements), and returns each requirement as covered / partial / missing with the exact evidence_spans (verbatim quotes) that support it, plus next_queries for the gaps. Default max_iterations=1 is a one-shot assessment billed len(queries); set max_iterations>1 AND max_total_queries>len(queries) to authorize bounded server-side follow-up searches (billed max_total_queries, capped at 25). Optionally pass a draft to get per-sentence support checks against the gathered spans. Every covered requirement and supported draft sentence carries a verbatim quote verified server-side, so you can cite it directly. You write the answer; cite papers by title, authors, and venue, not by paper_id.

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": {
      "task": "<task>",
      "queries": "<queries>",
      "max_iterations": "<max_iterations>"
    },
    "name": "gather_evidence"
  }
}

Input Schema

Name	Required	Description
`task`	Yes	The research goal in prose: what you are trying to establish. Drives requirement decomposition and the sufficiency judgment.
`year`	No
`draft`	No	Optional current draft. Each sentence is checked for support against the gathered spans (no extra searches). The tool never rewrites your draft.
`venues`	No	Restrict to these conference short names.
`queries`	Yes	Your initial search angles (full natural-language questions). One corpus search runs per angle; they are billed like search_papers_many.
`year_max`	No
`year_min`	No
`conference`	No	Filter to this conference short name, e.g. "NeurIPS".
`requirements`	No	Optional explicit evidence slots; omit to let the server derive them from `task`.
`max_iterations`	Yes	Sufficiency rounds. Default 1 is a one-shot advisor. Set >1 (with max_total_queries>len(queries)) to authorize bounded server-side follow-up searches.
`max_total_queries`	No	Total search budget across all iterations (the billed ceiling). Defaults to len(queries). Must exceed len(queries) only when max_iterations>1.

Output Schema

Name	Required	Description
`queries_run`	Yes	Actual searches run (<= units_charged).
`stop_reason`	Yes
`next_queries`	Yes	Suggested follow-up search angles for partial / missing requirements.
`requirements`	Yes	One coverage row per requirement: covered / partial / missing.
`draft_support`	Yes	Per-sentence support for a supplied draft; null when no draft was sent or the check did not finish (stop_reason says time_budget when the time budget cut it).
`units_charged`	Yes	Billed ceiling (max_total_queries, default len(queries), cap 25).
`evidence_spans`	Yes	The spans the judge evaluated; every supporting_span_id points here.
`iterations_run`	Yes
`queries_failed`	Yes	Per-query failures (non-CircuitBreaker); a systemic outage 503s instead.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations cover the read-only, open-world, non-destructive profile, and the description adds substantial context beyond them: one corpus search per angle, billing tied to len(queries) vs max_total_queries, a 25-query cap, and the exact gate (max_iterations>1 AND max_total_queries>len(queries)) required to authorize server-side follow-up searches. It also discloses that quotes are verified server-side and can be cited directly, plus a citation convention (title/authors/venue, not paper_id).

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 the use case and then the calling contract; nearly every clause carries information (billing, gating, return shape, citation rule). It is a single dense semicolon-chained paragraph, which makes the billing/budget rules harder to scan than a short bulleted structure would.

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?

For an 11-parameter, budgeted, multi-iteration tool, the description covers the trigger, the search-and-billing model, the opt-in gate for extra searches, the optional draft mode, and the citation requirement. Return values are also summarized despite an output schema existing, leaving nothing an agent needs to call it correctly.

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?

With 73% schema coverage the baseline is modest, but the description adds non-obvious semantics the schema cannot express: `task` drives requirement decomposition, `queries` maps one billed search per angle, `requirements` overrides server-derived slots, and `max_iterations`/`max_total_queries` interact conditionally. Filters (year/conference/venues) are left to the schema, which is reasonable given their clarity.

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 function: judging whether gathered evidence is sufficient, what is missing, and what to search next, with an explicit scope boundary ("without the tool writing the answer"). It names concrete outputs (`evidence_spans`, `next_queries`, per-requirement covered/partial/missing) that differentiate it from search_papers_many and verify_claims.

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

Usage Guidelines4/5

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

The opening clause gives a clear trigger: "Use for a multi-part research task when you need to know whether your gathered evidence is SUFFICIENT." It also states what the tool will not do (write the answer) and how to opt into the draft-checking mode. It nonetheless does not name an alternative sibling (e.g. verify_claims) or state when not to use it, so routing between the verification tools still requires inference.

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

All Lune Research tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.