Skip to main content
Glama
X Literature MCP

X Literature MCP

by JiahongXu88

Search papers

search_papers
Read-only

Search local academic PDFs by keyword in Chinese or English, returning paper ID, page, and snippet so you can locate relevant text and re-read hits with read_paper_pages.

Instructions

Keyword search over page text (Chinese/English substring, whitespace- and width-insensitive; multiple space-separated terms must all occur on the same page). Returns paper_id + page + snippet; re-read hits with read_paper_pages. Query ≤ 200 chars.

Input Schema

NameRequiredDescriptionDefault
limitNodefault 20
queryYes
paper_idsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond readOnlyHint/openWorldHint, it discloses the exact matching algorithm, the AND-across-terms rule, the 200-char query cap, and the return payload shape (paper_id + page + snippet). It does not state the search scope when paper_ids is omitted (all papers vs. an indexed subset) or how limit interacts with hit ordering, but the behavioral core is disclosed.

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

Conciseness5/5

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

Three dense clauses, front-loaded with the operation and followed by the matching rules and the next-step hint. No filler, no restatement of the tool name or title.

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?

With no output schema, the description usefully explains the return shape itself, and the matching semantics cover the hardest-to-guess behavior. The remaining hole is scoping: an agent cannot tell whether omitting paper_ids searches the whole library or only the current context.

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 only 33%, so the description is expected to compensate. It explains the query parameter's semantics and length limit well, but says nothing about paper_ids (that it restricts the search to specific papers) or limit (default 20 is only in the schema), leaving two of three parameters uninterpreted.

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?

"Keyword search over page text" gives a specific verb (search) and resource (page text), and the parenthetical spells out the matching model precisely (Chinese/English substring, whitespace/width-insensitive, AND across terms). No sibling performs search, so the tool is unambiguous without needing disambiguation.

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?

It names the downstream step explicitly ("re-read hits with read_paper_pages"), which tells the agent this is a discovery tool, not a retrieval tool. It stops short of contrasting with list_papers or get_paper_structure, so an agent browsing broadly still has to infer when keyword search beats enumeration.

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