Skip to main content
Glama

Search scholarly papers

search_papers
Read-only

Search Rivul Index and return structured scholarly metadata. Free under fair-use rate limits. Each call adds 2 to this workspace's MCP usage count, which usage_status reports.

Each result is a short record -- id, title, year, first 3 authors, citation count, doi and a 200-character snippet. The full record for a result (complete snippet, every author held, venue, work type, topic, field and open-access links) is available from get_paper_details by its openalex_id.

Results come from a dated OpenAlex snapshot, not live data; meta.snapshot_at gives the snapshot date. Every field is as OpenAlex recorded it on that date and is not independently verified: OpenAlex records can be wrong, and a small number have been corrupted upstream by predatory mirrors that overwrite a real paper's date, DOI and open-access link while leaving its title, authors and abstract intact. openalex_id is the stable identifier; a doi may not resolve.

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": {
      "query": "<query>"
    },
    "name": "search_papers"
  }
}

Input Schema

NameRequiredDescriptionDefault
sortNorelevance
fieldNoOpenAlex display name, matched exactly (case-sensitive); surrounding and repeated spaces are removed.
limitNo
queryYes
topicNoOpenAlex display name, matched exactly (case-sensitive); surrounding and repeated spaces are removed.
offsetNo
year_maxNo
year_minNo
min_citationsNoRounded down to the nearest of 0, 10, 50, 100, 500, 1000, 5000, 10000.
open_access_onlyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior5/5

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

Beyond readOnlyHint and destructiveHint=false, the description discloses fair-use rate limits, a per-call cost of 2 on the workspace usage count, a dated snapshot rather than live data, and a concrete upstream data-corruption failure mode. It also tells the agent that openalex_id is stable while a doi may not resolve, which materially changes how results should be trusted.

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?

Purpose is front-loaded, then cost, then result shape, then data provenance and caveats — a logical order with no filler sentences. It is on the long side, but each paragraph carries distinct operational information such as cost accounting and the corrupted-record warning.

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

Completeness4/5

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

For a 10-parameter search tool with no output schema, the description covers return shape, pagination-adjacent cost, snapshot dating and trust caveats well. The remaining gap is that most filter and sort parameters are never described, though their names and enum values are largely self-explanatory.

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

Parameters2/5

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

Schema description coverage is only 30% across 10 parameters, so the description carries the burden — but it explains no parameters at all. sort, limit, offset, year_min/year_max, open_access_only and query are left entirely to their names and schema constraints, and only field, topic and min_citations have schema-level notes the description does not extend.

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 first sentence names a specific verb and resource ('Search Rivul Index') and states the return type ('structured scholarly metadata'). It also distinguishes itself from the sibling get_paper_details by describing search results as short records versus the full record from that tool.

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 description gives clear routing guidance: use this tool for short records and get_paper_details with an openalex_id for the full record, plus it points to usage_status for the call counter. It does not state explicit exclusions or when search would be the wrong choice, which keeps it below a 5.

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.

Resources