RBAi Scholar

Search papers by exact terms

search_corpus_keyword

Read-onlyIdempotent

KEYWORD/Boolean search over the same 11M+ biomedical abstracts, matching EXACT TERMS rather than meaning. Use this instead of search_corpus when the query contains specific identifiers — gene symbols (TP53, BRCA1), variants (p.Gly12Asp, c.35G>A, rs334), accessions, clinical-trial IDs (NCT…), cell lines, drug codes — or when you want PubMed-style Boolean logic. Vector search loses the exact identity of rare strings, so keyword mode is substantially better for these queries and worse for open natural-language questions. Syntax: terms are ANDed by default; AND / OR / NOT are supported; prefix a term with - to exclude it; use "quoted phrases" for exact adjacent wording. A very broad query is ranked over its best BM25 matches.

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_corpus_keyword"
  }
}

Input Schema

Name	Required	Description
`doi`	No	Exact DOI (e.g. "10.1021/acs.biochem.6c00105"), in any case, with or without https://doi.org/ (optional)
`pmid`	No	PubMed ID (e.g. "42130315") (optional)
`topK`	No	Number of results to return (default 20, max 100)
`type`	No	Article type filter (optional). Nearly every paper in the corpus has type "article", so this filter rarely narrows a search. To find reviews, put the word "review" in the query instead.
`query`	Yes	Keyword or Boolean query, e.g. 'TP53 AND apoptosis NOT mouse' or 'BRCA1 "triple negative breast cancer"'. Include at least one distinctive term.
`author`	No	Author name, matched as whole words in the order typed, case-insensitive (optional)
`yearTo`	No	Only papers up to this year (optional)
`journal`	No	Journal name, matched as whole words in the journal field, case-insensitive ("Nature" also finds Nature Medicine) (optional)
`language`	No	Language code filter, e.g. "en" (optional)
`oaStatus`	No	Open-access status: "open", "green", "gold", "closed" (optional)
`yearFrom`	No	Only papers from this year onwards (optional)
`titleSearch`	No	Words of the paper title, matched as whole words in the order typed, case-insensitive (optional)
`isOpenAccess`	No	Only open-access papers (optional)
`minCitations`	No	Minimum citation count (optional)

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 12, 2026

changedInput schema / properties / type / description

Previous value: -"Article type filter (optional)"New value: +"Article type filter (optional). Nearly every paper in the corpus has type \"article\", so this filter rarely narrows a search. To find reviews, put the word \"review\" in the query instead."

First observedNov 12, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description goes well beyond that by disclosing query semantics (default AND, AND/OR/NOT, leading '-' for exclusion, quoted phrases for adjacency) and ranking behavior (broad queries ranked over best BM25 matches), which materially changes how an agent should phrase a call.

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 purpose, then routing rule, then syntax, then ranking — a sensible order with no filler. It is dense, and the rationale sentence about vector search losing rare strings slightly overlaps with the earlier routing sentence, but every sentence adds distinct information.

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 14-parameter search tool with no output schema, the definition covers what to search, how to phrase queries, and how results are ranked. It stops short of describing result shape or pagination beyond the topK parameter, which is a minor gap given the ranking note.

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?

Schema description coverage is 100%, so the baseline is 3; the description earns the extra point by documenting the syntax of the required query parameter in a way the schema's two short examples do not. It does not discuss the many filter parameters, but the schema already carries meaning for those.

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 verb and resource (keyword/Boolean search over 11M+ biomedical abstracts) and immediately contrasts it with its sibling: EXACT TERMS rather than meaning, versus search_corpus. The scope and mode are unmistakable without opening the schema.

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?

Gives an explicit routing rule: use this instead of search_corpus when the query contains gene symbols, variants, accessions, trial IDs, cell lines, or drug codes, or when Boolean logic is needed. It also states the negative case — keyword mode is worse for open natural-language questions — so the agent knows both sides of the decision.

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

All RBAi Scholar 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.

Resources

Need Help?