Which integrations are available for this server?

Enables searching and retrieving recent publications and metadata from arXiv. Planned integration to search and retrieve papers from IEEE Xplore. Planned integration to search and retrieve papers with associated code from Papers With Code. Planned integration to search and retrieve biomedical literature from PubMed. Enables searching and retrieving academic papers, citations, and open-access links from Semantic Scholar.

How do I use Research Intelligence MCP?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Research Intelligence MCP Find recent papers about Agentic RAG." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Research Intelligence MCP

by supuni9622

Overview Schema Related Servers Score Discussions

Python

Remote

Research Intelligence MCP

A production-structured Model Context Protocol (MCP) server for academic paper discovery, citation exploration, and research intelligence workflows.

Research Intelligence MCP provides a unified interface over multiple scientific knowledge sources while exposing standardized MCP tools that can be consumed by AI systems such as ChatGPT, Claude Desktop, Cursor, ResearchMind, and custom agents.

claude_connector

connector

Connects as a standard MCP server into Claude Desktop, Cursor, or applications like ResearchMind

search papers One query fans out across Semantic Scholar, arXiv, and returning a single unified result set.

research_papers Rich, structured paper metadata — abstracts, citations, and open-access links — surfaced directly in conversation.

Motivation

Modern AI systems increasingly require access to external research knowledge.

Academic information is fragmented across multiple providers:

Semantic Scholar
arXiv
OpenAlex
CrossRef
PubMed
IEEE
Springer
Nature

Every provider exposes different APIs, schemas, identifiers, and capabilities.

This project solves that problem by providing:

Unified paper models
Provider abstraction
Search federation
Citation graph exploration
Open-access paper resolution
MCP-compatible tooling

Features

Current Version

Academic Search

Search scientific papers
Search recent arXiv publications
Retrieve paper metadata
Discover related papers
Retrieve citations and references
Resolve available open-access PDFs

Architecture

Official MCP Python SDK
Async Python architecture
Provider abstraction layer
Canonical domain models
Structured logging
Retry policies
Caching support
Rate limiting support
Production-quality project structure

Supported Providers

Related MCP server: Academic Paper MCP HTTP/SSE Server

Phase 1

Semantic Scholar
arXiv

Planned Providers

CrossRef
OpenAlex
Papers With Code
PubMed
IEEE
Springer Nature

Example Use Cases

Find recent papers

Find recent papers about Agentic RAG.

Find papers related to LangGraph multi-agent systems.

Citation exploration

What papers cite the original RAG paper?

Open-access resolution

Find the PDF for this research paper.

Research agent integration

ResearchMind
        ↓
Research Intelligence MCP
        ↓
Semantic Scholar
arXiv

Architecture

┌──────────────────────┐
│      MCP Tools       │
└──────────┬───────────┘
           │
┌──────────▼───────────┐
│      Services        │
└──────────┬───────────┘
           │
┌──────────▼───────────┐
│ Provider Abstraction │
└──────────┬───────────┘
           │
 ┌─────────┴─────────┐
 │                   │
▼                     ▼
Semantic Scholar     arXiv

Project Structure

research-intelligence-mcp/
├── src/
│   └── research_intelligence_mcp/
├── tests/
├── scripts/
│   └── generate_dev_token.py
├── deployment/
│   ├── ecs/
│   │   ├── task-definition.json
│   │   ├── service-connect-example.json
│   │   └── README.md
│   ├── observability/
│   │   ├── prometheus.yml
│   │   └── grafana/
│   └── scripts/
│       ├── smoke_test.py
│       └── wait_for_ready.py
├── Dockerfile
├── .dockerignore
├── docker-compose.yml
├── pyproject.toml
├── README.md
└── .env.example

Requirements

Python 3.12+
uv
Git

Installation

Clone repository:

git clone <repository-url>
cd research-intelligence-mcp

Create virtual environment:

uv venv
source .venv/bin/activate

Install dependencies:

uv sync

Create environment file:

cp .env.example .env

Running

Run the MCP server:

uv run research-intelligence-mcp

python -m research_intelligence_mcp

Quality Checks

Format:

uv run ruff format .

Lint:

uv run ruff check .
uv run ruff check . --fix

Type checking:

uv run mypy src

Tests:

uv run pytest

Package build verification:

uv build

MCP Configuration Example

{
  "mcpServers": {
    "research-intelligence-mcp": {
      "command": "uv",
      "args": [
        "--directory",
        "/absolute/path/to/research-intelligence-mcp",
        "run",
        "research-intelligence-mcp"
      ]
    }
  }
}

For full step-by-step instructions covering Claude Desktop, Cursor, MCP Inspector, and remote streamable-http clients (including bearer-JWT authentication), see docs/research_intelligence_mcp_client_setup.md.

Test using MCP Inspector

The official MCP Inspector is the recommended interactive tool for viewing registered MCP tools, their schemas, parameters, and execution results. project root, run:

npx @modelcontextprotocol/inspector \
  uv \
  --directory "$(pwd)" \
  run \
  research-intelligence-mcp

The Inspector should open in your browser.

Then: Connect to MCP Server Open the Tools tab. List tools Select health_check. Run the tool.

Expected structured result:

{
  "status": "healthy",
  "service": "Research Intelligence MCP",
  "server_name": "research-intelligence-mcp",
  "version": "0.1.0",
  "environment": "development",
  "transport": "stdio",
  "timestamp": "2026-07-20T..."
}

mcp inspector

Startup flow

main()
  │
  ├── load settings
  ├── configure stderr logging
  ├── build dependency container
  ├── create FastMCP server
  ├── register tools
  └── run stdio transport

MCP Tools

Search Tool

Remote Deployment and Authentication

For the full deployment guide (Docker, AWS ECS, secrets, smoke tests, and the remaining manual AWS steps), see docs/research_intelligence_mcp_deployment_guide.md. The summary below covers the basics.

stdio remains the default local transport and requires no authentication.

For remote deployments (for example, integrating with ResearchMind), the server also supports a streamable-http transport with service-to-service bearer-JWT authentication:

MCP_TRANSPORT=streamable-http
AUTH_ENABLED=true
AUTH_ISSUER=https://auth.researchmind.ai
AUTH_AUDIENCE=research-intelligence-mcp
AUTH_JWKS_URL=https://auth.researchmind.ai/.well-known/jwks.json

See docs/research_intelligence_mcp_authentication.md for the full architecture, docs/research_intelligence_mcp_authentication_testing.md for a verified step-by-step guide to testing it locally, and .env.example for every AUTH_* and MCP_* setting.

On streamable-http, the server also exposes unauthenticated HTTP routes alongside /mcp:

Route	Purpose
`GET /health`	Liveness only. Never calls Semantic Scholar or arXiv.
`GET /ready`	Readiness. Returns `503` once graceful shutdown has begun.
`GET /metrics`	Prometheus text format (tool, provider, cache, and HTTP metrics). Keep this endpoint network-private.

Container

Build and run the production container:

docker build -t research-intelligence-mcp:local .

docker run --rm -p 8000:8000 --env-file .env research-intelligence-mcp:local

The image defaults to MCP_TRANSPORT=streamable-http, binds 0.0.0.0:8000, runs as a non-root user, and ships a container-level HEALTHCHECK against /health. See Dockerfile and .dockerignore.

AWS ECS

Reference (unapplied) task-definition and Service Connect templates, security-group guidance, and a deployment/rollback runbook live in deployment/ecs/README.md.

Deployment Smoke Tests

uv run python deployment/scripts/wait_for_ready.py --base-url http://127.0.0.1:8000
uv run python deployment/scripts/smoke_test.py --base-url http://127.0.0.1:8000

smoke_test.py checks /health, /ready, /metrics, MCP session initialization, tool discovery, and an authenticated health_check + search_papers call. Pass --auth-token when AUTH_ENABLED=true.

Local Observability Stack

Why

/metrics alone is just a text snapshot of counters at the instant you curl it — it can't tell you if arXiv's error rate spiked five minutes ago, whether the cache is actually paying for itself, or whether search_papers got slower after a change. That requires something to scrape it repeatedly, store the history, and let you look at trends instead of one number. docker-compose.yml runs that: the MCP server, Prometheus, and Grafana, wired together.

docker compose up -d --build

Service	URL	Role
Prometheus	http://127.0.0.1:9090	Collects and stores metrics. Scrapes `/metrics` every 15s into a time-series database and answers PromQL queries (`rate(mcp_tool_requests_total[1m])`, etc.). Its own UI is functional, not built for dashboards.
Grafana	http://127.0.0.1:3002	Visualizes what Prometheus stored. Has no storage of its own here — it queries Prometheus and renders the results as graphs. Pre-provisioned with a Prometheus datasource and a 10-panel dashboard (Dashboards → Research Intelligence MCP, anonymous viewer access, no login needed).
MCP server	http://127.0.0.1:8001	The app itself, on a remapped host port (`8000` is often already in use — change it in `docker-compose.yml` if `8001` collides too).

In short: Prometheus is the database that remembers metrics over time; Grafana is the window you look through to see them — neither is useful here without the other.

What you can actually do with it

Once traffic flows through (uv run python deployment/scripts/smoke_test.py --base-url http://127.0.0.1:8001, or just use the server), the dashboard's 10 panels let you:

Watch tool usage live — which of the 7 MCP tools are actually being called, at what rate, and how their p95 latency moves over time (mcp_tool_requests_total, mcp_tool_duration_seconds).
Catch failures by cause, per tool — a spike in mcp_tool_failures_total{error_type="ValidationError"} vs. {error_type="ProviderTransportError"} tells you immediately whether it's bad input or an upstream outage, without grepping logs.
See which provider is the bottleneck or the one failing — provider_requests_total / provider_failures_total, broken out by provider (Semantic Scholar vs. arXiv) and operation (search, get_paper, citations, ...), so you don't have to guess which one is slow or rate-limiting you.
Judge whether caching is worth it — the cache-hit-ratio panel (cache_hits_total / (hits + misses)) shows, per cache (search vs. paper), whether repeat lookups are actually being served from memory.
Spot HTTP-layer load — request rate by route/status code and in-flight request count, useful for noticing retries, client misbehavior, or load before it becomes a real incident.
Query anything ad hoc in Prometheus directly (http://127.0.0.1:9090/graph) — the dashboard only covers the panels we pre-built; any of the metric names above can be queried and graphed on the fly with PromQL for a question the dashboard doesn't answer.

This stack is for local development only — it is not deployed as part of the ECS setup above (nothing collects these metrics in production yet; see the "remaining manual tasks" in the deployment guide). See docs/research_intelligence_mcp_deployment_guide.md §8 for teardown and more detail.

License

MIT

Available Tools

7 tools

get_paperA

Retrieve canonical metadata for a single academic paper.

Supported identifiers depend on the selected provider and may include:

DOI;
arXiv identifier;
Semantic Scholar paper identifier;
Semantic Scholar CorpusId;
PubMed identifier.

Use arXiv for direct arXiv metadata retrieval. Use Semantic Scholar when richer citation counts, reference counts, publication metadata, and external identifiers are required.

This tool returns provider-neutral structured metadata. It does not summarize the paper or read the full paper content.

ParametersJSON Schema

Name	Required	Description	Default
`paper_id`	Yes
`provider`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`year`	No	Publication year.
`title`	Yes	Paper title.
`venue`	No	Journal, conference, archive, or publication venue.
`access`	No	Paper access and URL information.
`authors`	No	Paper authors in publication order.
`sources`	Yes	Providers contributing metadata to this record.
`abstract`	No	Paper abstract when available.
`identifiers`	Yes	Stable identifiers associated with the paper.
`citation_count`	No	Known citation count.
`fields_of_study`	No	Normalized academic subject areas.
`reference_count`	No	Known reference count.
`publication_date`	No	Known publication date.

TDQS

A4.5/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 discloses that the tool returns 'provider-neutral structured metadata' and states it does not summarize or read the paper. This is sufficient for a typical retrieval tool, though additional details like rate limits or authentication requirements are missing.

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 concise, consisting of seven sentences that are front-loaded with the main purpose. Each sentence adds necessary information without redundancy, and the structure 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 the tool has an output schema (handling return values), the description covers all essential aspects: what it does, supported identifiers, provider-specific guidance, and limitations. It is complete for a two-parameter tool with external schema coverage.

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?

The input schema has 0% description coverage, so the description must add meaning. It explains that supported identifiers for paper_id depend on the provider and lists examples (DOI, arXiv ID, etc.). This adds significant value beyond the schema's minimal definition.

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 clearly states the tool retrieves canonical metadata for a single academic paper. It specifies the verb 'retrieve' and resource 'metadata for a single academic paper', and distinguishes itself from sibling tools like search_papers by focusing on a single paper and from citation/reference tools.

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 provides explicit guidance on when to use each provider: 'Use arXiv for direct arXiv metadata retrieval. Use Semantic Scholar when richer citation counts, reference counts, publication metadata, and external identifiers are required.' It also clarifies what the tool does not do (summarize or read full content). However, it does not explicitly exclude using this tool for tasks better suited to siblings like get_paper_citations.

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

get_paper_citationsA

Retrieve papers that cite a specified academic paper.

This tool traverses the citation graph from an origin paper to papers that cite it. Each returned relationship may include:

canonical citing-paper metadata;
citation contexts;
citation intent labels;
influential-citation status.

Semantic Scholar supports citation graph retrieval. arXiv does not expose a citation graph API and will return a normalized unsupported-operation error.

This tool retrieves structured graph metadata only. It does not synthesize or summarize the citing papers.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`paper_id`	Yes
`provider`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes	Maximum number of relationships requested.
`offset`	Yes	Offset used for the provider request.
`paper_id`	Yes	Identifier of the origin paper.
`provider`	Yes	Provider used for the graph request.
`returned`	Yes	Number of relationships returned.
`references`	No	Canonical citation or reference relationships.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, description fully explains behavior: traverses citation graph, returns specific metadata, provider-specific errors, and excludes synthesis. Missing rate limits or auth but sufficient for a read-like tool.

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?

Well-structured with bullet points and provider note, but slightly verbose. Every sentence adds value, could be tightened.

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?

Given output schema exists, description covers return types, provider differences, and limitations. Adequate for agent to use correctly, though handling arXiv error could be clearer.

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?

Despite 0% schema coverage, description clarifies paper_id and provider semantics. However, limit/offset parameters are not explained, leaving gaps.

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 clearly states the tool retrieves papers citing a specified paper, with specific verb and resource. It distinguishes from siblings like get_paper_references (references out) and get_related_papers.

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?

Provides clear context on provider differences (Semantic Scholar vs. arXiv) and what the tool does not do (no synthesis). Lacks explicit when-not-to-use or alternatives beyond implied differentiation.

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

get_paper_referencesA

Retrieve papers referenced by a specified academic paper.

This tool traverses the reference graph from an origin paper to papers listed in its bibliography. Each returned relationship may include:

canonical referenced-paper metadata;
reference contexts;
intent labels;
influential-reference status.

Semantic Scholar supports reference graph retrieval. arXiv does not expose a reference graph API and will return a normalized unsupported-operation error.

This tool retrieves structured graph metadata only. It does not evaluate the quality of the references.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`offset`	No
`paper_id`	Yes
`provider`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes	Maximum number of relationships requested.
`offset`	Yes	Offset used for the provider request.
`paper_id`	Yes	Identifier of the origin paper.
`provider`	Yes	Provider used for the graph request.
`returned`	Yes	Number of relationships returned.
`references`	No	Canonical citation or reference relationships.

TDQS

A4.3/5.0

Behavior5/5

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

With no annotations, the description fully bears the burden of transparency. It explicitly states the tool retrieves structured metadata only, does not evaluate quality, and notes provider-specific error behavior. This is comprehensive for a read-only tool.

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 well-structured and front-loaded with the core purpose. Each sentence adds value, though the list of returned fields could be condensed. Overall, it is appropriately sized without excess.

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?

Given the tool has an output schema and moderate complexity, the description provides sufficient context: it lists output fields, provider differences, and limitations. It lacks pagination details but is otherwise complete.

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 0%, so the description must compensate. It explains the tool’s purpose and the provider parameter, but does not describe limit, offset, or paper_id format. This leaves some ambiguity despite the overall context.

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 clearly states the tool retrieves papers referenced by a given paper, distinguishing it from siblings like get_paper_citations by specifying 'reference graph' and 'bibliography.' It also details the output structure, making the purpose unambiguous.

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 implicitly guides usage by noting that Semantic Scholar supports reference graph retrieval while arXiv does not, indicating when to avoid this tool. However, it could more explicitly contrast with siblings like get_paper_citations.

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

get_related_papersA

Retrieve papers related to a specified academic paper.

The selected paper is used as a positive recommendation seed. Optional negative paper identifiers can be supplied to reduce recommendations similar to those papers.

Semantic Scholar supports related-paper recommendations. arXiv does not expose a related-paper recommendation API and will return a normalized unsupported operation error.

This tool returns canonical paper records. It does not explain why each paper was recommended.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`paper_id`	Yes
`provider`	Yes
`negative_paper_ids`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`limit`	Yes	Maximum number of related papers requested.
`papers`	No	Canonical related-paper recommendations.
`paper_id`	Yes	Identifier of the positive seed paper.
`provider`	Yes	Provider used for recommendation retrieval.
`returned`	Yes	Number of related papers returned.
`negative_paper_ids`	No	Negative recommendation seed identifiers.

TDQS

A4.2/5.0

Behavior4/5

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

Discloses that it returns canonical records without explanations, and that arXiv returns an unsupported operation error. No annotations provided, so description carries burden; good disclosure of limitations.

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?

Very concise with 7 sentences, no fluff. Front-loaded with purpose, each sentence adds value. Efficient structure for quick understanding.

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?

Covers purpose, usage, provider differences, output nature. Missing details on limit defaults, error handling beyond arXiv, and output schema is present but not referenced. Adequate for a recommendation tool.

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?

Explains paper_id as positive seed and negative_paper_ids for filtering, but does not describe limit or provider beyond noting arXiv doesn't work. Schema coverage is 0%, so description partially compensates but misses some params.

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?

Description clearly states the tool retrieves papers related to a specified paper, distinguishing it from siblings like search_papers or citations. Includes specific verb 'Retrieve' and resource 'academic paper'.

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?

Describes when to use this tool (for recommendations), mentions negative paper ids to refine results, and notes arXiv limitations. Lacks explicit 'when not to use' or comparisons to all siblings, but context is clear.

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

health_checkA

Check whether the Research Intelligence MCP server is running and return its current runtime metadata.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`status`	No	Current health state of the MCP server.
`service`	Yes	Human-readable application name.
`version`	Yes	Current server version.
`timestamp`	Yes	UTC time at which the health check was executed.
`transport`	Yes	Configured MCP transport.
`environment`	Yes	Current application environment.
`server_name`	Yes	MCP server identifier.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided; description clearly states it is a read-only operation ('check', 'return metadata'), sufficient for a health check.

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?

Single concise sentence with no unnecessary words, front-loads the purpose effectively.

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 no parameters, no annotations, and an output schema present, the description fully conveys the tool's functionality and return value.

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?

No parameters; description adds no parameter info but baseline is 4 per rules since schema coverage is 100% with 0 params.

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?

Description explicitly states the tool checks server status and returns runtime metadata, clearly distinguishing it from sibling tools that operate on papers.

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?

Describes usage (check server running) but does not explicitly state when not to use or mention alternatives; still clear enough given the simple nature.

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

resolve_paper_accessA

Resolve known access information for an academic paper.

The tool retrieves the paper through the selected provider and returns its canonical access metadata, including:

open, closed, or unknown access status;
landing-page URL;
direct PDF URL when available;
known license;
repository or provider hosting the accessible copy.

This tool resolves metadata only. It does not download, parse, or return the paper PDF.

ParametersJSON Schema

Name	Required	Description	Default
`paper_id`	Yes
`provider`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Resolved paper title.
`access`	Yes	Canonical access status and available URLs.
`paper_id`	Yes	Identifier supplied by the caller.
`provider`	Yes	Provider used to resolve paper access.
`identifiers`	Yes	Preferred canonical identifier for the resolved paper.

TDQS

A4.4/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: it resolves metadata only, does not download or return PDF. Lists specific return fields, providing complete transparency.

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?

Description is concise, well-structured with bullet points for return data, and front-loads key actions. No redundant sentences.

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 output schema exists, description adequately covers tool behavior and limitations. It clarifies what the tool does and does not do, making it complete for its complexity.

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

Parameters2/5

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

Schema coverage is 0%, yet description adds no parameter details (e.g., paper_id format, available provider values). This fails to compensate for the schema gap.

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 clearly states it resolves access information for an academic paper, listing specific fields (access status, URLs, license, provider). It distinguishes from siblings like get_paper (metadata) and search_papers (search).

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 indicates the tool resolves metadata only, implying use when access info is needed, not PDF download. However, it lacks explicit when-not-to-use or alternatives beyond siblings.

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

search_papersA

Search for academic papers across Semantic Scholar, arXiv, or both providers.

Use this tool when the user wants to:

discover papers about a research topic;
find literature related to a research question;
search for a known paper title;
find papers by keywords or an author name;
restrict results by publication year;
restrict results by academic field or arXiv category;
request papers with known open-access metadata;
compare results from Semantic Scholar and arXiv.

The tool executes selected providers concurrently, preserves successful results when another provider fails, merges duplicate papers, preserves provider provenance, and returns deterministic provider-neutral paper records.

The response includes:

canonical paper metadata;
normalized paper identifiers;
author and publication metadata;
known access URLs;
provider attribution;
pagination metadata;
non-fatal warnings;
normalized partial-provider failures.

This tool performs academic paper discovery only. It does not summarize papers, answer research questions, synthesize evidence, or generate research reports.

ParametersJSON Schema

Name	Required	Default
`sort`	No	relevance
`limit`	No
`query`	Yes
`offset`	No
`year_to`	No
`providers`	No
`year_from`	No
`fields_of_study`	No
`open_access_only`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Normalized search query.
`papers`	No	Canonical search results.
`failures`	No	Normalized partial provider failures.
`warnings`	No	Non-fatal result warnings.
`pagination`	Yes	Pagination information.
`providers_requested`	Yes	Providers requested by the caller.
`providers_succeeded`	No	Providers that completed successfully.

TDQS

A4.3/5.0

Behavior5/5

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

No annotations are provided, so the description carries the full burden. It transparently discloses concurrent execution, error handling, merging duplicates, and provider provenance. It also details what the response includes, providing comprehensive behavioral context.

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 moderately long but well-structured with bullet points and clear sections. Every sentence adds value, though some sections could be more concise. It front-loads the core purpose and provides detailed behavioral notes.

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?

Given the tool's complexity (9 parameters, output schema exists), the description covers key aspects: purpose, when to use, behavioral traits, and response contents. It provides sufficient context for an AI agent to select and invoke correctly, though it could detail parameter format more.

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?

With 0% schema coverage, the description must compensate. It mentions filtering by year, field, and open access, which correspond to parameters. However, it does not explain sort, limit, offset, or providers, leaving some parameters unclear. The description adds value but is incomplete.

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 clearly states it searches for academic papers across Semantic Scholar and arXiv, with specific use cases listed. It distinguishes from sibling tools like get_paper or get_paper_citations, which focus on individual paper details or citations.

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 explicitly lists when to use the tool (e.g., discover papers on a topic, find literature, search by title/author) and what it does not do (e.g., summarize papers, answer research questions). However, it does not explicitly compare to sibling tools for when not to use it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

7 tool updatesv0.1.0Jul 29, 2026
- First observedget_paper
- First observedget_paper_citations
- First observedget_paper_references
- First observedget_related_papers
- First observedhealth_check
- First observedresolve_paper_access
- First observedsearch_papers

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: health check, paper search by query, single paper retrieval by identifiers, citation graph, reference graph, related papers, and access resolution. No two tools overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (search_papers, get_paper, get_paper_citations, etc.). The only exception is health_check, which is a common noun_noun pattern but still consistent with the server's style. Overall naming is clear and predictable.

Tool Count5/5

With 7 tools, the server covers the core workflow of academic paper discovery and retrieval without being bloated. Each tool serves a specific need, and the count is well within the ideal range for a focused MCP server.

Completeness5/5

The tool surface covers the full lifecycle of academic paper research: searching, retrieving metadata, traversing citation/reference/related paper graphs, and resolving access information. No obvious gaps for the stated purpose of paper discovery and retrieval.

Maintenance

ActivityMaintained

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

PapersFlowOAuth
io.github.papersflow-ai
Academic research MCP server for paper search, citation checks, graphs, and deep research.
Research & Data Search Documentation Access
214
Semanticscholar A
io.github.pipeworx-io
Semantic Scholar Academic Graph MCP.
Research & Data Search
352
Biolab MCP Server
io.github.srikarjy
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
Biology & Medicine Search Open Data
11
ScholarFetch A
io.github.laibniz
Multi-engine scholarly research server for search, traversal, full text, and reading lists.
Search Research & Data Open Data
1221

Related MCP Servers

scholar-toolkit-mcp
Research & Data Documentation Access
czwziy
A
license
A
quality
A
maintenance
Comprehensive MCP server for academic research workflows, enabling paper searching across multiple sources, manuscript processing with citation placeholders, search caching, and citation export.
Updated 2 months ago (2026-07-19 07:24 UTC)
11
MIT
Academic Paper MCP HTTP/SSE
Research & Data Search
pastchais
A
license
Not graded
quality
D
maintenance
A MCP server for academic literature retrieval, aggregating multiple data sources like arXiv, Crossref, OpenAlex, PubMed, and Semantic Scholar to provide search, details, citations, trends, and recommendations.
Updated a year ago (2025-10-11 06:37 UTC)
4
MIT
semanticscholar-mcp
Research & Data Search
xbghc
A
license
B
quality
D
maintenance
MCP server that provides Semantic Scholar academic search capabilities, including paper search, detail query, citation analysis, author search, and intelligent recommendations.
Updated 4 months ago (2026-04-26 09:38 UTC)
9
83
7
MIT
Science MCP
Research & Data Knowledge & Memory Search
l4b4r4b4b4
A
license
Not graded
quality
D
maintenance
MCP server for AI-assisted research: paper ingestion, semantic search, citation graph traversal, cross-domain knowledge synthesis, and workflow automation.
Updated 5 months ago (2026-04-03 14:48 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/supuni9622/research-intelligence-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

Research Intelligence MCP

Motivation

Features

Current Version

Academic Search

Architecture

Supported Providers

Phase 1

Planned Providers

Example Use Cases

Find recent papers

Discover related work

Citation exploration

Open-access resolution

Research agent integration

Architecture

Project Structure

Requirements

Installation

Running

Quality Checks

MCP Configuration Example

Test using MCP Inspector

Startup flow

MCP Tools

Search Tool

Remote Deployment and Authentication

Container

AWS ECS

Deployment Smoke Tests

Local Observability Stack

Why

What you can actually do with it

License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API