Skip to main content
Glama

omniseek_paper_recommend

Recommends semantically-similar papers from a seed paper ID using SPECTER embeddings, surfacing conceptually related work, including recent papers, that keyword search and citations miss.

Instructions

Use WHEN you have a paper and want more like it — semantically-similar papers (SPECTER embeddings) that keyword search and the citation graph miss, including very recent work. Uses Semantic Scholar's recommendation model (SPECTER embeddings + co-citation), so it surfaces conceptually-related work that omniseek_search (keyword) and omniseek_field_skeleton (citations) miss — including very recent papers the citation graph has not caught up to.

Fully-qualified MCP name: mcp__omniseek__omniseek_paper_recommend (server name is omniseek; there is no omniseek-eye server).

Pass seed paper ids (arXiv ids / DOIs / S2 ids — a paper you found via omniseek_search or omniseek_field_skeleton). One seed = "more like this"; several = recommendations from that set. This is OmniSeek's "semantic search": it routes to S2's existing embeddings rather than building any. For an openalex omniseek_search result pass metadata.paper_id (or metadata.doi), NOT source_id — the OpenAlex W-id is a graph id the paper tools do not accept.

Returns: {"seeds", "n", "papers": [{id, title, year, date, cited_by, first_author, doi, url}]} (ordered by S2 relevance; YOU re-judge). Citation neighborhood instead → omniseek_field_skeleton; keyword search → omniseek_search.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idsYes
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden. It explains the underlying mechanism (SPECTER embeddings + co-citation), notes that results are ordered by relevance and that the agent should re-judge, and clarifies it uses existing S2 embeddings. It doesn't explicitly state non-destructive behavior or rate limits, but these are reasonably implied for a recommendation tool.

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 long but every sentence adds distinct value: purpose, mechanism, input details, output format, alternatives, and even server naming. Information is front-loaded, starting with the core use case, and the flow is logical.

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 there is no output schema, the description fully specifies the return structure and ordering. It also covers alternative tools, input constraints, and the MCP server context, leaving nothing an agent needs to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides only names and types (0% coverage). The description compensates richly: it specifies acceptable id formats (arXiv, DOI, S2 ids), explains how to pass multiple seeds, and warns against using OpenAlex source_id, which is a common mistake. The limit parameter is not elaborated but its default and obvious purpose make that a minor omission.

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 use case ('Use WHEN you have a paper and want more like it') and explicitly contrasts with sibling tools (keyword search and citation graph), making the tool's purpose unambiguous and distinct.

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?

Provides explicit when-to-use criteria, what inputs to pass (seed paper ids), a critical pitfall for OpenAlex IDs (metadata.paper_id vs source_id), and names alternatives (omniseek_search, omniseek_field_skeleton) with the conditions that select them.

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