Skip to main content
Glama
Arks-06

Neuro MCP V2

by Arks-06
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Local

Neuro MCP V2

Description

Neuro MCP V2 is an advanced, production-grade local Model Context Protocol (MCP) server designed specifically for Claude Desktop. It supercharges Claude with a suite of agentic capabilities, bridging the gap between local execution and AI assistance using standard I/O (stdio) transport.

Related MCP server: MCP Document Indexer

Key Features

  • Persistent Semantic Memory: Utilizes local embedded ChromaDB to store, embed, and instantly recall user context and project insights across different chat sessions.

  • Sandboxed File System I/O: Safely reads and writes files asynchronously via aiofiles within a strict, path-traversal-protected workspace/ directory.

  • Live Web Research: Interacts with the Tavily Search API via httpx to pull real-time data, documentation, and news directly into Claude's context window.

  • Local Emotional Intelligence: Runs a localized Hugging Face DistilRoBERTa pipeline via transformers and torch to analyze the semantic emotional tone of text blocks with zero external API latency.

  • Algorithmic Text Summarization: Compresses long documents and web search dumps using an extractive summarization engine based on normalized word-frequency scoring, instantly extracting key informational sentences to prevent LLM context window exhaustion.

  • Zero-Dependency Entity & Intent Extraction: Parses unstructured text records locally using a highly optimized, regex-based NLP engine to instantly extract critical parameters (IPs, emails, URLs, monetary bounds) and classify system operational intent.

Architecture & Tech Stack

  • Framework: fastmcp (Official Python SDK for MCP)

  • Package Management: uv (Fast Python dependency resolution)

  • Database: chromadb (Serverless, local SQLite vector storage)

  • Machine Learning: transformers, torch

  • Async Operations: aiofiles, httpx

Project Structure

neuro_mcp_v2/
├── .venv/
├── memory_db/             
├── workspace/     
├── .python-version
├── README.md
├── main.py
├── pyproject.toml
├── src/
    ├── mymcp/
        ├── server.py
        ├── tools/
            ├── emotion.py
            ├── fs_io.py
            ├── memory.py
            ├── websrch.py
            ├── extractor.py
            ├── summarize.py
        ├── utils/
            ├── security.py
├── uv.lock

Prerequisites

  • Python: 3.10 or higher

  • Claude Desktop Application

  • Tavily API Key: For web search capabilities

Installation

Clone the repository and navigate to the project root. Sync the dependencies using uv:

uv sync

Crucial Pre-flight Step: Run the server manually once to cache the Hugging Face emotion model (~300MB) locally and prevent Claude Desktop initialization timeouts:

uv run src/mymcp/server.py

Press Ctrl + C once the model finishes downloading.

Claude Desktop Configuration

To connect this server to Claude, edit your Claude Desktop configuration file (located at %APPDATA%\Claude\claude_desktop_config.json on Windows). [or simply go to Claude Desktop -> profile -> settings -> developer -> edit config option(if the mcp option is not shown automatically) -> make changes to the file that opens] Point the command to your project's absolute path and supply your API keys in the environment block:

{
  "mcpServers": {
    "neuro-mcp-v2": {
      "command": "C:\\Absolute\\Path\\To\\second_mcp_server\\.venv\\Scripts\\python.exe",
      "args": [
        "C:\\Absolute\\Path\\To\\second_mcp_server\\src\\mymcp\\server.py"
      ],
      "env": {
        "PYTHONUTF8": "1",
        "TAVILY_API_KEY": "your_tavily_api_key_here"
      }
    }
  }
}

Restart Claude Desktop entirely after updating this file. You should see the MCP plug icon appear in your chat window.

Security Notice

This application includes a workspace/ sandbox. The security middleware prevents the AI from reading or writing files outside of this specific directory to protect your local machine. Do not bypass the security.py checks.

License

This project is licensed under the MIT License.

Available Tools

6 tools
analyze_text_emotionA

Locally run a deep learning classification pipeline to detect semantic emotional markers (Joy, Sadness, Anger, Fear, Surprise, Disgust, Neutral) inside a block of text. Use this to adapt your tone or better understand user sentiment.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
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 pipeline runs locally, which is a key behavioral trait, and lists the emotion labels. It does not detail performance or limitations, but the information is sufficient for a simple classification 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?

Two sentences that front-load the main action and purpose. The first sentence is slightly long but clear. No superfluous information.

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 presence of an output schema, the description does not need to explain return values. It covers the input, the emotion categories, and a usage scenario. Basic edge cases are not addressed, but the tool's simplicity makes this acceptable.

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?

The single parameter 'text' has no schema description, and the schema coverage is 0%. The description adds context by referring to 'a block of text', but does not specify format, length, or encoding. It provides minimal added value beyond the type.

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 runs a deep learning pipeline to detect semantic emotional markers, lists the specific emotions (Joy, Sadness, Anger, Fear, Surprise, Disgust, Neutral), and distinguishes it from sibling tools that handle file operations, memory, or 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?

Explicitly suggests usage for adapting tone or understanding user sentiment, but does not provide explicit when-not-to-use or alternatives. The context from sibling tools makes its purpose distinct.

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

read_workspace_fileA

Read the full text contents from a specific file strictly inside the sandboxed workspace folder. Use this to get context from previous documents or code files.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description must disclose all behavioral traits. It states the file is read as full text and is restricted to the workspace folder, but does not mention error handling (e.g., file not found, permissions), encoding, or size limits. This leaves gaps for an AI agent.

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?

Two sentences, no redundant words, and the most important information is front-loaded. Every sentence adds value.

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 simplicity (one parameter, output schema exists), the description covers the main purpose and scope. It lacks details on error behavior and security restrictions beyond 'sandboxed', but these are acceptable for a straightforward read 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?

The input schema has one parameter 'file_path' with 0% description coverage. The description adds the constraint that the path must be 'strictly inside the sandboxed workspace folder', providing context beyond the schema. However, it does not specify path format (relative/absolute) or constraints, so it partially compensates.

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 specifies the action ('read the full text contents'), the resource ('a specific file'), and the scope ('strictly inside the sandboxed workspace folder'). It also mentions typical use cases ('get context from previous documents or code files'), distinguishing it from sibling tools like write_workspace_file.

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 says 'Use this to get context from previous documents or code files', which gives a clear when-to-use. It does not directly state when not to use or name alternatives, but the sibling tools are distinct enough that the usage context is clear.

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

recall_persistent_memoryA

Query the persistent vector database to recall past context, preferences, or project details. Use this to check if you have existing knowledge on a topic the user mentions.

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYes
n_resultsNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.1/5.0
Behavior3/5

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

The description indicates it queries a persistent vector database, implying a read-only operation, but does not disclose limitations, privacy implications, or behavior when no results are found. With no annotations provided, the description carries the full burden; it provides basic context but lacks depth.

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 two sentences, front-loading the core action and usage guidance. Every word serves a purpose, achieving high conciseness without sacrificing clarity.

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 simplicity and the presence of an output schema, the description adequately covers the tool's purpose and usage. It does not explain edge cases or result handling, but these are partially addressed by the output schema. The description is nearly complete for a recall tool.

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%, requiring the description to compensate for parameter meaning. However, the description does not mention the 'query' or 'n_results' parameters, leaving the agent to infer from names alone. This is insufficient when coverage is low.

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 identifies the tool as querying a persistent vector database to retrieve past context, preferences, or project details. It distinguishes itself from sibling tools like store_persistent_memory and tavily_web_search by specifying its recall function.

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

Usage Guidelines5/5

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

Explicitly tells the agent when to use this tool: 'Use this to check if you have existing knowledge on a topic the user mentions.' This provides clear guidance on invocation context, differentiating it from storage or search tools.

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

store_persistent_memoryA

Store long-term semantic context or user preferences permanently in the vector database. Use this when the user explicitly asks you to remember something or when key insights are uncovered.

ParametersJSON Schema
NameRequiredDescriptionDefault
conceptYes
detailsYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.8/5.0
Behavior3/5

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

No annotations provided, so description carries burden. Describes permanence but lacks details on overwrite behavior, idempotency, or potential effects on existing memories.

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?

Two sentences, front-loaded with purpose, no unnecessary words. Efficient and well-structured.

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?

Given no annotations and an output schema, description should mention return value or confirmation. Missing details on effect and response, though tool complexity is low.

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%. Description adds no meaning to 'concept' or 'details' beyond what is in the schema. Fails to explain what these parameters represent or how to use them.

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 action (store), resource (long-term semantic context/user preferences), and permanence (in vector database). It effectively distinguishes from sibling tool recall_persistent_memory.

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?

Explicitly states when to use: when user asks to remember or key insights are uncovered. Could be improved by noting when not to use, but provides clear guidance.

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

write_workspace_fileA

Write or overwrite text content to a specific file inside the sandboxed workspace folder. Automatically creates directories if they do not exist. Use this to save notes, code, or outputs.

ParametersJSON Schema
NameRequiredDescriptionDefault
file_pathYes
contentYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.9/5.0
Behavior3/5

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

The description adds behavioral context beyond the bare schema by noting automatic directory creation. However, it does not mention that content is overwritten without confirmation or discuss error handling, which would be useful given no annotations.

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 extremely concise (two sentences, ~25 words) and front-loaded with the primary action. Every sentence is informative with no unnecessary words.

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?

Given the tool's simplicity, the description covers the main purpose and a key side effect. However, it lacks detail on overwrite behavior and return values (though an output schema may fill that gap). Overall adequate but not rich.

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 description coverage, the description must compensate. It mentions file_path and content implicitly but does not add details like path format or content encoding, so it provides only marginal added meaning.

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 (write/overwrite text content), the resource (specific file), and the location (sandboxed workspace folder). It distinguishes from the sibling tool read_workspace_file.

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?

It provides explicit context for when to use the tool ('save notes, code, or outputs') and mentions the automatic directory creation behavior. However, it does not explicitly exclude scenarios or compare with alternatives.

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. Dates show when Glama detected each change.

  1. 6 tool updatesv0.1.0
    • First observedanalyze_text_emotion
    • First observedread_workspace_file
    • First observedrecall_persistent_memory
    • First observedstore_persistent_memory
    • First observedtavily_web_search
    • First observedwrite_workspace_file
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: emotion analysis, file reading, memory recall, memory store, web search, and file writing. No overlap in functionality.

Naming Consistency4/5

All tools follow a verb_noun pattern (e.g., analyze_text_emotion, read_workspace_file). The only minor deviation is 'tavily_web_search' which includes a brand name, but it still fits the pattern.

Tool Count5/5

Six tools is well within the ideal 3-15 range. The tool count matches the server's purpose of providing a capable assistant with memory, file operations, web search, and emotion analysis.

Completeness4/5

Core operations are covered: file read/write, memory recall/store, web search, and text analysis. Minor gaps include lack of file deletion or memory deletion, but the set enables key workflows.

Maintenance

ActivityStale
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • MCP Document Indexer

    yairwein
    A
    license
    Not graded
    quality
    D
    maintenance
    Enables real-time indexing and semantic search of local documents (PDF, Word, text, Markdown, RTF) using vector embeddings and local LLMs. Monitors folders for changes and provides natural language search capabilities through Claude Desktop integration.
    21
    MIT

  • quarry

    punt-labs
    A
    license
    A
    quality
    A
    maintenance
    Enables local semantic search over documents and code for Claude Code and Claude Desktop, running entirely offline with local embeddings and vector storage.
    12
    3
    MIT

Latest Blog Posts

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/Arks-06/neuro_mcp_v2'

If you have feedback or need assistance with the MCP directory API, please join our Discord server