Provides tools for searching and retrieving research papers from arXiv, with capabilities to query papers by topic, extract detailed paper information, and automatically save paper metadata to local storage.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Research Server search for recent papers about quantum computing"
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.
A comprehensive Model Context Protocol (MCP) setup that provides powerful tools for research, file management, and web content fetching. This project integrates multiple MCP servers to enhance your AI assistant capabilities.
📚 Research Tool: Search and manage academic papers from arXiv
📁 Filesystem Tool: Browse, read, and manage project files
🌐 Fetch Tool: Retrieve content from websites and APIs
🤖 Multi-LLM Support: Works with Claude, Gemini, and other AI models
💾 Local Storage: Automatically saves research data organized by topics
Related MCP server: arXiv MCP Server
Python 3.13 or higher
uv package manager (recommended) or pip
API keys for your chosen LLM providers
Claude Desktop (for MCP integration)
git clone <your-repo-url>
cd mcp_project# Install uv if you haven't already
curl -LsSf https://astral.sh/uv/install.sh | sh
# Create virtual environment and install dependencies
uv syncCreate a .env file in your project root:
ANTHROPIC_API_KEY=your_anthropic_api_key_hereCreate or update your Claude Desktop configuration file:
Location: ~/Library/Application Support/Claude/claude_desktop_config.json (macOS)
{
"mcpServers": {
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"."
],
"cwd": "/path/to/your/mcp_project"
},
"research": {
"command": "/path/to/your/mcp_project/.venv/bin/python",
"args": [
"/path/to/your/mcp_project/research_server.py"
],
"cwd": "/path/to/your/mcp_project"
},
"fetch": {
"command": "/path/to/your/.local/bin/uvx",
"args": ["mcp-server-fetch"],
"cwd": "/path/to/your/mcp_project"
}
}
}Important: Replace /path/to/your/mcp_project with your actual project path.
Restart Claude Desktop completely to load the new configuration.
Search for Papers:
Search for 5 papers about machine learningGet Paper Details:
Show me information about paper ID 1234.5678Browse Saved Papers:
What papers do I have saved on physics?Browse Files:
List all files in my project directoryRead Files:
Show me the contents of research_server.pyCreate Files:
Create a new Python script for data analysisGet Web Content:
Fetch the latest Python documentationAPI Calls:
Get current weather data from an APITool | Description | Parameters |
| Search arXiv for papers |
|
| Get paper details |
|
| List saved topics | None |
Tool | Description |
| Read file contents |
| Write to files |
| List directory contents |
| Delete files |
Tool | Description |
| Fetch content from URLs |
mcp_project/
├── research_server.py # Main research MCP server
├── mcp_chatbot_L7.py # Chatbot with LLM integration
├── pyproject.toml # Project configuration
├── requirements.txt # Python dependencies
├── uv.lock # Dependency lock file
├── papers/ # Research data storage
│ └── [topic_name]/ # Organized by topic
│ └── papers_info.json # Paper metadata
├── .env # Environment variables
└── README.md # This fileThe research server automatically:
Creates topic-based directories in papers/
Saves paper metadata as JSON files
Provides search and retrieval functions
Integrates with arXiv API
The filesystem server:
Operates within your project directory
Provides full file management capabilities
Uses relative paths for portability
The fetch server:
Handles web requests and API calls
Supports custom user agents
Can ignore robots.txt restrictions
Screenshot showing the MCP Research Assistant successfully running with all tools working
Edit research_server.py to add new functions
Use the @mcp.tool() decorator
Test with MCP Inspector
Update documentation
Edit mcp_chatbot_L7.py
Modify tool descriptions and parameters
Add custom prompts and resources
Search for information about a specific paper across all topic directories.
Args: paper_id: The ID of the paper to look for
Returns: JSON string with paper information if found, error message if not found
| Name | Required | Description | Default |
|---|---|---|---|
| paper_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It successfully discloses return behavior ('JSON string with paper information if found, error message if not found') and scope ('across all topic directories'). However, it lacks explicit safety classification (read-only vs destructive) or side-effect disclosure despite the implicit 'search' verb.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a clean, structured format with clear 'Args' and 'Returns' sections. It is appropriately concise with no redundant or wasted sentences; every clause provides specific functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with an output schema present, the description provides adequate completeness. It documents the sole parameter (compensating for schema gaps) and summarizes return behavior, which is sufficient given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the Args section effectively compensates by defining 'paper_id' as 'The ID of the paper to look for.' This adds necessary semantic meaning that the raw schema lacks, clearly indicating the parameter represents a paper identifier.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Search[es] for information about a specific paper across all topic directories,' providing specific verb (search), resource (paper information), and scope (all topic directories). It implicitly distinguishes from sibling 'search_papers' by emphasizing 'specific paper' lookup by ID rather than general searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus the sibling 'search_papers'. While it implies usage by stating it looks for a 'specific paper' (suggesting use when paper_id is known), it fails to explicitly contrast with alternatives or state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for papers on arXiv based on a topic and store their information.
Args: topic: The topic to search for max_results: Maximum number of results to retrieve (default: 5)
Returns: List of paper IDs found in the search
| Name | Required | Description | Default |
|---|---|---|---|
| topic | Yes | ||
| max_results | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It appropriately notes the side effect of storing information and specifies the return value (List of paper IDs), but omits other critical details such as idempotency, what 'store' entails (persistent cache, session memory, etc.), error handling behavior, or rate limiting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description uses a docstring format with distinct Args and Returns sections. While slightly more structured than typical prose descriptions, it efficiently organizes information with no wasted sentences. The format is machine-parseable and front-loads the core purpose before detailing parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple 2-parameter search tool with a straightforward output (list of IDs), the description is adequately complete. It covers the search domain (arXiv), the side effect (storage), and the return type. While additional context on storage scope would be helpful, the description suffices for tool selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (only titles). The description compensates via the Args section, documenting both 'topic' (the search query) and 'max_results' (with default value). While it documents the parameters, it lacks rich semantic detail such as expected format for topics, examples, or constraints on max_results.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for papers on arXiv based on a topic and stores their information. It uses specific verbs ('Search', 'store') and identifies the specific resource (arXiv papers), implicitly distinguishing it from the sibling 'extract_info' tool which likely operates on existing papers rather than searching for them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus the sibling 'extract_info' tool, nor does it specify prerequisites (e.g., whether a topic should be broad or specific) or when not to use it. Agents must infer usage solely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0extract_infosearch_papersThe two tools have clearly distinct purposes: extract_info retrieves information about a specific paper by ID, while search_papers finds papers on arXiv by topic and stores them. There is no overlap or ambiguity between these operations.
Both tools follow a consistent verb_noun pattern (extract_info and search_papers), using snake_case and descriptive action-object naming. The naming is predictable and readable throughout.
With only 2 tools for a research server, the set feels thin and incomplete for the apparent scope. A research domain typically requires more operations like managing papers, updating information, or handling citations, making this count inadequate.
There are significant gaps in the tool surface for a research server. While search and retrieval are covered, missing operations include creating, updating, or deleting paper records, organizing topics, or accessing stored data beyond extraction, which will limit agent workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
ArXiv preprint search, daily category digest, and author-collaborator graph.
A Model Context Protocol server for Wix AI tools
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/khushiiagrawal/MCP_Research_Assistant'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
