ai-research-assistant-mcp
Click on "Deploy 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., "@ai-research-assistant-mcpAdd a research note: Found interesting results in 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.
AI Research Assistant - MCP Server
An implementation of a Model Context Protocol (MCP) server built in Python using the FastMCP framework. This server acts as an AI Research Assistant, providing tools, resources, and prompt templates to help LLM clients (like Claude Desktop) read, write, and summarize research notes stored in a local flat-file database.
What the Project Does
This MCP server exposes the following capabilities to any compatible LLM client:
1. Tools (tools)
add_research(research: str): Appends a new line of research notes or text to the local database file (research.txt).read_research(): Reads and returns the entire contents of the research database. If the file is empty, it returns a message indicating no research has been saved yet.
2. Resources (resources)
research://latest: A dynamic URI resource that retrieves only the latest research entry (the last line of theresearch.txtfile).
3. Prompts (prompts)
research_summary_prompt: A prompt template that reads the current contents ofresearch.txtand automatically formats a prompt asking the AI model to summarize the collected research.
Related MCP server: Local Knowledge Desk
Directory Structure
main.py: The entry point of the MCP server implementing the tools, resources, and prompts using FastMCP.research.txt: The local storage file containing the research notes.pyproject.toml: The Python project configuration defining metadata and dependencies (mcp[cli]).uv.lock: The lockfile for deterministic dependency resolution viauv.
Setup Instructions
Prerequisites
Python: Version
3.12or higher (configured via.python-version).uv: It is highly recommended to use
uvfor fast dependency management and running the server. If you don't have it, install it using:curl -LsSf https://astral.sh/uv/install.sh | sh
Installation
Clone or navigate to the project directory:
cd /Users/gaganchaudhary/mcp-server-demoCreate the virtual environment and install dependencies:
uv sync
Running the Server
1. Developer Inspection & Testing (Recommended)
To test and interact with the server interactively using the MCP Inspector web interface, run:
uvx mcp dev main.pyThis command starts the server and hosts a visual inspector tool locally (typically at http://localhost:5173) where you can trigger tools, read resources, and test prompts.
2. Standard Run Command
To run the server directly on standard input/output (stdio) transport:
uv run main.pyClient Integration
To integrate this MCP server with Claude Desktop, add it to your configuration file.
Configuration File Location
macOS:
~/Library/Application Support/Claude/claude_desktop_config.jsonWindows:
%APPDATA%\Claude\claude_desktop_config.json
Configuration Content
Open the configuration file and add the ai-research-assistant server under the mcpServers object:
{
"mcpServers": {
"ai-research-assistant": {
"command": "uv",
"args": [
"--directory",
"/Users/gaganchaudhary/mcp-server-demo",
"run",
"main.py"
]
}
}
}After modifying the configuration file, restart Claude Desktop. You will see the new hammer icon indicating that the AI Research Assistant tools are available!
Available Tools
2 toolsadd_researchC
Add research to the research file
| Name | Required | Description | Default |
|---|---|---|---|
| research | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only says 'Add research' without disclosing any behavioral traits like append vs overwrite, side effects, or authorization requirements.
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 is concise (one sentence) but lacks structure and front-loading of key information. It could be more informative without added length.
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?
The tool has one required parameter and no annotations, yet the description fails to provide sufficient context for correct usage. The presence of an output schema is not leveraged.
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?
Schema description coverage is 0%, and the description adds no meaning to the 'research' parameter beyond its name. No format, constraints, or examples are given.
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 action ('Add'), the resource ('research'), and the target ('research file'). It distinguishes from the sibling tool 'read_research' by implying write vs read.
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?
No guidance on when to use this tool vs 'read_research' or any other alternatives. No context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
read_researchD
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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?
Tool has no description.
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.
2 tool updates
v0.1.0- First observed
add_research - First observed
read_research
TDQS
Scored across 2 tools
The two tools are clearly distinct: one for adding research, one for reading research. No overlap in purpose, making selection unambiguous for an agent.
Both tools follow a consistent verb_noun pattern ('add_research', 'read_research'), making the naming predictable and easy to understand.
With only 2 tools, the server feels thin for a research assistant, but it may suffice for a simple file-based read/write system. The count is acceptable but on the low end.
The tool set is incomplete: it lacks update, delete, search, or any organizational operations. An agent cannot manage or modify research after adding, leading to dead ends.
Maintenance
Related MCP Connectors
Markdown-based note-taking with a hosted MCP server. Your notes serve you and your AI.
An MCP server that used to create notes
An MCP server for deep research or task groups
Google Keep-style notes app with an MCP server for AI agents to read/write notes.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceAn offline MCP server that enables research tasks such as summarizing text, extracting key points, and saving/retrieving notes via a CLI client and stdio transport.1-
- FlicenseAqualityBmaintenanceA local MCP server for managing Markdown notes, enabling create, list, read, search, summarize, and delete operations through natural language.61-
- FlicenseNot gradedqualityDmaintenanceA simple notes MCP server that enables creating, listing, and summarizing text notes via resources, tools, and prompts.-
- FlicenseNot gradedqualityCmaintenanceAn MCP server that transforms markdown notes into a searchable knowledge base with semantic search, smart note creation, and flashcard management for AI assistants.1-