Skip to main content
Glama
Sign In

Tlacuilo

by io.github.mastercobeos
OverviewDiscussionsAdmin

papers_search

papers_search
Read-only

Full-text search across 250M+ scholarly works in OpenAlex: title, authors, year, venue, type, citation count, open-access status with PDF link, reconstructed abstract (up to 1500 chars) and topics. Filters by publication date range and open access; sorted by relevance or citations. Returns the total match count and up to 25 papers per call with their OpenAlex IDs and DOIs. Price: $0.005 USDC per call (x402).

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": {
      "q": "<q>"
    },
    "name": "papers_search"
  }
}

Input Schema

NameRequiredDescriptionDefault
qYesSearch terms (title, abstract and full text)
sortNorelevance (default) or cited
limitNoPapers to return, 1-25 (default 10)
sinceNoEarliest publication date, YYYY or YYYY-MM-DD (optional)
untilNoLatest publication date, YYYY or YYYY-MM-DD (optional)
open_accessNotrue to return only open-access works, false for closed only (optional)

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=true, the description discloses several operationally critical traits: results are capped at 25 per call, the total match count is returned alongside them, abstracts are truncated to 1500 chars, and each call costs $0.005 USDC via x402. The payment requirement in particular is information an agent cannot get from annotations or schema and would otherwise discover only by failing.

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?

A single dense paragraph that front-loads what is searched, then what comes back, then filters/sorting, then the cost — a sensible order with no filler sentences. Given the absence of an output schema, the result-field enumeration earns its space.

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?

With no output schema, the description carries the return-value burden and does so concretely (field list, total count, 25-per-call cap, abstract truncation, IDs and DOIs). Combined with a fully documented schema and the disclosed per-call price, an agent has what it needs to call this correctly and budget for it.

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 q, sort, limit, since, until and open_access are already fully documented in the schema. The description restates the date-range and open-access filters and the sort modes without adding syntax or edge-case meaning (e.g. inclusive/exclusive bounds, sort tie-breaking), so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ("Full-text search across 250M+ scholarly works in OpenAlex") and enumerates what each result carries (title, authors, year, venue, citation count, OA status, abstract, topics). That is far more than a restatement of the name. It does not explicitly name a sibling such as papers_cite or contrast its scope with it, so it stops short of full sibling differentiation.

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

Usage Guidelines3/5

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

Usage is implied by "Full-text search" plus the stated filters (publication date range, open access) and sort options, which tells an agent the shape of a typical query. However, there is no explicit when-to-use/when-not guidance and no pointer to an alternative tool for citation-graph or lookup-style needs, leaving routing to inference.

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

All Tlacuilo toolsInspect
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.

Resources