Skip to main content
Glama

Scholar Feed

Search Papers

search_papers
Read-only

Search Scholar Feed's 600k+ CS/AI/ML paper corpus. Semantic (embedding) search by default, so it finds conceptually related work even when the wording differs. EVERY PARAMETER DOCUMENTS ITS OWN BEHAVIOUR AND COVERAGE LIMITS — read the ones you intend to use; this description covers only what no single parameter can tell you. RETRIEVAL LIMIT: semantic ranking favours recent, stylistically-matched papers and routinely MISSES the old high-citation anchor of a field (H2O for KV eviction, GRIT for unified embedding+generation). To reach a field's canonical work, read the top-5 abstracts for repeated baseline mentions ('we compare against X') and look that name up directly, or call get_foundational_lineage. THREE UNRELATED NOTIONS OF IMPACT, easily confused: proven citations (sort='impactful', min_citations) | a ~90-day forecast percentile that is NULL on older papers and therefore excludes them (sort='trending', impact_min) | GitHub adoption (sort='community', min_stars). YOUR LIBRARY IS MARKED INLINE on authenticated calls: each hit carries is_saved and is_read, and a hit you previously annotated carries note_text — your own earlier verdict. Read note_text INSTEAD of re-deriving a conclusion from the abstract; re-judging a paper you already ruled on is the most common way an agent wastes a research session. is_saved=false is a real measurement; on anonymous calls these keys are absent entirely, so never read a missing is_saved as false. Papers new to you are ranked exactly as before — nothing is demoted for being unseen.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoSearch query keywords. REQUIRED unless (a) anchor_paper_id or scope_to_citations_of is set (anchor mode ignores q and returns papers similar to the anchor), or (b) sort is one of 'trending' / 'recent' / 'impactful' — the query-less 'browse the frontier' feed, which is capped to the FIRST 200 RESULTS (paging past offset 200 is a 422; narrow with q= or filters instead). Any other q-less call is a 422, INCLUDING a q-less call with only filters (category/days/...) and a q-less sort='community'. Filters alone do NOT substitute for q — pair them with a browse sort (e.g. category='cs.AI' + sort='recent') or pass q. For 'what's hot in AI right now', either sort='trending' alone or a broad q plus sort='trending' works.
daysNoLimit to papers published within N days
modeNoSearch mode. 'semantic' (default) uses embedding similarity — finds conceptually related papers even without exact keyword matches. 'keyword' uses Postgres full-text search — faster but only matches exact terms.
pageNoPage number
sortNoResult ranking — a relevance↔impact dial plus time-based and adoption orders. 'relevance' (default) = best topical match. 'balanced' = relevant AND well-cited. 'impactful' = the most-cited (proven-influential) papers among those relevant to the query — use this for 'the important/seminal papers on topic X'. 'trending' = rising/FORECAST impact (impact_pct, last ~90 days) — use for 'what's hot/new in X', NOT for established work. 'recent' = newest first. 'community' = GitHub adoption (stars + star-velocity) — surfaces the papers practitioners are actually running/building on, independent of citations. COVERAGE CAVEAT (the analogue of impact_min's ~90-day hole): an unfetched repo stores 0 rather than NULL, and coverage skews heavily toward recently-published papers, so most older papers with a repo currently rank as 0-star and sink — 'community' reflects measured adoption, not corpus-wide adoption. Proven impact ('impactful'/'balanced') ranks by real citations; 'trending' is a model prediction; 'community' is real-world engineering traction within its window. Pair with get_foundational_lineage for a topic's canonical roots.
taskNoFilter by task e.g. 'image classification', 'question answering' (partial match)
limitNoResults per page (max 50)
cursorNoCursor from previous response's next_cursor for keyset pagination
fieldsNoComma-separated list of fields to return (e.g. 'arxiv_id,title,llm_summary,llm_novelty_score'). If omitted, returns the lean 12-field default unless verbose=true.
datasetNoFilter to papers that evaluate on a specific dataset e.g. 'MMLU', 'ImageNet'
verboseNoIf true, returns the full 28-field paper shape (method/task/dataset extraction, application_domain, baselines, etc.). Default false returns the lean 12-field set. Ignored when `fields` is provided.
categoryNoFilter by arXiv category e.g. 'cs.AI', 'cs.LG'
has_codeNoFilter to papers with a linked code release (has_code=true). Surfaces runnable/reproducible work — pair with min_stars/sort='community' to find the papers practitioners actually adopt.
min_starsNoMinimum GitHub stars on the paper's linked repo. A proxy for engineering adoption — surfaces work that practitioners are actually running/building on. Pair with sort='community' to rank by it. COVERAGE CAVEAT: a never-fetched repo is stored as 0, not NULL, so this filter cannot distinguish 'no adoption' from 'never measured'. It is applied as 'KNOWN to have >= N stars' — papers whose stars were never fetched are excluded rather than treated as 0-star, so the result is honest but INCOMPLETE: a genuinely popular older paper can be missing simply because nobody measured it. Coverage skews toward recently-published papers and is being backfilled. Use it to filter recent work; for established papers use min_citations instead.
impact_minNoMinimum impact_pct (0-100), e.g. 80 = top 20% FORECAST impact. This is a RISING-WORK filter: impact_pct is only computed for the last ~90 days, so impact_min restricts results to recent papers predicted to land well AND DROPS everything older. Use it for 'what's rising in X'. Do NOT use it to find the influential/seminal papers in a topic — that excludes the established work; use sort='impactful' instead.
exclude_idsNoarXiv IDs to exclude from results (for deduplication across chained calls)
method_nameNoFilter to papers introducing/using a specific named method e.g. 'LoRA', 'YOLO', 'DPO'. Case-insensitive substring match on the extracted method_name field.
novelty_minNoMinimum novelty score (0-1). Use 0.5+ for novel papers.
min_citationsNoMinimum real citation count. Unlike impact_min (a ~90-day FORECAST percentile), this filters on PROVEN citations and keeps established/canonical papers.
task_categoryNoFilter by broad research area
anchor_paper_idNoReturn papers similar to this arXiv paper ID. When set, q is ignored and results carry similarity_score. Example: '2407.15831'.
method_categoryNoFilter by method category e.g. 'reinforcement learning', 'transformer'
published_afterNoOnly papers published on or after this date, 'YYYY-MM-DD'. Use with published_before to bound an arbitrary date window (days only gives a rolling N-day lookback).
published_beforeNoOnly papers published on or before this date, 'YYYY-MM-DD'. Pair with published_after for an explicit window.
contribution_typeNoFilter by paper's contribution type
github_url_existsNoFilter on whether the paper has a linked GitHub URL (true = only papers with a repo). Stricter than has_code (which counts any code link).
scope_to_citations_ofNoRestrict search to this paper's citation graph, ranked by relevance to q. Pass the arXiv ID of the paper whose citations you want to search within.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
modeNoSearch mode actually applied.
noteNo
pageNo
sortNoSearch sort order actually applied.
limitNo
topicNo
totalNoTotal results available for the query. null when the count was skipped (query-less browse, or the count query timed out).
papersNoMatched / returned papers.
directionNoCitation direction (get_citations: citing | cited_by).
not_foundNoRequested IDs that had no match.
next_cursorNoKeyset cursor for the next page, or null when exhausted.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=true and destructiveHint=false, but the description goes far beyond that: it discloses the retrieval limit, the recency/style bias that misses canonical papers, the difference between proven citations, forecast impact, and GitHub adoption, and the fact that is_saved=false is meaningful only on authenticated calls. This is a rich behavioral contract that prevents the agent from misinterpreting results.

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?

The description is long and uses ALL-CAPS emphasis, which slightly hurts skimmability, but it is well-labeled and information-dense with every section serving a purpose. The front-loaded core definition, followed by retrieval-limit caveats, impact-mode distinctions, and library-state semantics, gives an agent the most important facts early.

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?

Given the tool's complexity (27 parameters, 100% schema coverage, and an output schema), the description covers the cross-cutting concerns that no single parameter could convey: retrieval biases, the q-less browse rules, anonymous vs authenticated result differences, and the meaning of saved/read/note_text fields. There is no obvious gap that would prevent an agent from using this tool correctly.

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, but the description adds cross-parameter meaning by synthesizing the three notions of impact and warning that filters like impact_min and min_stars have coverage holes. It also instructs the agent to read each parameter's own documentation, which is appropriate for 27 parameters. It does not need to repeat schema details, and it contributes enough contextual nuance to warrant a 4.

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 opens with a specific verb and resource: 'Search Scholar Feed's 600k+ CS/AI/ML paper corpus.' It immediately clarifies that semantic embedding search is the default, which differentiates it from keyword search and gives the agent a precise mental model of what the tool does. It also names get_foundational_lineage as the complementary tool for finding canonical work, helping distinguish its scope from a sibling.

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?

The description gives explicit when-to-use and when-not-to-use guidance: for canonical work it says to read top abstracts or 'call get_foundational_lineage', and for rising work it says 'Do NOT use it to find the influential/seminal papers... use sort='impactful' instead.' It also warns about the q-less 422 cases and when paired filters are needed, giving agents actionable decision rules.

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.

TDQS

A4.3/5.0
Disambiguation4/5

Most tools target a distinct resource and action — search vs. saved-library synthesis vs. citation analysis vs. article metadata — and the descriptions explicitly cross-reference one another to reduce confusion. A few retrieval/analysis tools (get_field_orientation, get_foundational_lineage, get_citations, check_drift) have adjacent purposes and could be misselected without reading their descriptions carefully.

Naming Consistency4/5

The overwhelming majority follow a clear verb_noun snake_case pattern: create_watch, delete_watch, list_library, save_paper, annotate_paper, fetch_fulltext, search_papers. Minor deviations like co_author_graph and the interchangeable retrieval verbs (search, find, get, check, ask) create slight inconsistency, but the overall convention is predictable.

Tool Count3/5

27 tools is on the heavy side, but the server covers several coherent subdomains: search/discovery, library/collection management, watches, annotations, and research analysis. The count is justifiable for the broad purpose, though some of the discovery/analysis tools could likely be consolidated or split into a separate server.

Completeness4/5

The tool surface covers the core lifecycle well: search, fetch, save, organize into collections, annotate, watch for new papers, and analyze citations/authors/gaps. Minor gaps exist — there is no collection deletion/rename, no explicit mark-as-read tool, and no unlike operation — but these are workable edge cases rather than blocking omissions.