Skip to main content
Glama

Scholar Feed

Find Research Gaps

find_gaps
Read-only

Find important work you HAVEN'T saved, for a collection or topic — a 'what am I missing?' analysis. Returns two buckets: foundational_gaps (canonical citation-graph anchors in the niche, not in your library) and frontier_gaps (recent high-novelty work in the niche, not yet saved). Provide exactly one seed: collection_name OR collection_id OR topic. The backend derives the niche, runs lineage + recent-novelty search, and subtracts your saved set. Read-only. Requires SF_API_KEY (it needs your library to subtract) and is a Pro feature — free accounts receive an upgrade prompt.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax gaps per bucket (max 50). Default 10.
scopeNoWhich gaps to surface: 'foundational' (canonical anchors you're missing), 'frontier' (recent novel work you haven't saved), or 'both' (default).both
topicNoAnalyze gaps for a free-text topic/area. Provide exactly one seed.
collection_idNoAnalyze gaps for a collection by UUID. Provide exactly one seed.
collection_nameNoAnalyze gaps for a collection by name (resolved by the backend). Provide exactly one seed.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okNo
messageNo
frontier_gapsNoRecent high-novelty work you haven't saved.
foundational_gapsNoCanonical anchors in the niche not in your library.

Schema Changelog

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

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses that the tool subtracts the user's saved set, derives the niche from the seed, runs lineage and novelty searches, and requires SF_API_KEY plus Pro access. It also states the free-account upgrade prompt behavior, adding valuable operational context.

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 compact, front-loads the core value proposition, and every sentence adds either semantics, constraints, or operational context. It avoids repeating schema details and remains easy to scan.

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 an output schema present and the annotations covering safety, the description supplies the remaining context needed to select and invoke the tool correctly: seed exclusivity, bucketing logic, auth/Pro requirement, and behavior. Nothing critical is missing.

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 coverage is already 100%, but the description adds the critical 'exactly one seed' constraint and explains what each bucket means, mapping to the scope enum. It reinforces that collection_name is resolved by the backend, which is useful beyond the raw schema.

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 ('find important work you HAVEN'T saved') and clarifies the output as two gap buckets. This distinctly separates it from sibling search and lineage tools, which query saved or cited work rather than subtracting the user's library.

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?

The description clearly frames when to use the tool ('a what am I missing? analysis') and specifies the exact-seed rule. It does not explicitly contrast with alternatives like search_papers or get_foundational_lineage, but the context makes the intended use obvious.

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.