Skip to main content
Glama
Ruoth1111

ai-research-assistant-mcp

by Ruoth1111

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 the research.txt file).

3. Prompts (prompts)

  • research_summary_prompt: A prompt template that reads the current contents of research.txt and 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 via uv.


Setup Instructions

Prerequisites

  • Python: Version 3.12 or higher (configured via .python-version).

  • uv: It is highly recommended to use uv for 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

  1. Clone or navigate to the project directory:

    cd /Users/gaganchaudhary/mcp-server-demo
  2. Create the virtual environment and install dependencies:

    uv sync

Running the Server

To test and interact with the server interactively using the MCP Inspector web interface, run:

uvx mcp dev main.py

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

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

  • Windows: %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 tools
add_researchC

Add research to the research file

ParametersJSON Schema
NameRequiredDescriptionDefault
researchYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

C2.6/5.0
Behavior2/5

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.

Conciseness3/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose5/5

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.

Usage Guidelines2/5

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
ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

D1/5.0
Behavior1/5

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.

Conciseness1/5

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.

Completeness1/5

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.

Parameters1/5

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.

Purpose1/5

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.

Usage Guidelines1/5

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.

  1. 2 tool updatesv0.1.0
    • First observedadd_research
    • First observedread_research

TDQS

C2.2/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are clearly distinct: one for adding research, one for reading research. No overlap in purpose, making selection unambiguous for an agent.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern ('add_research', 'read_research'), making the naming predictable and easy to understand.

Tool Count3/5

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.

Completeness2/5

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

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers