Research Intelligence MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.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.
Average 4.3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![research-intelligence-mcp MCP server](https://glama.ai/mcp/servers/supuni9622/research-intelligence-mcp/badges/card.svg)](https://glama.ai/mcp/servers/supuni9622/research-intelligence-mcp)

Score Badge

Copy to your README.md:

[![research-intelligence-mcp MCP server](https://glama.ai/mcp/servers/supuni9622/research-intelligence-mcp/badges/score.svg)](https://glama.ai/mcp/servers/supuni9622/research-intelligence-mcp)

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