How do I use mcp-research-assistant?

1. Click on "Deploy 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., "@mcp-research-assistant Query my 'ml-research' for information about neural networks" 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.

mcp-research-assistant

by CyprianFusi

Overview Schema Source Related Servers Discussions Admin

Python

Local

MCP Research Assistant Server

By BINATI AInalytics

A Model Context Protocol (MCP) server that provides intelligent research data management using vector embeddings and semantic search. This server enables you to save, organize, and retrieve research content using ChromaDB and OpenAI embeddings.

Screenshots

UI Screenshot 1 UI Screenshot 2 UI Screenshot 3 UI Screenshot 4 UI Screenshot 5

Related MCP server: Chroma MCP Server

Features

Vector Storage: Uses ChromaDB for efficient storage and retrieval
Topic Organization: Organize research content by topics
Deduplication: Automatic content deduplication using hashing
Semantic Search: Query research content using natural language
Multiple Topics: Manage multiple research topics simultaneously
OpenAI Embeddings: Uses OpenAI's text-embedding-3-small model

Installation

Using uvx (Recommended)

uvx mcp-research-assistant

Using uv

uv pip install mcp-research-assistant

Using pip

pip install mcp-research-assistant

From Source

git clone https://github.com/CyprianFusi/mcp-research-assistant.git
cd mcp-research-assistant
uv pip install -e .

Configuration

Environment Variables

Required:

OPENAI_API_KEY - Your OpenAI API key for embeddings
RESEARCH_DB_PATH - Base path for storing research databases
- A research_chroma_dbs directory will be created inside this path
- Example: /path/to/data (will create /path/to/data/research_chroma_dbs)
- Example: ~/.research_assistant_mcp (will create ~/.research_assistant_mcp/research_chroma_dbs)

Create a .env file with your configuration:

OPENAI_API_KEY=your-api-key-here
RESEARCH_DB_PATH=/path/to/data

Claude Desktop Configuration

MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "research-assistant": {
      "command": "uvx",
      "args": ["mcp-research-assistant"],
      "env": {
        "OPENAI_API_KEY": "your-api-key-here",
        "RESEARCH_DB_PATH": "/path/to/data"
      }
    }
  }
}

Note: Both OPENAI_API_KEY and RESEARCH_DB_PATH are required. The database will be stored in RESEARCH_DB_PATH/research_chroma_dbs/.

Available Tools

1. save_research_data

Save research content to vector database for future retrieval.

Parameters:

content (List[str]): List of text content to save
topic (str): Topic name for organizing the data (creates separate DB)

Example:

Save these research findings about AI to the "artificial-intelligence" topic

2. query_research_data

Query saved research content using natural language.

Parameters:

query (str): Natural language query
topic (str): Topic to search in (default: "default")
k (int): Number of results to return (default: 5)

Example:

Query the "artificial-intelligence" topic for information about transformers

3. list_topics

List all available research topics and their document counts.

Example:

List all available research topics

4. delete_topic

Delete a research topic and all its associated data.

Parameters:

topic (str): Topic name to delete

Example:

Delete the "old-research" topic

5. get_topic_info

Get detailed information about a specific topic.

Parameters:

topic (str): Topic name

Example:

Get information about the "artificial-intelligence" topic

Usage Examples

Once configured with Claude Desktop or another MCP client, you can:

"Save this article about machine learning to my 'ml-research' topic"
"Query my 'ml-research' for information about neural networks"
"List all my research topics"
"Get information about the 'quantum-computing' topic"
"Delete the 'old-notes' topic"

Technical Details

Protocol: Model Context Protocol (MCP)
Transport: stdio
Vector Database: ChromaDB
Embeddings: OpenAI text-embedding-3-small
Storage: Local filesystem at RESEARCH_DB_PATH/research_chroma_dbs/

Requirements

Python 3.11 or higher
OpenAI API key
Dependencies: chromadb, langchain, fastmcp, openai

Development

Setup Development Environment

# Clone the repository
git clone https://github.com/CyprianFusi/mcp-research-assistant.git
cd mcp-research-assistant

# Install with development dependencies
uv pip install -e .

License

This project is licensed under the MIT License - see the LICENSE file for details.

Author

Cyprian Fusi

Email: info@binati-ai.com
GitHub: https://github.com/CyprianFusi/

Acknowledgments

Built with FastMCP
Uses ChromaDB for vector storage
Powered by LangChain
Implements the Model Context Protocol

Available Tools

5 tools

delete_research_topicA

Delete a research topic and all its data. Args: topic: Topic name to delete

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

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

No annotations provided. The description only states 'delete all its data', which indicates destructiveness but lacks details on cascading effects, reversibility, or authorization needs.

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?

Concise, front-loaded description with no wasted words. Includes args for clarity. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Minimally complete for a simple delete tool, but lacks details on return value (output schema exists but not described) and confirmation of deletion.

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 schema coverage at 0%, the description adds minimal value: 'topic name' clarifies the parameter. For a single string field, this is adequate but not exceptional.

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?

Clearly states the action (delete) and resource (research topic) with scope (all its data). Differentiates from sibling tools like get_topic_info and list_research_topics which are read-only.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implied usage for deletion, but no explicit when-to-use or when-not-to-use guidance. No mention of prerequisites or alternatives.

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

get_topic_infoB

Get detailed information about a research topic. Args: topic: Topic name to get info for

ParametersJSON Schema

Name	Required	Description	Default
`topic`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations provided, the description must fully disclose behavioral traits. It only says 'get detailed information' without specifying read-only nature, error behavior for missing topics, or any side effects. The brevity leaves significant behavioral ambiguity.

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 concise with no wasted words. It front-loads the purpose in the first sentence and then lists the argument. However, it lacks structural elements like headings or examples that could enhance scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While an output schema exists (relieving the need to explain return values), the description does not mention what 'detailed information' entails—e.g., metadata, relationships, or associated data. It is minimally adequate but leaves the agent guessing about the nature of the output.

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 description coverage is 0%, meaning the description must compensate. It merely restates the parameter as 'topic name to get info for,' adding minimal meaning beyond the schema's 'topic' string. No constraints, examples, or format details 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 'Get detailed information about a research topic,' which specifies the verb ('get') and resource ('research topic'). It distinguishes from siblings like 'delete_research_topic' and 'list_research_topics' by focusing on retrieval of detailed info rather than deletion, listing, saving, or searching.

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 is provided on when to use this tool compared to alternatives like 'search_research_data' or 'list_research_topics'. There is no mention of context, preconditions, or exclusions, leaving the agent without decision criteria.

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

list_research_topicsA

List all available research topics (vector databases).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations provided, the description must disclose behavior. It indicates a read-only listing operation, which is adequate. However, it lacks details on authentication, rate limits, or any side effects, though for a list tool these are less critical.

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 a single sentence that effectively communicates the tool's purpose with no unnecessary words. It is well-structured and front-loaded with the action.

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 simplicity of the tool (no parameters, no nested objects) and the presence of an output schema, the description is complete. It does not need to explain return values, and the context signals indicate no missing information.

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 tool has zero parameters, and schema coverage is 100% (trivially). According to guidelines, 0 parameters yields a baseline score of 4. The description adds no parameter info, which is acceptable.

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's function: listing all available research topics. The addition of '(vector databases)' provides context about the domain, distinguishing it from other tools. It is specific and identifies the resource and action.

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 is given on when to use this tool versus its siblings (delete, get info, save, search). The description implies usage for listing all topics but does not specify exclusions or alternative scenarios.

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

save_research_dataA

Save research content to vector database for future retrieval. Args: content: List of text content to save topic: Topic name for organizing the data (creates separate DB)

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes
`topic`	No		default

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.2/5.0

Behavior3/5

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

The description mentions that saving is for 'future retrieval' and that a topic 'creates separate DB', giving some behavioral context. However, with no annotations, it could disclose more about whether data is additive or overwritten, handling of duplicates, or performance implications.

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 very concise: a clear purpose sentence followed by a labeled args section with minimal but sufficient descriptions. No extraneous content; every word is earned.

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 two parameters, no annotations, and an output schema exists (though not shown), the description covers the core functionality. It could be more complete by describing the return value or behavior on success/failure, but it is adequate for a simple write operation.

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?

Since schema description coverage is 0%, the description adds meaning: content is 'List of text content to save' and topic is 'Topic name for organizing the data (creates separate DB)'. This provides useful context beyond the bare schema, though further details (e.g., content size limits) would improve it.

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 'Save research content to vector database for future retrieval' which combines a specific verb (Save) and resource (research content to vector database). It distinguishes from sibling tools like search_research_data (retrieval) and delete_research_topic (deletion).

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 explains how to use the tool by providing content and an optional topic, and notes that topic creates a separate database. However, it does not explicitly state when to use this tool versus alternatives like search_research_data or 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.

search_research_dataB

Search through saved research data using semantic similarity. Args: query: Search query topic: Topic database to search in max_results: Maximum number of results to return

ParametersJSON Schema

Name	Required	Default
`query`	Yes
`topic`	No	default
`max_results`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

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

No annotations are provided, so the description must disclose behavioral traits. It mentions 'semantic similarity' but lacks details on matching behavior, valid topics, pagination, or any side effects. The default values are noted but not explained.

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?

One short sentence followed by a structured 'Args:' list. No unnecessary words, and the format is easy to parse. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite the presence of an output schema, the description lacks context on how topics relate to sibling tools, what the 'default' topic means, and any prerequisites. It is too brief for a search tool with no annotations.

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 adds minimal semantics: each parameter has a brief explanation. 'topic: Topic database to search in' is somewhat ambiguous, but it clarifies the role beyond the schema's type and default.

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 verb 'search' and the resource 'saved research data' with the method 'semantic similarity', which distinguishes it from sibling tools like delete, list, and save.

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 explicit guidance on when to use this tool versus alternatives. Sibling tools are listed but no comparisons or selection criteria are provided.

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.

5 tool updatesv0.1.5May 30, 2026
- First observeddelete_research_topic
- First observedget_topic_info
- First observedlist_research_topics
- First observedsave_research_data
- First observedsearch_research_data

Deploy Server

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

TDQS

A3.8/5.0

Scored 2026-05-30 15:10 across 5 tools

Disambiguation5/5

Each tool targets a distinct operation: listing, getting info, saving, searching, and deleting topics. No overlap in functionality, making it easy for an agent to select the correct tool.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., delete_research_topic, list_research_topics), making the naming predictable and intuitive.

Tool Count5/5

Five tools is appropriate for a research assistant, covering essential CRUD-like operations without being too sparse or overwhelming.

Completeness4/5

The tool surface covers listing, reading, creating, searching, and deleting research data. The only minor gap is the lack of an explicit update operation, but 'save' may serve as an upsert.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Needle
com.needle-ai.mcp
The Needle MCP server enables semantic search on documents stored in files like PDFs, DOCX, and XLSX by connecting AI applications to external data sources. It provides capabilities to create and manage document collections, perform natural language searches on stored content, and retrieve relevant information without requiring exact keyword matches.
RAG Systems Search File Systems
2
SombraOAuth
so.sombra
AI research library. Save, organise and reuse notes and webpages as clean markdown context.
Note Taking Research & Data Web Scraping
2
AmberOAuth
com.ambermem
Long-term memory for AI assistants. Hybrid retrieval, query expansion, auto-topics.
Knowledge & Memory RAG Systems Vector Databases
21
ragie
com.mcparmory
Ingest, manage, and retrieve documents for RAG-powered AI applications
RAG Systems Databases Knowledge & Memory
2

Related MCP Servers

PapersWithCode MCP
Research & Data Search Documentation Access
hbg
A
license
Not graded
quality
F
maintenance
A server that allows AI assistants to search for research papers, read their content, and access related code repositories through the PapersWithCode API.
Updated a year ago (2025-06-07 02:53 UTC)
26
MIT
Chroma MCP Serverofficial
Vector Databases RAG Systems Knowledge & Memory
chroma-core
A
license
A
quality
D
maintenance
A server that provides data retrieval capabilities powered by Chroma embedding database, enabling AI models to create collections over generated data and user inputs, and retrieve that data using vector search, full text search, and metadata filtering.
Updated a year ago (2025-09-17 20:20 UTC)
13
590
Apache 2.0
Pocket Assistant MCP Server
Knowledge & Memory Vector Databases RAG Systems
VikashS
A
license
Not graded
quality
C
maintenance
Enables AI assistants to save, retrieve, and manage research content using ChromaDB vector storage with semantic search, topic organization, and automatic deduplication powered by OpenAI embeddings.
Updated 8 months ago (2026-01-09 22:51 UTC)
MIT
Marcus Local MCP Server
RAG Systems Vector Databases Search
Marcussy34
F
license
Not graded
quality
D
maintenance
Enables AI assistants to semantically search through indexed documentation websites and local code repositories using OpenAI embeddings and ChromaDB vector storage.
Updated 10 months ago (2025-11-13 06:47 UTC)
-

MCP Research Assistant Server

Screenshots

Features

Installation

Using uvx (Recommended)

Using uv

Using pip

From Source

Configuration

Environment Variables

Claude Desktop Configuration

Available Tools

1. save_research_data

2. query_research_data

3. list_topics

4. delete_topic

5. get_topic_info

Usage Examples

Technical Details

Requirements

Development

Setup Development Environment

License

Author

Acknowledgments

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Chroma MCP Serverofficial