Skip to main content
Glama
michalhron

Scopus Plus MCP

by michalhron
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

resolve_citers

Find and verify papers citing seed papers using multiple strategies; report confirmed citers and flag ones Scopus misses via OpenAlex and Semantic Scholar cross-checks.

Instructions

All papers citing one or more seed papers, found by several search strategies at once and verified. Runs REF() on each seed plus any extra queries (for example a title-phrase query), merges the hits, then checks each hit's own reference list for the seeds. Reports a per-strategy table (hits, confirmed, unconfirmed, verification failed, confirmed citers the strategy missed). With cross_check (default on when scope is given) it also asks OpenAlex and Semantic Scholar which in-scope papers cite the seeds and lists those Scopus misses or cannot confirm, with Scopus's reference count against the external one, so truncated Scopus reference lists become visible. The Scopus result stays Scopus-only. Long runs may return a job ID: poll job_status, then job_result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scopeNoRestrict to journals, by ISSN: a list of ISSNs, or a basket name ('basket_of_eight' / 'ais8': the AIS Senior Scholars' Basket of Eight). ISSNs are used rather than journal names, which Scopus spells inconsistently.
inlineNo'compact' (default): every hit as one JSON line (ID, DOI, year, title, status, seeds found in its references, strategies). 'summary': counts only.compact
sourceNoData source. 'scopus' (default) needs subscriber entitlement for search, citations and references. 'openalex' needs none: IDs may be DOIs, OpenAlex work IDs (W...), or Scopus IDs (resolved to a DOI via Scopus metadata), and results carry OpenAlex IDs. Never mix sources within one analysis.scopus
verifyNoCheck each hit's reference list for the seeds (default true).
queriesNoExtra search strategies, e.g. REF("organizing vision") or REFAUTH(swanson) AND REFTITLE("organizing vision").
seed_idsYesSeed papers (Scopus IDs/EIDs; with source='openalex', DOIs or OpenAlex IDs), e.g. both papers of a construct's origin.
cross_checkNoScopus only: list in-scope citers that OpenAlex or Semantic Scholar know and Scopus misses (default: on when scope is set).
max_resultsNoCap on hits per strategy (default 1000).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses the REF()/merge/verify pipeline, the per-strategy table contents, that cross_check consults OpenAlex and Semantic Scholar while 'the Scopus result stays Scopus-only', and that long runs may return a job ID requiring polling. This is behavior beyond what any structured field provides.

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?

Three dense sentences, front-loaded with purpose and workflow before the cross-check and job-ID caveats. Efficient, though the middle sentence is information-heavy and could be split for readability.

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 complex multi-strategy tool with no output schema and no annotations, the description covers the return shape (per-strategy table, counts, misses) and the async job path adequately. Minor gaps remain around error/entitlement failure behavior, but an agent has enough to call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all 8 parameters, including scope's ISSN rationale, inline modes, source entitlements, and cross_check defaults. The description largely restates this (e.g. cross_check default, queries examples) rather than adding new semantic detail, so baseline 3 applies.

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 precise verb+resource ('all papers citing one or more seed papers') and immediately scopes it with the mechanism ('several search strategies at once and verified'). The multi-strategy + verification framing implicitly distinguishes it from the simpler sibling get_citing_papers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains the internal workflow but never states when to pick this over siblings like get_citing_papers or search_scopus. It does give operational guidance for long runs ('poll job_status, then job_result') and notes cross_check defaults on when scope is set, but no explicit when/when-not or alternative routing.

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

Deploy Server

Other Tools