Skip to main content
Glama

search_keyword

Pure keyword (BM25) search — fastest option, optimal for exact-term lookups: paper titles, author names, method names (e.g. "LoRA", "RLHF"), arXiv IDs. Does NOT use semantic vectors. Use this when you know the specific term you're looking for. For paraphrased or conceptual queries, prefer "search_semantic" or "search". ★ Ranking is over at most 20 000 matching chunks: a COMMON term (or any_words over several) overflows that, and then pool.keyword.truncated=true says the ranking covered only the earliest-stored matches — narrow the query to get a full ranking. This is what keeps an answer under a few seconds instead of minutes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax results to return
matchNoHow the words are combined. DEFAULT 'all_words' — EVERY word must appear in the chunk, which is why long queries often return nothing. ⚠️ MEASURED 2026-09-11 over archived all_words traffic: 6-10 word queries CAME BACK empty 78% of the time on this door — a figure about that traffic under that mode, which this parameter exists to change. Adding more words makes the default stricter, not broader. ⚠️ Matching happens INSIDE ONE CHUNK, so that figure depends on the CURRENT chunking policy as much as on the mode — re-measure if you need a current one rather than relying on this. stricter, not broader. Use 'any_words' to find chunks matching ANY of them, and 'phrase' for the words adjacent and in order. ⚠️ Writing `or` in the query text does NOT ask for any_words — it is dropped as a stop word; name the mode instead.
queryYesSearch query — exact terms work best (method names, IDs, titles). NOTE: BM25 ranks by chunk-level term frequency; for canonical paper lookup by exact name (e.g. "LoRA" → original LoRA paper), prefer find_by_id by arxivId or title-search. This tool may surface papers that mention the term frequently but are not the canonical source.
dateToNoFilter: published on or before (ISO date)
detailNo'minimal' = id+title+snippet+score. 'standard' = adds metadata + chunkContext. 'full' = adds entities/selfContained/scores/licenses map
facetsNoIf true, return facets block: count breakdown by contentType + top entities mentioned
run_idNoOptional. The active methodist run_id (as returned by the methodist diagnose / get_current_dose door). Pass it whenever you call this tool while working inside a run, so the call is attributed to that run for the §8 usage crosscheck — attribution is run-anchored, so it stays correct even if your access token refreshes mid-run. Must be YOUR run: a run_id owned by a different principal, or a non-existent run_id, is rejected.
dateFromNoFilter: published on or after (ISO date)
entitiesNoSoft filter by entity (method names like "BERT", datasets like "SQuAD", metrics like "BLEU"), case-insensitive. Matching chunks rank first; chunks with no entities recorded (legacy gap) fall to the bottom rather than being dropped; chunks with non-matching entities are excluded.
categoriesNoFilter by arXiv categories (e.g. cs.AI, cs.LG)
contentTypeNoFilter chunks by type. Use [methodology] for HOW researchers approach a problem; [results] for OUTCOMES; [survey, background] for context
diversifyByNo'document' (default): max N chunks per paper. 'keyConcept': diversify by main idea (good for landscape view). 'contentType': mix methodology/results/etc.document
maxPerDocumentNoMax chunks per single key (only when diversifyBy=document)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / match
      Added value: +{
      +  "description": "How the words are combined. DEFAULT 'all_words' — EVERY word must appear in the chunk, which is why long queries often return nothing. ⚠️ MEASURED 2026-09-11 over archived all_words traffic: 6-10 word queries CAME BACK empty 78% of the time on this door — a figure about that traffic under that mode, which this parameter exists to change. Adding more words makes the default stricter, not broader. ⚠️ Matching happens INSIDE ONE CHUNK, so that figure depends on the CURRENT chunking policy as much as on the mode — re-measure if you need a current one rather than relying on this. stricter, not broader. Use 'any_words' to find chunks matching ANY of them, and 'phrase' for the words adjacent and in order. ⚠️ Writing `or` in the query text does NOT ask for any_words — it is dropped as a stop word; name the mode instead.",
      +  "enum": [
      +    "all_words",
      +    "any_words",
      +    "phrase"
      +  ],
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • removedInput schema / properties / detail / default
      Removed value: -"full"
  3. Changed1 schema field changed
    • changedInput schema / properties / detail / default
      Previous value: -"standard"New value: +"full"
  4. First observed

TDQS

A4.6/5.0
Behavior4/5

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

No annotations are provided, so the description correctly carries the behavioral burden. It discloses that BM25 does not use semantic vectors, that ranking covers at most 20,000 chunks, that common terms can cause truncation with pool.keyword.truncated=true, and why this behavior keeps responses fast. A short note about returned result structure or pagination would make it more complete, but the key operational traits are covered.

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?

The description is front-loaded: first sentence establishes the tool's core nature, second sentence states when to use alternatives, and third explains a crucial practical limit with the remedy. The star marker draws attention to the truncation caveat. Every sentence earns its place and there is no filler.

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 search tool with 13 params and no output schema, the description covers selection logic, behavioral limits, and performance trade-offs well. The input schema already documents each parameter richly. The only residual gap is the absence of any statement about what the response contains beyond the detail-level enum, but the schema's detail parameter partially fills that.

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 further clarifies the query parameter: exact terms work best, BM25 ranks by chunk-level term frequency, and for canonical paper lookup one should prefer find_by_id by arxivId or title-search. It does not add per-parameter meaning for all 13 params, but the schema already does that; the extra paragraph materially improves query semantics.

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 description names a specific verb and resource ('Pure keyword (BM25) search') and enumerates concrete use cases such as paper titles, author names, method names, and arXiv IDs. It explicitly contrasts itself with semantic search, so an agent can disambiguate it from search_semantic and search without opening their schemas.

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?

Usage conditions are explicit: 'Use this when you know the specific term you're looking for' and 'for paraphrased or conceptual queries, prefer search_semantic or search.' It also warns when the tool should be narrowed due to the 20,000-chunk ranking cap, giving the agent actionable when-to-use versus when-not-to-use guidance.

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.