What can you do with this server?

NeuroVerse is a multilingual AI agent intelligence layer providing memory, safety, multi-model routing, voice, and reasoning capabilities for MCP-compatible AI agents. * Multilingual Processing (neuroverse_process): Handle mixed Indian languages (Tamil, Hindi, Telugu, Kannada, Malayalam, Bengali) with English code-switching — running the full pipeline: language detection → normalization → intent extraction → safety check → optional execution. * Memory Storage & Recall (neuroverse_store / neuroverse_recall): Persist and retrieve context across three tiers (short-term, episodic, semantic) with importance scoring, filtered by user, intent, tier, or semantic query. * Safe Execution (neuroverse_execute): Parse and execute user requests through a 3-layer safety engine (keyword blocklist → intent risk classifier → optional LLM judge) that blocks dangerous operations like DROP DATABASE or rm -rf, with zero token cost and sub-millisecond latency. * Multi-Model Routing (neuroverse_model): Automatically select the best AI provider (OpenAI, Anthropic, Sarvam AI, Ollama, OpenRouter) based on task type (multilingual, reasoning, local, general). * Agent-to-Agent Routing (neuroverse_route): Route tasks to registered downstream agents via HTTP with automatic fallback on failure. * Voice (neuroverse_transcribe / neuroverse_synthesize): Transcribe audio to text using Whisper STT and synthesize speech from text using Coqui TTS. * High-Performance Reasoning (neuroverse_reason): Execute complex analytical tasks using specialized reasoning models via OpenRouter. * Codebase Context Assembly (neuroverse_assemble_context): Scan a codebase and extract the most relevant file chunks for a given query (Arachne Protocol). * RLHF Feedback Logging (neuroverse_feedback): Submit human feedback with ratings and comments to continuously tune agent performance.

Which integrations are available for this server?

Supports local model execution through Ollama via the Marga multi-model router for privacy-focused or local task processing. Utilized by the multi-model router to provide agents with intelligence for intent extraction, reasoning, and multilingual processing. Powers the Smriti memory layer to provide persistent tiered storage for short-term, episodic, and long-term semantic context.

neuroverse

by joshua400

Overview Schema Related Servers Score Discussions

Python

Hybrid

🚀 What's New in v4.1

OpenRouter Reasoning: Integrated the stepfun/step-3.5-flash:free model for high-performance analytical tasks. Use the new neuroverse_reason tool for deep thinking.
Reasoning Tokens: Real-time tracking of reasoning tokens for every request.
Voice Layer (v2.0): Built-in support for Whisper STT and Coqui TTS.

Related MCP server: Memory Nexus MCP

🚀 What is NeuroVerse?

Every time you start a new chat with Cursor, VS Code Copilot, or any MCP-compatible AI agent, it starts from zero — no memory, no safety, no understanding of your language. NeuroVerse is an MCP server that gives your agents:

	Feature	Description
🌐	Multilingual Intelligence	Understands mixed Indian languages — Tamil, Hindi, Telugu, Kannada, Malayalam, Bengali + English. Code-switching? No problem.
🎙️	Voice Layer	STT via Whisper and TTS via Coqui. Transcribe user audio and synthesize agent responses.
🧠	Intent Extraction	LLM-first structured intent extraction with deterministic rule-based fallback. Never misses a command.
💾	Tiered Memory	Short-term (session), Episodic (recent), Semantic (long-term facts) — all with importance scoring.
🛡️	3-Layer Safety (Kavach)	Keyword blocklist → Intent risk classifier → LLM judge. Blocks `DROP DATABASE` before it's too late.
🤖	Multi-Model Router (Marga)	OpenAI · Anthropic · Sarvam AI · Ollama · OpenRouter — routes each task to the best model automatically.
🔗	Agent-to-Agent (Setu)	REST+JSON agent registry with automatic fallback. Agents calling agents calling agents.
⚡	Async Everything	FastAPI + asyncpg + httpx. Sub-millisecond safety checks. Zero blocking.

⚡ NeuroVerse is a modular intelligence layer — not a monolith. Plug in what you need. Ignore what you don't.

🚀 Quick Start

1. Install

Option A: npm (recommended) — use anywhere

npm install neuroverse

Option B: From source (Python)

git clone https://github.com/joshua400/neuroverse.git
cd neuroverse
python -m pip install -e ".[dev]"

💡 Tip: If you installed via npm, the path is node_modules/neuroverse/dist/index.js. If from source, use the absolute path to your cloned directory.

2. Add NeuroVerse to your MCP config

NeuroVerse is a standard MCP server (stdio). Add it to your host's config:

Cursor / VS Code Copilot / Claude Desktop (npm)

{
  "mcpServers": {
    "neuroverse": {
      "command": "npx",
      "args": ["neuroverse"]
    }
  }
}

From source (Python)

{
  "mcpServers": {
    "neuroverse": {
      "command": "python",
      "args": ["mcp/server.py"],
      "cwd": "/path/to/neuroverse"
    }
  }
}

3. Tell your agent to use NeuroVerse

Add this to your agent's rules file (.md, .cursorrules, system prompt, etc.):

## NeuroVerse Integration
- Use `neuroverse_process` to handle any user request — it auto-detects language, extracts intent, checks safety, and executes.
- Use `neuroverse_reason` for complex tasks requiring analytical reasoning (powered by OpenRouter).
- Use `neuroverse_store` / `neuroverse_recall` for persistent context across sessions.
- Use `neuroverse_execute` for any potentially dangerous action — it will block destructive operations.

That's it. Two commands your agent needs to know:

Command	When	What happens
`neuroverse_process(text, user_id)`	Any user request	Detects language, extracts intent, safety-checks, executes
`neuroverse_store(user_id, intent, ...)`	End of work	Saves context for next session

Next session, your agent picks up exactly where it left off — like it never forgot.

Requirements

npm edition: Node.js 18+ (zero database deps — uses JSON files)
Python edition: Python 3.10+ + PostgreSQL (for persistent memory)

🤔 Why NeuroVerse?

Without NeuroVerse	With NeuroVerse
Agent only understands English	Agent understands Tamil, Hindi, Telugu, Kannada + English code-switching
`"anna file ah csv convert pannu"` → ❌ error	`"anna file ah csv convert pannu"` → ✅ converts file to CSV
Every session starts from zero	Agent remembers what it did — across sessions, across agents
`DROP DATABASE` → 💀 your data is gone	`DROP DATABASE` → 🛡️ blocked in < 1ms, zero tokens
Locked to one LLM provider	Routes to the best model for each task automatically
Two agents = chaos	Agent A hands off to Agent B seamlessly

Token Efficiency

NeuroVerse's safety layer runs at zero token cost — pure regex and rule matching, no LLM calls wasted:

Safety Approach	Cost per Check	Latency
LLM-based safety	500–2,000 tokens	1–5 seconds
Embedding-based	100–500 tokens	200–500ms
NeuroVerse Kavach	0 tokens	< 1ms

Over 100 tool calls per session, that's 50,000–200,000 tokens saved compared to LLM-based safety.

⚙️ How It Works

User Input (any language)
        │
   ┌────┴────┐
   │  Vani   │ ← Language detection + keyword normalisation
   │ (भाषा)  │   Tamil/Hindi/Telugu → normalised internal format
   └────┬────┘
        │
   ┌────┴────┐
   │  Bodhi  │ ← LLM intent extraction + rule-based fallback
   │ (बोधि)  │   Returns structured JSON with confidence
   └────┬────┘
        │
   ┌────┴────┐
   │ Kavach  │ ← 3-layer safety: blocklist → risk → LLM judge
   │ (कवच)   │   Blocks dangerous actions at zero token cost
   └────┬────┘
        │
   ┌────┴────┐
   │  Marga  │ ← Routes to best model (OpenAI/Anthropic/Sarvam/Ollama)
   │ (मार्ग)  │   Based on task type: multilingual/reasoning/local
   └────┬────┘
        │
   ┌────┴────┐
   │ Smriti  │ ← Stores/recalls from tiered memory
   │ (स्मृति) │   Short-term + Episodic + Semantic (PostgreSQL)
   └────┬────┘
        │
   Tool Execution + Response

🌐 Multilingual Intelligence — Vani

The Problem: Every MCP server speaks only English. 70% of India code-switches daily.

"anna indha file ah csv convert pannu"
         ↓
"anna this file ah csv convert do"     ← keyword normalisation (not full translation)
         ↓
Intent: convert_format { output_format: "csv" }

Hybrid Pipeline (Rule + LLM)

Input → Language Detect (langdetect) → Code-Switch Split → Keyword Normalise → Output

Key insight: Don't fully translate. Only normalise domain-critical keywords. The rest stays untouched — preserving context, tone, and nuance.

Supported Languages

Language	Keywords Mapped	Example
🇮🇳 Tamil	`pannu` → do, `maathru` → change, `anuppu` → send	`"file ah csv convert pannu"`
🇮🇳 Hindi	`karo` → do, `banao` → create, `bhejo` → send	`"report banao sales ka"`
🇮🇳 Telugu	`cheyyi` → do, `pampu` → send, `chupinchu` → show	`"data chupinchu"`
🇮🇳 Kannada	Support coming in v2	—
🇬🇧 English	Pass-through	`"convert json to csv"`

Code-Switch Detection

{
  "languages": ["ta", "en"],
  "confidence": 0.92,
  "is_code_switched": true,
  "original_text": "anna indha file ah csv convert pannu",
  "normalized_text": "anna this file ah csv convert do"
}

🧠 Intent Extraction — Bodhi

LLM-first. Rule-based fallback. Never fails.

LLM succeeds (confidence ≥ 0.5)?
   ├─ Yes → use LLM result
   └─ No  → rule-based parser (deterministic)

LLM Strategy

# Prompt to LLM:
"Extract structured intent from the following input.
 Return ONLY valid JSON: {intent, parameters, confidence}"

Rule-Based Fallback (7 patterns)

Pattern	Intent	Trigger Keywords
Format conversion	`convert_format`	convert, csv, json, excel, pdf
Summarisation	`summarize`	summarise, summary, brief, tldr
Report generation	`generate_report`	report, generate report
Deletion	`delete_data`	delete, remove, drop, clean
Data query	`query_data`	query, search, find, fetch, get
Communication	`send_message`	send, share, email, notify
Explanation	`explain`	explain, describe, what is, how to

Output

{
  "intent": "convert_format",
  "parameters": { "input_format": "json", "output_format": "csv" },
  "confidence": 0.87,
  "source": "rule"
}

The key difference: the code decides — not the LLM. If the LLM fails, hallucinates, or returns garbage, the rule engine takes over. Deterministic. Reliable.

💾 Tiered Memory — Smriti

The Problem: Raw logs are useless. Storing everything wastes resources. No relevance scoring.

NeuroVerse's approach: Score → Filter → Compress → Store.

Three Tiers

Tier	Storage	Lifetime	Use
Short-term	In-process dict	Current session	Active context, capped at 50 per user
Episodic	PostgreSQL	Recent actions	What the agent did recently
Semantic	PostgreSQL	Long-term facts	Persistent knowledge about users, projects, entities

Importance Scoring

if importance_score >= 0.4:
    persist_to_database()   # worth remembering
else:
    skip()                  # noise

Only important memories survive. No bloat. No irrelevant recall.

Context Compression

❌ Bad:  "The user asked about sales data three times in the last hour and seemed frustrated..."
✅ Good: { "intent": "sales_query", "frequency": 3, "sentiment": "frustrated" }

Structured JSON payloads, NOT raw text dumps. Compressed. Indexable. Queryable.

Memory Schema (PostgreSQL)

CREATE TABLE memory_records (
    id          TEXT PRIMARY KEY,
    user_id     TEXT NOT NULL,
    tier        TEXT NOT NULL,          -- short_term | episodic | semantic
    intent      TEXT NOT NULL,
    language    TEXT DEFAULT 'en',
    data        JSONB DEFAULT '{}',     -- compressed structured payload
    importance  REAL DEFAULT 0.5,
    created_at  TIMESTAMPTZ DEFAULT NOW(),
    updated_at  TIMESTAMPTZ DEFAULT NOW()
);
-- Indexed: user_id, intent, tier

🛡️ Safety Layer — Kavach

Three Layers — Defense in Depth

Agent calls tool  →  MCP Server receives request
                            │
                ┌───────────┴───────────┐
                │   Layer 1: Blocklist  │  ← regex + keywords, < 0.1ms
                └───────────┬───────────┘
                            │ pass
                ┌───────────┴───────────┐
                │  Layer 2: Risk Score  │  ← intent → risk classification
                └───────────┬───────────┘
                            │ pass
                ┌───────────┴───────────┐
                │  Layer 3: LLM Judge   │  ← optional model-based check
                └───────────┬───────────┘
                            │ pass
                     Execute handler

Layer 1 — Rule-Based Blocklist (Zero Cost)

Runs inside the MCP server. Pure regex. No network. No tokens.

Blocked keywords:

delete_all_data, drop_database, drop_table, system_shutdown,
format_disk, rm -rf, truncate, shutdown, reboot, erase_all, destroy

Blocked patterns (regex):

DROP (DATABASE|TABLE|SCHEMA)
DELETE FROM *
TRUNCATE TABLE
FORMAT [drive]:
rm (-rf|--force)

Layer 2 — Intent Risk Classification

Risk Level	Intents	Action
🟢 LOW	`convert_format`, `summarize`, `generate_report`, `query_data`, `explain`	✅ Allow
🟡 MEDIUM	`send_message`, `unknown`	⚠️ Block if strict mode
🔴 HIGH	`delete_data`	❌ Block always
⛔ CRITICAL	`drop_database`, `system_shutdown`	❌ Block always

Layer 3 — LLM Safety Judge (Optional)

If Layers 1–2 pass, optionally ask an LLM: "Is this safe?"

// LLM returns:
{ "safe": false, "reason": "This action would delete all user data." }

Safety Verdict

{
  "allowed": false,
  "risk_level": "critical",
  "reason": "Blocked keyword detected: 'drop_database'",
  "blocked_by": "rule"
}

Token Cost: Zero

Most AI safety:  Agent → "rm -rf /" → Safety LLM → 2,000 tokens burned
NeuroVerse:      Agent → "rm -rf /" → regex match → BLOCKED (0 tokens, < 1ms)

Strict Mode

# .env
SAFETY_STRICT_MODE=true    # Also blocks MEDIUM risk (unknown/send)
SAFETY_STRICT_MODE=false   # Only blocks HIGH and CRITICAL

🤖 Multi-Model Router — Marga

The Problem: Vendor lock-in. One model for everything. Overpaying.

NeuroVerse's approach: Route each task to the best model. Automatically.

Routing Logic

def route_task(task):
    if task.type == "multilingual":
        return sarvam_model        # Best for Indian languages
    elif task.type == "reasoning":
        return claude_or_openai    # Best for complex analysis
    elif task.type == "local":
        return ollama              # Free, on-device, private
    else:
        return best_available      # Fallback chain

Supported Providers

Provider	Default Model	Best For	Cost
🇮🇳 Sarvam AI	`sarvam-2b-v0.5`	Indian languages, multilingual	Low
🧩 OpenRouter	`stepfun/step-3.5-flash:free`	High-performance reasoning	Free
🧠 Anthropic	`claude-sonnet-4-20250514`	Reasoning, analysis	Medium
🤖 OpenAI	`gpt-4o`	General tasks, code	Medium
🦙 Ollama	`llama3`	Local, private, offline	Free

Benefits

	Without Marga	With Marga
Cost	Pay GPT-4 for everything	Use Ollama for simple tasks
Speed	Same latency for all tasks	Local models for fast tasks
Privacy	Everything goes to cloud	Sensitive data stays local
Vendor lock-in	Stuck with one provider	Switch anytime

Fallback Chain

If your preferred provider is down or unconfigured:

OpenRouter → Anthropic → OpenAI → Sarvam → Ollama (local, always available)

🔗 Agent-to-Agent — Setu

Agents calling agents calling agents.

Agent Registry

register_agent({
    "agent_name": "report_agent",
    "endpoint": "http://localhost:8001/generate",
    "capabilities": ["generate_report", "sales_analysis"]
})

Routing

{
  "target_agent": "report_agent",
  "task": "generate_sales_report",
  "payload": { "quarter": "Q1", "year": 2026 }
}

Fallback

If the target agent is unreachable:

{
  "success": false,
  "error": "Agent unreachable: ConnectError",
  "fallback": true
}

The caller can fall back to local execution. No hard failures.

🧩 MCP Tools

NeuroVerse exposes 6 tools via the Model Context Protocol:

#	Tool (npm)	Tool (Python)	Description
1	`neuroverse_process`	`india_mcp_process_multilingual_input`	Full pipeline: detect → normalise → intent → safety → execute
2	`neuroverse_store`	`india_mcp_store_memory`	Store a memory record in the tiered system
3	`neuroverse_recall`	`india_mcp_recall_memory`	Retrieve memories by user, intent, or tier
4	`neuroverse_execute`	`india_mcp_safe_execute`	End-to-end safe execution (convenience)
5	`neuroverse_route`	`india_mcp_route_agent`	Route a task to a registered downstream agent
6	`neuroverse_model`	`india_mcp_model_route`	Query the multi-model router (optionally invoke)
7	`neuroverse_transcribe`	`india_mcp_transcribe_audio`	Transcribe audio to text via Whisper STT
8	`neuroverse_synthesize`	`india_mcp_synthesize_speech`	Synthesize speech from text via Coqui TTS
9	`neuroverse_reason`	N/A	High-performance reasoning via OpenRouter

Real-World Example

── Session 1 (Agent Alpha, 2pm) ───────────────────────────
india_mcp_process_multilingual_input({
    text: "anna indha sales data ah csv convert pannu",
    user_id: "alpha",
    execute: true
})
→ Language: Tamil+English (code-switched)
→ Intent: convert_format { output_format: "csv" }
→ Safety: ✅ allowed (LOW risk)
→ Execution: ✅ success

india_mcp_store_memory({
    user_id: "alpha",
    intent: "convert_format",
    tier: "episodic",
    data: { "file": "sales_q1.json", "output": "csv" },
    importance_score: 0.8
})

── Session 2 (Agent Beta, next day) ───────────────────────
india_mcp_recall_memory({
    user_id: "alpha",
    intent: "convert_format",
    limit: 5
})
→ "Agent Alpha converted sales_q1.json to CSV yesterday"
→ Beta picks up exactly where Alpha left off

🌐 REST API

NeuroVerse also ships with a FastAPI REST layer — for non-MCP clients:

python app/main.py
# → http://localhost:8000/docs (Swagger UI)

Endpoint	Method	Description
`/health`	GET	Health check
`/api/process`	POST	Full multilingual pipeline
`/api/memory/store`	POST	Store memory
`/api/memory/recall`	POST	Recall memories

⚙️ Configuration

All settings via environment variables (.env):

# Database (PostgreSQL required for persistent memory)
DATABASE_URL=postgresql+asyncpg://user:password@localhost:5432/neuroverse

# AI Model API Keys (configure the ones you have)
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
SARVAM_API_KEY=...

# Ollama (local, free)
OLLAMA_BASE_URL=http://localhost:11434

# Safety
SAFETY_STRICT_MODE=true     # Block MEDIUM risk actions too

# MCP Transport
MCP_TRANSPORT=stdio          # or streamable_http
MCP_PORT=8000

🧪 Testing

python -m pytest tests/ -v

tests/test_intent.py     — 10 passed  (rule-based + async + mock LLM + fallback)
tests/test_language.py   — 10 passed  (keyword normalisation + detection + code-switch)
tests/test_pipeline.py   —  8 passed  (full e2e: English, Tamil, Hindi, dangerous, edges)
tests/test_safety.py     — 12 passed  (blocklist, regex, risk classification, pipeline)

============================= 40 passed in 0.87s ==============================

What's Tested

Category	Tests	Coverage
Language Detection	10	Tamil, Hindi, English, empty input, code-switch flag
Intent Extraction	10	All 7 rule patterns, LLM mock, LLM failure, empty
Safety Engine	12	Keywords, regex, risk levels, full pipeline, strict mode
Full Pipeline	8	E2E English, Tamil, Hindi, dangerous commands, edge cases

🏗️ Architecture

npm Edition (Node.js / TypeScript)

npm/
├── src/
│   ├── core/
│   │   ├── language.ts       # Vani  — Language detection (zero deps)
│   │   ├── intent.ts         # Bodhi — Intent extraction (LLM + fallback)
│   │   ├── memory.ts         # Smriti — Tiered memory (JSON files)
│   │   ├── safety.ts         # Kavach — 3-layer safety engine
│   │   └── router.ts         # Marga — Multi-model AI router
│   ├── services/
│   │   ├── executor.ts       # Tool registry + retry engine
│   │   └── agent-router.ts   # Setu — Agent-to-Agent routing
│   ├── types.ts              # TypeScript interfaces & enums
│   ├── constants.ts          # Shared constants
│   └── index.ts              # MCP Server — 6 tools (McpServer + Zod)
├── package.json              # npm publish config
├── tsconfig.json
└── LICENSE                   # Apache-2.0

Python Edition

app/
├── core/
│   ├── language.py           # Vani  — Language detection (langdetect)
│   ├── intent.py             # Bodhi — Intent extraction (LLM + fallback)
│   ├── memory.py             # Smriti — Tiered memory (PostgreSQL)
│   ├── safety.py             # Kavach — 3-layer safety engine
│   └── router.py             # Marga — Multi-model AI router
├── models/schemas.py         # 12 Pydantic v2 models
├── services/
│   ├── executor.py           # Tool registry + retry engine
│   └── agent_router.py       # Setu — Agent-to-Agent routing
├── config.py                 # Settings from environment
└── main.py                   # FastAPI REST entry point
mcp/server.py                 # MCP Server (FastMCP) — 6 tools
tests/                        # 40 tests (pytest)

Dependencies — Minimal

npm (3 packages):

Package	Purpose
`@modelcontextprotocol/sdk`	MCP protocol
`zod`	Schema validation
`axios`	HTTP requests

Python (7 packages):

Package	Purpose
`mcp[cli]`	Model Context Protocol SDK
`fastapi` + `uvicorn`	REST API layer
`pydantic`	Input validation (v2)
`langdetect`	Statistical language identification
`asyncpg` + `sqlalchemy[asyncio]`	PostgreSQL async driver
`httpx`	Async HTTP for model APIs

🚀 Roadmap

Phase	Status	What
v1.0	✅ Done	Multilingual parsing + intent extraction + 5 tools
v1.0	✅ Done	Tiered memory system (PostgreSQL)
v1.0	✅ Done	3-layer safety engine (Kavach)
v1.0	✅ Done	Multi-model router (Marga) + Agent routing (Setu)
v2.0	✅ Done	Voice layer (Whisper/Coqui) + Extended Multilingual
v3.0	✅ Done	Redis caching + Embedding-based semantic retrieval
v4.0	✅ Done	Reinforcement learning (RLHF) + Arachne contextual indexing
v4.1	✅ Done	OpenRouter Reasoning Layer Integration
v5.0	🔮 Future	Agent marketplace & external system plugins

🔐 Security

Measure	Implementation
API key management	Environment variables only — never in code
Input sanitisation	Pydantic v2 with field constraints on all inputs
Rate limiting	Planned for v2.0
Path traversal	N/A — no file system access by tools
SQL injection	Parameterised queries via SQLAlchemy
Encrypted storage	Delegated to PostgreSQL TLS

🤝 Contributing

Contributions are welcome! Here's how to get started:

Fork the repo
Create a feature branch (git checkout -b feature/amazing-feature)
Commit your changes (git commit -m 'feat: add amazing feature')
Push to the branch (git push origin feature/amazing-feature)
Open a Pull Request

Development Setup

# npm edition
git clone https://github.com/joshua400/neuroverse.git
cd neuroverse/npm
npm install
npm run build

# Python edition
cd neuroverse
python -m pip install -e ".[dev]"
python -m pytest tests/ -v    # All 40 should pass

📜 License

Apache-2.0

Available Tools

11 tools

neuroverse_assemble_contextAssemble Code Context (Arachne Protocol)B

Read-onlyIdempotent

Scan the codebase and assemble the most relevant file chunks based on a query.

ParametersJSON Schema

Name	Required	Description	Default
`dir`	No	Root directory to scan (defaults to cwd)
`query`	Yes	Search query for context assembly

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds little behavioral context beyond stating 'scan'. It does not mention output limits, performance, or auth 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?

Single sentence with no filler, immediately conveying the action and resource. Highly concise and front-loaded.

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?

With no output schema, the description should explain what 'assemble' means (e.g., format, relevance criteria). It fails to set expectations for the result, leaving a gap for the agent.

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 coverage is 100% with both parameters described. The description mentions 'query' but does not add further meaning beyond the schema for 'dir' (defaults to cwd) and 'query'.

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 'scan and assemble' and the resource 'codebase file chunks', and it distinguishes from sibling tools like neuroverse_recall by focusing on assembly for a query.

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 like neuroverse_recall or neuroverse_synthesize. The description only states what it does without providing selection criteria.

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

neuroverse_executeSafe ExecuteA

Parse, safety-check, and execute a user request end-to-end.

Convenience tool that chains: Language → Intent → Safety → Execute.

Args:

text (string): Raw user input
user_id (string): User / agent identifier

Returns: JSON with safety verdict and execution result

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Raw user input to parse, safety-check, and execute
`user_id`	No	User / agent ID	anonymous

TDQS

A3.9/5.0

Behavior4/5

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

Annotations indicate readOnlyHint=false and openWorldHint=true, and the description adds that the tool chains steps including safety-check and execution, returning a JSON with safety verdict. This provides useful behavioral context beyond what annotations alone offer.

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, using bullet points for args and returns. It gets straight to the point, though it could be slightly more compact by removing redundant phrasing.

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?

The description covers the tool’s flow, parameters, and return value. For a tool with only two parameters and no output schema, this is sufficient. It lacks explicit error handling details but is otherwise complete.

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 coverage is 100%, and the description largely repeats the parameter descriptions from the schema. However, it adds context by explaining the tool's chaining process, which indirectly clarifies the parameters' roles.

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 it parses, safety-checks, and executes user requests end-to-end. It distinguishes from sibling tools by describing it as a convenience tool that chains Language→Intent→Safety→Execute, which is specific and helpful.

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?

The description implies usage for end-to-end execution of user requests but does not explicitly specify when to use this tool versus alternatives like neuroverse_process or neuroverse_reason. No 'when-not' guidance is provided.

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

neuroverse_feedbackLog RLHF FeedbackB

Submit Reinforcement Learning from Human Feedback (RLHF) data for agent tuning.

ParametersJSON Schema

Name	Required	Description
`model`	Yes	The model used
`intent`	Yes	The intent executed
`rating`	Yes	Rating from 1 to 5
`feedback_text`	No	Optional human-readable feedback

TDQS

B3.3/5.0

Behavior2/5

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

No behavioral traits beyond what annotations imply are disclosed. The description does not mention side effects, authorization needs, rate limits, or how data is stored.

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?

Single sentence, front-loaded with purpose, no wasted words. Highly concise.

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 adequate for a simple submission tool. Lacks usage guidance and behavioral details, but parameters and annotations are sufficient for basic understanding.

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 100%, so baseline is 3. The description adds context about RLHF and agent tuning but does not significantly enhance understanding of individual parameters beyond the schema.

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 ('submit'), the resource ('RLHF data'), and the purpose ('agent tuning'). It distinguishes itself from siblings like neuroverse_execute or neuroverse_model by focusing on feedback logging.

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 versus alternatives, nor any prerequisites or context for using other tools. The description only states what the tool does, not when it should be invoked.

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

neuroverse_modelModel RouteA

Read-onlyIdempotent

Query the multi-model AI router.

If a prompt is provided, the prompt is sent to the routed model. Otherwise, returns only the routing decision.

Supported providers: OpenAI, Anthropic, Sarvam AI, Ollama.

Args:

task_type (string): multilingual | reasoning | local | general
prompt (string, optional): Prompt to send

Returns: JSON with routing decision and optional model response

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	No	Optional prompt to actually send to the routed model
`task_type`	No	Task type for routing	general

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already indicate read-only, idempotent, non-destructive behavior. The description adds context about conditional behavior (prompt present vs absent) and lists supported providers, going beyond what annotations provide.

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 and well-structured, with a clear summary followed by parameter details and return information. No superfluous content.

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 absence of an output schema, the return description is sufficient. All parameters are explained, and the tool's behavior under different inputs is clear. Missing details like error handling are acceptable for this complexity.

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 coverage is 100% with descriptions for both parameters. The description restates the enum values and notes prompt optionality, adding minimal extra meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it queries a multi-model AI router and differentiates between routing-only and prompt-sending modes. However, it does not distinguish itself from the similarly named sibling 'neuroverse_route', which may cause confusion.

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?

The description implies usage for getting routing decisions or model responses, but lacks explicit guidance on when not to use this tool or when to prefer alternatives like 'neuroverse_route'.

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

neuroverse_processProcess Multilingual InputA

Idempotent

Process mixed-language input through the full NeuroVerse pipeline.

Pipeline: Language Detect → Normalise → Intent Extract → Safety Check → (optional) Execute

Supported languages: Tamil, Hindi, Telugu, Kannada + English (code-switched).

Args:

text (string): Raw user input, possibly code-switched
user_id (string): User / agent identifier (default: "anonymous")
execute (boolean): Whether to also execute the intent (default: true)

Returns: JSON with keys: language, intent, safety, execution (if execute=true)

Examples:

"anna indha file ah csv convert pannu" → detects Tamil+English, extracts convert_format
"report banao sales ka" → detects Hindi+English, extracts generate_report
"drop database production" → BLOCKED by safety layer

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Raw user input (may be code-switched, e.g. Tamil+English)
`execute`	No	If true, also execute the extracted intent after safety check
`user_id`	No	Identifier for the user / agent	anonymous

TDQS

A4.1/5.0

Behavior4/5

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

The description adds behavioral context beyond annotations, detailing the pipeline stages (detect, normalize, extract, safety check) and safety blocking behavior, with no contradiction to annotations. Annotations are already informative, but the description enhances understanding.

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 well-structured with clear sections (pipeline, languages, args, returns, examples) and front-loads the purpose. It is slightly verbose but efficient overall.

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 complexity (pipeline, safety, code-switching) and absence of an output schema, the description provides return format and examples, making it fairly complete. Minor gaps remain (e.g., safety check details beyond example), but overall sufficient.

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?

Schema coverage is 100%, setting a baseline of 3. The description provides additional context for each parameter (e.g., text as raw input, execute default true) and includes helpful examples, exceeding the baseline.

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 it processes mixed-language input through a defined pipeline, lists supported languages, and distinguishes it from siblings like neuroverse_route or neuroverse_reason by specifying its role as the central processing tool.

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?

While the description implies usage for multilingual input processing, it lacks explicit guidance on when not to use it or how it compares to alternatives like neuroverse_route or neuroverse_execute.

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

neuroverse_reasonHigh-Performance ReasonA

Read-onlyIdempotent

Execute a complex reasoning task using specialized high-performance models (e.g. OpenRouter Reasoning). Returns the model's analytical response.

ParametersJSON Schema

Name	Required	Description	Default
`prompt`	Yes	The complex prompt requiring high-performance reasoning

TDQS

A4/5.0

Behavior4/5

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

Annotations (readOnlyHint, idempotentHint) are present and consistent, covering safety aspects. The description adds value by specifying the model type and return nature, but does not disclose potential latency or cost 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?

Single sentence, directly informative, no superfluous words. It earns its place.

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?

Despite no output schema, the description mentions the return type ('analytical response'). Parameter is fully described in schema, and annotations cover behavior. Minor gap: could specify output format.

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 100% schema description coverage, the parameter 'prompt' is already well-documented in the schema. The tool description adds no additional semantic detail beyond what the schema provides.

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 operation ('Execute a complex reasoning task'), the resource ('specialized high-performance models'), and the output ('analytical response'). It distinguishes itself from siblings like neuroverse_synthesize and neuroverse_recall by specifying high-performance reasoning.

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?

The description implies usage for complex reasoning tasks but does not explicitly state when to use this tool versus alternatives. No exclusion criteria or when-not-to-use guidance is provided.

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

neuroverse_recallRecall MemoryA

Read-onlyIdempotent

Retrieve memories from NeuroVerse's tiered memory system.

Args:

user_id (string): Agent / user identifier
intent (string, optional): Filter by intent
tier (string, optional): Filter by tier
semantic_query (string, optional): Search constraint for vector engine
limit (number): Max results (1–100, default 10)

Returns: JSON array of matching MemoryRecords

ParametersJSON Schema

Name	Required	Description
`tier`	No	Filter by tier
`limit`	No	Max results
`intent`	No	Filter by intent
`user_id`	Yes	Agent / user identifier
`semantic_query`	No	Query for semantic retrieval reranking

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, fully covering the tool's safety profile. The description adds minimal behavioral context beyond that (e.g., returns JSON array), so it meets but does not exceed expectations.

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 reasonably concise, using a docstring format that lists parameters and return value. It is front-loaded with the main purpose. A slightly shorter version could achieve the same 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?

For a retrieval tool with 5 fully documented parameters and clear annotations, the description provides adequate context: purpose, parameters, and return type. It does not discuss ordering or pagination, but these are less critical given the limit parameter.

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 100%, so the schema already documents all parameters. The description repeats the parameter list and default/range for limit, but adds no deeper meaning beyond what is in the schema.

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 'retrieve' and the resource 'memories from NeuroVerse's tiered memory system', making the tool's purpose unambiguous. It distinguishes well from sibling tools like 'neuroverse_store' and 'neuroverse_assemble_context'.

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?

The description implies usage for memory recall but does not provide explicit when-to-use or when-not-to-use guidance compared to sibling tools. No alternatives or exclusions are mentioned.

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

neuroverse_routeRoute to AgentB

Route a task to a registered downstream agent via HTTP.

Args:

target_agent (string): Name of the agent
task (string): Task description
payload (object): Arbitrary payload

Returns: JSON with the agent's response or a fallback error

ParametersJSON Schema

Name	Required	Description
`task`	Yes	Task description to send
`payload`	No	Arbitrary payload for the target
`target_agent`	Yes	Name of the registered agent

TDQS

B3.2/5.0

Behavior3/5

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

Annotations declare readOnlyHint=false and destructiveHint=false. The description adds that the tool uses HTTP and returns JSON with a fallback error, but does not elaborate on behavioral traits beyond what annotations already convey.

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 relatively short and front-loaded with the main action. It lists arguments and return value efficiently, though it could be slightly more concise by not repeating schema info.

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?

Without an output schema, the description explains the return value as 'JSON with the agent's response or a fallback error.' It covers the basics but misses potential details like error handling, timeouts, or network behavior.

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 100%, with each parameter already described in the JSON schema. The description repeats these with slight variations, adding no new semantic information beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it routes a task to a registered downstream agent via HTTP, specifying the three arguments and return value. The purpose is clear, but it does not explicitly differentiate from sibling tools like neuroverse_execute or neuroverse_process.

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?

The description provides no guidance on when to use this tool versus alternatives. It lacks context for appropriate usage scenarios 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.

neuroverse_storeStore MemoryA

Store a memory record in NeuroVerse's tiered memory system.

Tiers:

short_term: In-process, capped at 50 per user. Lost on restart.
episodic: Persisted to JSON file. Recent actions.
semantic: Persisted to JSON file. Long-term facts.

Only episodic/semantic memories with importance_score ≥ 0.4 are persisted.

Args:

user_id (string): Agent / user identifier
intent (string): Canonical intent name
tier (string): short_term | episodic | semantic
language (string): Language code (default: "en")
data (object): Structured payload
importance_score (number): 0.0–1.0

Returns: JSON of the stored MemoryRecord

ParametersJSON Schema

Name	Required	Description	Default
`data`	No	Structured memory payload
`tier`	No	Memory tier	short_term
`intent`	Yes	Canonical intent this memory relates to
`user_id`	Yes	Agent / user identifier
`language`	No	Primary language code	en
`importance_score`	No	Importance score — only above 0.4 are persisted for episodic/semantic

TDQS

A4.7/5.0

Behavior5/5

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

Discloses key behaviors: short-term lost on restart, only episodic/semantic memories with importance_score ≥ 0.4 are persisted. No contradiction with 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?

Well-structured with bullet points, front-loaded purpose, and no redundant sentences.

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?

Covers behavioral nuances (persistence, loss), return format, and all parameters despite no output schema.

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?

Schema coverage is 100%, but description adds value by explaining importance_score threshold and tier semantics, exceeding baseline.

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 stores a memory record and explains the three tiers, distinguishing it from siblings like neuroverse_recall.

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?

Provides detailed tier descriptions (short_term for in-process, episodic for recent actions, semantic for long-term facts) and importance threshold, but lacks explicit when-not-to-use or alternatives.

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

neuroverse_synthesizeSynthesize SpeechA

Synthesize text to speech using Coqui TTS.

Args:

text (string): Text to synthesize
language (string): Language code

Returns: JSON with the path to the generated audio file

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes	Text to synthesize into speech
`language`	No	Language code (e.g. en, ta, hi)	en

TDQS

A3.5/5.0

Behavior3/5

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

Annotations provide readOnlyHint=false, openWorldHint=true, which hint at mutation and external dependencies. The description adds that it uses Coqui TTS and returns a file path, but does not detail latency, file format, or potential side effects.

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 and well-organized with a clear one-line action, parameter list, and return description. However, it could be slightly more efficient by merging the parameter list into prose.

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 simple tool (2 params, no output schema), annotations present, the description adequately covers purpose, parameters, and return. It misses limitations like max text length or supported languages beyond examples, but is mostly complete.

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 has 100% coverage of parameters with descriptions. The description repeats the schema info without adding new meaning, so baseline 3 applies.

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 synthesizes text to speech using Coqui TTS, specifying the verb and resource. It distinguishes from siblings like neuroverse_transcribe (speech-to-text) and neuroverse_process (generic).

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 versus alternatives like neuroverse_execute or neuroverse_process. No context about prerequisites 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.

neuroverse_transcribeTranscribe AudioB

Read-onlyIdempotent

Transcribe an audio file to text using Whisper STT.

Args:

audio_path (string): Absolute path to the audio file

Returns: JSON with the transcribed text

ParametersJSON Schema

Name	Required	Description	Default
`audio_path`	Yes	Absolute path to the audio file to transcribe

TDQS

B3.2/5.0

Behavior2/5

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

Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate safe, read-only behavior. Description adds only that it returns JSON with transcribed text, but lacks details on file size limits, supported audio formats, or any side effects. Minimal extra value beyond 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?

Two sentences with clear front-loading of purpose, followed by a structured Args/Returns section. Every sentence is essential and no waste.

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 simple tool (1 param, no output schema), description lacks important details like supported audio formats, file size limits, or potential error cases. Given sibling tools with different purposes, this missing information could hinder correct invocation.

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 coverage is 100% with 'audio_path' fully described as 'Absolute path to the audio file to transcribe'. Description repeats this in Args section, adding no new semantic information. Baseline score of 3 is appropriate; no extra context or constraints provided.

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 verb (transcribe), resource (audio file), and specific technology (Whisper STT). No sibling tool appears to offer transcription, so purpose is distinct and unambiguous.

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 versus alternatives or any prerequisites. Among siblings, there is no similar tool, but explicit context about file format support, size limits, or exclusion criteria is missing.

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.

11 tool updatesv1.0.0Mar 22, 2026
- First observedneuroverse_assemble_context
- First observedneuroverse_execute
- First observedneuroverse_feedback
- First observedneuroverse_model
- First observedneuroverse_process
- First observedneuroverse_reason
- First observedneuroverse_recall
- First observedneuroverse_route
- First observedneuroverse_store
- First observedneuroverse_synthesize
- First observedneuroverse_transcribe

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 clear and distinct purpose, covering different aspects like memory, language processing, model routing, audio, and execution. There is no overlap that would cause confusion for an agent.

Naming Consistency5/5

All tools follow a consistent 'neuroverse_verb_noun' pattern using snake_case, making them predictable and easy to navigate.

Tool Count5/5

With 11 tools, the set is well-scoped for a multi-modal AI platform. Each tool provides necessary functionality without being excessive.

Completeness4/5

The tool surface covers core operations like memory storage/retrieval, model queries, language processing, and audio handling. Minor gaps exist (e.g., no explicit memory update or delete tool), but the overall set is robust for common tasks.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

memra
com.usememra
Persistent memory for AI agents. EU-hosted, privacy-first, hybrid recall, contradiction detection.
Knowledge & Memory Autonomous Agents
2
Hipocampo MCP
io.github.carrasquelalex1
Bilingual dual memory with SSC for AI agents. Semantic search, embeddings, profiles.
Knowledge & Memory Search AI & Machine Learning
1
fixflow A
io.github.MagneticDogSon
Collective memory for AI agents. One agent solves a bug — every agent gets the fix instantly.
Knowledge & Memory Autonomous Agents RAG Systems
32
nucleus B
io.github.eidetic-works
Sovereign Agent OS — Persistent Memory, Governance & Compliance for AI Agents.
Autonomous Agents Knowledge & Memory Security
2824

Related MCP Servers

FixFlow
Knowledge & Memory Autonomous Agents Developer Tools
MagneticDogSon
A
license
A
quality
C
maintenance
Collective memory for AI agents. One agent solves a bug - every agent in the world gets the fix instantly.
Updated 6 months ago (2026-03-12 12:03 UTC)
3
MIT
Memory Nexus MCP
Knowledge & Memory Autonomous Agents AI & Machine Learning
KairosMobius
A
license
A
quality
D
maintenance
Enables AI agents with persistent semantic memory, including semantic recall, knowledge graphs, and instant domain expertise via pre-built Intelligence Packs.
Updated 7 months ago (2026-02-11 04:04 UTC)
10
67
MIT
universal-memory
Knowledge & Memory Developer Tools
YanAmorelli
A
license
C
quality
A
maintenance
A vendor-agnostic cognitive persistence layer for AI agents. Eliminate the "repetition tax" by transporting your context, preferences, and history across sessions. Features an auto-adaptation engine that syncs global instructions to ensure operational cohesion and optimize token usage across any LLM or multi-agent workflow.
Updated 11 days ago (2026-08-25 15:22 UTC)
38
6
Apache 2.0
Shared Workspace MCP
Autonomous Agents Knowledge & Memory Developer Tools
WhileTrueBlackObelizk
A
license
Not graded
quality
B
maintenance
Local-first memory, pipelines, learning, feedback, and safe code tools for AI coding agents.
Updated 24 days ago (2026-08-12 11:34 UTC)
MIT

Appeared in Searches

Building an AI-native media studio with autonomous agents for film, game, and interactive world creation

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/joshua400/neuroverse'

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

🚀 What's New in v4.1

🚀 What is NeuroVerse?

Table of Contents

🚀 Quick Start

1. Install

2. Add NeuroVerse to your MCP config

3. Tell your agent to use NeuroVerse

Requirements

🤔 Why NeuroVerse?

Token Efficiency

⚙️ How It Works

🌐 Multilingual Intelligence — Vani

Hybrid Pipeline (Rule + LLM)

Supported Languages

Code-Switch Detection

🧠 Intent Extraction — Bodhi

LLM Strategy

Rule-Based Fallback (7 patterns)

Output

💾 Tiered Memory — Smriti

Three Tiers

Importance Scoring

Context Compression

Memory Schema (PostgreSQL)

🛡️ Safety Layer — Kavach

Three Layers — Defense in Depth

Layer 1 — Rule-Based Blocklist (Zero Cost)

Layer 2 — Intent Risk Classification

Layer 3 — LLM Safety Judge (Optional)

Safety Verdict

Token Cost: Zero

Strict Mode

🤖 Multi-Model Router — Marga

Routing Logic

Supported Providers

Benefits

Fallback Chain

🔗 Agent-to-Agent — Setu

Agent Registry

Routing

Fallback

🧩 MCP Tools

Real-World Example

🌐 REST API

⚙️ Configuration

🧪 Testing

What's Tested

🏗️ Architecture

npm Edition (Node.js / TypeScript)

Python Edition

Dependencies — Minimal

🚀 Roadmap

🔐 Security

🤝 Contributing

Development Setup

📜 License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API