Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Moorcheh MCP Server search my documents for AI ethics"
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.
There are two ways to use the Moorcheh MCP server:
The easiest way to get started:
# Set your API key and run directly
MOORCHEH_API_KEY=your_api_key_here npx -y @moorchehai/mcpIf you prefer to clone and run locally:
Clone the repository
git clone https://github.com/moorcheh-ai/moorcheh-mcp.git
cd moorcheh-mcpInstall dependencies
npm installGet your Moorcheh API key
Visit Moorcheh Dashboard
Sign in to your account
Go to your account settings
Generate or copy your API key
Set up your environment
# Copy the example environment file
cp env.example .envEdit the .env file
# Open .env in your preferred editor
# Replace 'your_moorcheh_api_key_here' with your actual API key
MOORCHEH_API_KEY=your_actual_api_key_herenpm startThat's it! Your Moorcheh MCP server is now running and ready to use.
Related MCP server: Hashnode Universal MCP Server
To use the Moorcheh MCP server with Claude Desktop:
https://github.com/user-attachments/assets/fccbba8e-7393-4b74-8a73-769b55b3f3a3
Download Claude Desktop from https://claude.ai/download
Install and launch Claude Desktop
Option A: Using NPX (Recommended)
In Claude Desktop, go to Settings → Developer
Click Edit Config
Configure the server with these settings:
{
"mcpServers": {
"moorcheh": {
"command": "npx",
"args": ["-y", "@moorchehai/mcp"],
"env": {
"MOORCHEH_API_KEY": "your_actual_api_key_here"
}
}
}
}Option B: Local Installation
In Claude Desktop, go to Settings → Developer
Click Edit Config
Configure the server with these settings:
{
"mcpServers":{
"moorcheh": {
"command": "node",
"args": [
"path\\to\\moorcheh-mcp\\src\\server\\index.js"
],
"env": {
"NODE_ENV": "development"
}
}
}
}Important:
For Option A: Replace your_actual_api_key_here with your actual Moorcheh API key
For Option B: Replace path\\to\\moorcheh-mcp\\src\\server\\index.js with the actual path to your index.js file and create .env in moorcheh-mcp with your API key
Save the configuration file and restart Claude Desktop completely
Start a new conversation in Claude Desktop
Ask Claude to list the available tools: "Can you list down my namespaces?"
You should see tools like list-namespaces, search, answer, etc.
To use the Moorcheh MCP server with Cursor IDE:
Download Cursor from https://cursor.com
Install and launch Cursor
Option A: Using NPX (Recommended)
In Cursor, go to Settings → Tools & integration
Click Add MCP Server
Configure the server with these settings:
{
"mcpServers": {
"moorcheh": {
"command": "npx",
"args": ["-y", "@moorchehai/mcp"],
"env": {
"MOORCHEH_API_KEY": "your_actual_api_key_here"
}
}
}
}Option B: Local Installation
In Cursor, go to Settings → Tools & integration
Click Add MCP Server
Configure the server with these settings:
{
"mcpServers":{
"moorcheh": {
"command": "node",
"args": [
"path\\to\\moorcheh-mcp\\src\\server\\index.js"
],
"env": {
"NODE_ENV": "development"
}
}
}
}For Option A: Replace your_actual_api_key_here with your actual Moorcheh API key in the configuration
For Option B: Create .env in moorcheh-mcp directory and add your API key with MOORCHEH_API_KEY=your_key_here
Open a new chat in Cursor (Cmd/Ctrl + L)
Ask the AI to list available Moorcheh tools: "What Moorcheh tools can I use?"
You should see tools like list-namespaces, search, answer, etc.
The Moorcheh MCP server provides tools for:
Namespace Management: Create, list, and delete namespaces for organizing your data
Document Operations: Upload and manage text documents and vector embeddings
Advanced Search: Perform semantic search across your data
AI-Powered Answers: Get intelligent responses based on your stored data
list-namespaces: View all your available namespaces
create-namespace: Create a new namespace for storing data
delete-namespace: Remove a namespace and all its contents
upload-text: Upload text documents to a namespace
upload-vectors: Upload vector embeddings to a namespace
upload-file: Upload files to a text namespace via pre-signed URL (supported types: .pdf, .docx, .xlsx, .json, .txt, .csv, .md)
list-files: List raw file objects in S3 storage for a namespace (GET /list-files; see List Files)
delete-file: Delete one or more raw files from S3 storage (DELETE /delete-file with file_name and/or file_names; see Delete File)
fetch-text-data: List text and summary chunks from a text namespace (GET /documents/fetch-text-data, up to 100 items per response; see Fetch Text Data)
get-data: Retrieve text documents by ID from text namespaces
delete-data: Remove specific data items from a namespace
search: Search across namespaces with vector similarity
answer: Get AI-generated answers based on top of your search
These IDs match the current Moorcheh Available Models list (REST answer / Python answer.generate).
Model ID | Name | Provider | Description |
| Claude Sonnet 4.6 | Anthropic | Fast flagship: coding, tools, long docs and RAG (~1M context) |
| Claude Opus 4.6 | Anthropic | Deepest reasoning and hardest tasks; pick when quality matters most (~1M context) |
| Llama 4 Maverick 17B | Meta | Long context, summarization, function calling, fine-tuning friendly |
| Amazon Nova Pro | Amazon | Chat, math, and structured answers for AWS-style workloads |
| DeepSeek R1 | DeepSeek | Step-by-step reasoning; math, logic, and technical explanations |
| DeepSeek V3.2 | DeepSeek | Efficient general Q&A, multilingual, everyday RAG (~164K context) |
| OpenAI GPT OSS 120B | OpenAI | Large generalist: research-style answers and long-form writing |
| Qwen 3 32B | Qwen | Code and bilingual (EN/ZH) tasks in a smaller footprint |
| Qwen3 Next 80B A3B | Qwen | MoE model for long chats, docs, and code at scale (~256K context) |
Node.js: Version 18.0.0 or higher
Moorcheh Account: Active account with API access
Git: For cloning the repository
For development with auto-reload:
npm run devScript | Description |
| Start the MCP server |
| Start in development mode with auto-reload |
| Run tests (when available) |
Variable | Description | Required | Default |
| Your Moorcheh API key | Yes | None |
"Missing required API_KEY environment variable"
Make sure you've created a .env file
Verify your API key is correctly set in the .env file
Check that the API key is valid in your Moorcheh dashboard
"Forbidden: Check your API key"
Your API key may be invalid or expired
Generate a new API key from the Moorcheh dashboard
Update your .env file with the new key
"Network Error"
Check your internet connection
Verify the API endpoints are accessible
Try again in a few minutes
GitHub Issues: https://github.com/moorcheh-ai/moorcheh-mcp/issues
Moorcheh Documentation: https://console.moorcheh.ai/docs/mcp
Moorcheh Dashboard: https://console.moorcheh.ai
This project is licensed under the Apache License 2.0 - see the LICENSE file for details.
We welcome contributions! Please feel free to submit a Pull Request.
For a detailed list of changes, see CHANGELOG.md.
Get AI-generated answers based on data in a namespace using text queries. This tool provides intelligent, context-aware responses by searching through your stored text documents and generating comprehensive answers using advanced language models. Supports two modes: Search Mode (with namespace) and Direct AI Mode (empty namespace).
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | Yes | Namespace to answer questions from. For Search Mode: provide a text namespace containing documents to search for context. For Direct AI Mode: provide empty string "" to make direct AI model calls without searching your data. | |
| query | Yes | Text query for AI answer generation. Provide a natural language question or prompt that you want the AI to answer. The AI will search through your namespace content and generate a comprehensive response based on the relevant information found. | |
| top_k | No | Number of top results to return. Controls how many relevant documents the AI considers when generating an answer. Default is 10. Use lower values (3-5) for focused answers, higher values (8-10) for comprehensive responses that consider more context. | |
| type | No | Search type for answer generation. Supported value is 'text'. | |
| threshold | No | Similarity threshold for results. A value between 0 and 1 that filters documents based on relevance before generating the answer. Higher values (0.7-0.9) ensure only highly relevant content is used, lower values (0.3-0.5) include more context. Required when kiosk_mode is true. | |
| kiosk_mode | No | Kiosk mode for restricted search. When true, search is restricted to specific namespaces with threshold filtering, providing more controlled and focused answers suitable for production environments. | |
| ai_model | No | AI model ID for answer generation (snake_case field sent to the API). Supported models: 'anthropic.claude-sonnet-4-6' (Claude Sonnet 4.6), 'anthropic.claude-opus-4-6-v1' (Claude Opus 4.6), 'meta.llama4-maverick-17b-instruct-v1:0' (Llama 4 Maverick 17B), 'amazon.nova-pro-v1:0' (Amazon Nova Pro), 'deepseek.r1-v1:0' (DeepSeek R1), 'deepseek.v3.2' (DeepSeek V3.2), 'openai.gpt-oss-120b-1:0' (OpenAI GPT OSS 120B), 'qwen.qwen3-32b-v1:0' (Qwen 3 32B), 'qwen.qwen3-next-80b-a3b' (Qwen3 Next 80B A3B). If omitted, the Moorcheh API uses its default model for your account. | |
| chat_history | No | Chat history for AI answer generation. Provide previous conversation context to help the AI maintain continuity and reference earlier parts of the conversation. This enables more coherent multi-turn conversations. | |
| header_prompt | No | Header prompt for AI answer generation. Custom instructions that define the AI's role, style, and behavior. Use this to create specialized assistants (e.g., technical support, friendly helper, formal advisor) or set specific guidelines for response generation. | |
| footer_prompt | No | Footer prompt for AI answer generation. Additional instructions that are applied after the main response generation. Useful for formatting requirements, citation styles, or specific response patterns that should be consistently applied. | |
| temperature | No | Temperature for AI answer generation. Controls the creativity and randomness of responses. Lower values (0.1-0.3) produce more focused, deterministic answers. Higher values (0.7-1.0) produce more creative, varied responses. Default is 0.7. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the two operational modes and explains that the tool searches documents and generates answers. However, it does not mention whether the operation is read-only, any side effects like consumption of AI credits, or potential latency. Lacks details on authentication or rate limits. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Reasonably concise, with purpose stated upfront. Two short paragraphs. Some redundancy (e.g., 'Get AI-generated answers' and 'provides intelligent, context-aware responses' are similar). Could be slightly tighter, but overall well-structured for a tool with many parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters and no output schema, the description covers the two modes and parameter semantics well. However, it does not describe the return value or response format, which is a notable gap. For completeness, it should state what the AI generates (e.g., a string answer) or mention any pagination. Error cases or prerequisites (e.g., namespace must contain data) are not addressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds significant value beyond the schema: explains the dual purpose of namespace, defaults for top_k, condition for threshold, lists specific model IDs with names, clarifies role and content in chat_history, and distinguishes header/footer prompts. This goes beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what the tool does: 'Get AI-generated answers based on data in a namespace using text queries.' Clearly explains two modes (Search vs Direct AI) which distinguishes it from sibling tools like 'search' that retrieve raw data. The purpose is specific and contrasts effectively with nearby tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use each mode (namespace for search-based answers, empty string for direct AI). While it doesn't explicitly contrast with sibling tools, the description implies usage for generated answers vs raw search. Could be improved by explicitly stating when not to use this tool (e.g., for raw document retrieval, use 'search' instead).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new namespace for document storage in Moorcheh
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the namespace to create | |
| type | No | Type of namespace (text, vector, etc.) | |
| vector_dimension | No | Vector dimension for vector namespaces |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects, permissions needed, or any constraints beyond the brief action statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single short sentence, no wasted words. Could be slightly more structured but effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters (1 required) and no output schema, the description is minimal. It does not explain return values, error conditions, or the relationship between parameters like vector_dimension and type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Create') and resource ('namespace for document storage') and distinguishes from sibling tools like delete-namespace and list-namespaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like list-namespaces or delete-namespace. No context about prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete specific data items from a namespace in Moorcheh
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the namespace to delete from | |
| data_type | No | Data type to delete from. Use 'documents' for text namespaces and 'vectors' for vector namespaces. Default is 'documents'. | |
| ids | Yes | Array of document/vector IDs to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Lacks disclosure of key behavioral traits like permanence, reversibility, or permission requirements. No annotations are present to compensate, leaving agents unaware of the destructive nature's implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no redundant information, efficiently conveying the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal context given the tool's destructive nature and lack of output schema. Does not explain return values, error handling, or idempotency, leaving gaps for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds value by clarifying enum choices for data_type with usage context ('Use 'documents' for text namespaces…'), beyond the schema's description. Schema coverage is 100%, so baseline is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states delete action on specific data items within a namespace, distinguishing from sibling tools like delete-namespace which removes an entire namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for deleting specific items by ID but provides no explicit when-to-use or comparisons to alternatives, such as delete-namespace for bulk removal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete file(s) from document storage (S3) for a namespace. Use snake_case: file_name (one file) and/or file_names (array). At least one is required. This deletes storage objects, not indexed documents by pipeline ID (use delete-data for documents/vectors by id).
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Namespace that contains the file(s). You must own this namespace. | |
| file_name | No | Single file to delete (e.g. "document.pdf"). Can be combined with file_names. | |
| file_names | No | Multiple files to delete, e.g. ["a.pdf", "b.docx"]. Can be combined with file_name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the destructive behavior ('Permanently delete') and the scope (namespace). However, it does not mention additional traits like irreversibility, authorization needs, or error conditions, which would enhance transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and uses no unnecessary words. Every sentence adds information: purpose, usage, and differentiation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for a delete operation with 3 parameters and 100% schema coverage. It includes scope, naming conventions, and sibling differentiation. However, it lacks information about return values or confirmation of deletion, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds value by explaining the snake_case naming convention and clarifying that at least one of file_name or file_names is required, which is not evident from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Permanently delete file(s) from document storage (S3) for a namespace.' It identifies the specific resource (file(s) in S3) and differentiates from the sibling tool 'delete-data' by clarifying that it deletes storage objects, not indexed documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool and when to use the alternative: 'This deletes storage objects, not indexed documents by pipeline ID (use delete-data for documents/vectors by id).' It also specifies the naming convention ('snake_case') and requirement ('At least one is required').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a namespace and all its contents from Moorcheh
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the namespace to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose irreversible destructive behavior, permissions needed, or confirmation steps. It merely states the action without warnings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, efficiently conveys the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive operation with no annotations or output schema, the description omits behavioral details (e.g., permanence, return value) and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Delete) and resource (namespace) and explicitly states 'all its contents', distinguishing it from sibling tools like delete-file and delete-data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., delete-data) or prerequisites (e.g., namespace must exist).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List text and summary chunks from a text-type namespace via GET /documents/fetch-text-data. Returns up to 100 items per request with statistics (text vs summary counts, source_counts). Only text namespaces are supported; not for vector namespaces. See Moorcheh API docs.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the text namespace (e.g. my-docs). Must be a text-type namespace. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses returns up to 100 items and statistics, implying a read operation. However, it lacks explicit statements about non-destructiveness, authentication needs, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no filler. Front-loaded with essential information (action, resource, endpoint, limits).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains return structure (up to 100 items, statistics) and references API docs for more detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds no additional meaning beyond the schema's description of namespace_name. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists text and summary chunks from a text-type namespace via a GET endpoint. Differentiates from vector namespaces but does not explicitly contrast with sibling tools like get-data or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies that only text namespaces are supported (a when-not), but does not provide guidance on when to use this tool versus alternatives such as search or get-data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get specific data items by ID from a text namespace in Moorcheh
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the text namespace to read from | |
| ids | Yes | Array of document IDs to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It describes the action as 'Get', implying a read operation, but does not disclose authentication needs, error handling for missing IDs, rate limits, or any side effects. The lack of such context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, no fluff, and directly conveys the core action. Every part is necessary, and it is front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should explain what is returned (e.g., data items, errors). It does not. With two simple parameters and no behavioral details, the description is insufficient for the agent to fully understand the tool's behavior and output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both parameters have descriptions). The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'specific data items by ID', and the scope 'from a text namespace in Moorcheh'. It distinguishes itself from siblings like 'fetch-text-data' (which likely retrieves all data) and 'search' (which is keyword-based) by specifying retrieval by ID.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have known IDs, but it does not explicitly state when to use this tool versus alternatives like 'fetch-text-data' or 'search'. No 'when not to use' or alternative names are provided, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List file objects stored in document storage (S3) for a namespace: file_name, size (bytes), last_modified. This is raw storage listing (e.g. after upload-url uploads), not indexed text documents. GET only; no body.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Namespace name. Must exist and belong to your account. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description provides behavioral details: it's a GET request with no body, returning raw storage file list (file_name, size, last_modified). It clarifies it's safe and read-only. It does not mention error conditions or limits, but enough for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the purpose and then adding context. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the use case, return fields, and nature of data. For a simple tool with one parameter and no output schema, it is nearly complete. Minor omission: no mention of pagination or ordering, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the sole parameter with description 'Namespace name. Must exist and belong to your account.' The tool description adds no additional parameter information beyond the schema. With 100% schema coverage, baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List file objects stored in document storage (S3) for a namespace', specifying a specific verb (list) and resource (file objects) with a namespace context. This distinguishes it from sibling tools like list-namespaces or fetch-text-data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes guidance on when to use ('after upload-url uploads') and when not ('not indexed text documents'). It also notes the method ('GET only; no body'). However, it could be more explicit about when to prefer this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available namespaces in Moorcheh
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation but discloses no additional behavioral traits such as rate limits, response structure, or error conditions. The behavior is straightforward but minimally documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the essential purpose. Every word is necessary, and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a simple behavior, the description is largely complete. It could mention return format or error handling, but for a basic list tool, the current description is sufficient for an agent to understand its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description adds no parameter details because none exist, which is acceptable. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all available namespaces in Moorcheh', using a specific verb and resource. It effectively distinguishes from siblings like create-namespace and delete-namespace.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies the tool is for listing namespaces, it provides no explicit guidance on when to use it versus alternatives. For a simple list tool, usage is implicit, but the lack of any explicit direction lowers the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for data in a namespace using semantic search or vector similarity. This tool provides powerful search capabilities across your namespaces, supporting both text-based semantic search and vector-based similarity search. For text search, you can use natural language queries to find relevant documents based on meaning rather than just keywords. For vector search, you can find similar content by comparing vector embeddings. The tool supports advanced features like result filtering, similarity thresholds, metadata filters, keyword filters, and kiosk mode for production environments. This is ideal for building intelligent search interfaces, recommendation systems, or content discovery features.
Filtering Capabilities:
Metadata Filters: Use #key:value format (e.g., #category:tech, #priority:high)
Keyword Filters: Use #keyword format (e.g., #important, #urgent)
Filters only apply to text search and metadata must be manually uploaded with documents
| Name | Required | Description | Default |
|---|---|---|---|
| namespaces | Yes | Namespaces to search in. Provide an array of namespace names where you want to search for content. You can search across multiple namespaces simultaneously. All namespaces must be accessible with your API key. | |
| query | Yes | Search query. For text search: provide a natural language query string (e.g., 'tell me about the company?', 'how to configure authentication?'). For vector search: provide an array of numbers representing a vector embedding (e.g., [0.1, 0.2, 0.3, ..., 0.768]). The query type will be automatically detected based on the input format. DO NOT USE QUOTES IN THE QUERY FOR VECTOR SEARCH. Filtering: For text search, you can include filters in your query: - Metadata filters: #category:tech #priority:high - Keyword filters: #important #urgent - Combine both: 'serverless benefits #category:tech #important' | |
| query_type | No | Type of query to perform. 'text' for semantic search using natural language queries. 'vector' for similarity search using vector embeddings. If not specified, the type will be automatically detected based on the query format (string for text, array for vector). | |
| top_k | No | Number of top results to return. Controls how many search results are returned, with higher values providing more comprehensive results. Default is 10. Use lower values (3-5) for focused results, higher values (10-20) for broader exploration. | |
| threshold | No | Similarity threshold for results. A value between 0 and 1 that filters results based on similarity score. Higher values (0.7-0.9) return only highly similar results, lower values (0.3-0.5) return more comprehensive results. Required when kiosk_mode is true. | |
| kiosk_mode | No | Kiosk mode for restricted search. When true, search is restricted to specific namespaces with threshold filtering, providing more controlled results suitable for production environments. When false, search across all specified namespaces without strict filtering. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auto-detection of query type, behavior of filters, kiosk mode, and threshold requirements. It also warns against using quotes for vector search. However, it omits rate limits or authentication details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary and then detailed sections. While slightly verbose, each sentence adds value. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not describe the structure of search results (e.g., scores, metadata). For a search tool of moderate complexity, describing the return format would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the description adds significant value by explaining query auto-detection, filter syntax (metadata/keyword), top_k usage recommendations, threshold range and kiosk mode purpose. This goes well beyond the schema's basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches data using semantic or vector similarity, and it distinguishes itself from siblings like get-data or fetch-text-data by focusing on search vs direct retrieval. It provides specific use cases like building search interfaces, recommendation systems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use text versus vector search and describes filtering capabilities, but does not explicitly state when not to use this tool in favor of siblings like 'answer' or 'get-data'. It provides contextual guidance for usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a file to a text namespace using pre-signed URL flow. The tool requests an upload URL, uploads the file directly to storage, then the file is queued for processing and indexing.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the text namespace to upload the file to | |
| file_path | Yes | Absolute path to the file to upload. Must be one of: .pdf, .docx, .xlsx, .json, .txt, .csv, .md |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds behavioral context about the pre-signed URL flow, direct storage upload, and queuing for processing/indexing. Could mention failure modes or limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. Technical terms like 'pre-signed URL flow' are precise but may require familiarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description covers upload process. Could specify return value (e.g., upload ID). Sufficient for a file upload tool with sibling context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for namespace_name and file_path. Description adds no additional parameter detail beyond the flow context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it uploads a file to a text namespace using a pre-signed URL flow. It distinguishes from siblings like upload-text (which likely handles text directly) and delete-file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the flow but does not explicitly state when to use this tool versus alternatives like upload-text or list-files. Usage is implied but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload text documents to a namespace in Moorcheh
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the namespace to upload to | |
| documents | Yes | Array of documents to upload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without disclosing behavioral traits like whether it overwrites existing documents, what happens on failure, or any rate limits or authorization requirements. The verb 'Upload' implies mutation, but further details are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence that conveys the tool's core function without any extraneous words. It is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is too brief to provide sufficient context. It does not cover return values, error handling, idempotency, or any prerequisites beyond what the schema implies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters and their meanings. The description adds no additional information beyond the schema, meeting the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action ('Upload'), resource ('text documents'), and destination ('to a namespace in Moorcheh'). It clearly distinguishes from sibling tools like upload-file and upload-vectors by specifying 'text documents', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or conditions. For example, it does not say whether the namespace must exist or how to handle duplicate IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload vector data to a namespace in Moorcheh
| Name | Required | Description | Default |
|---|---|---|---|
| namespace_name | Yes | Name of the namespace to upload to | |
| vectors | Yes | Array of vectors to upload |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the one-line description does not disclose behavioral traits such as whether the upload appends or overwrites, or what the response contains. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. It is appropriately sized and front-loaded with the core action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks completeness. It does not explain return values, error handling, or prerequisites like namespace existence. More context is needed for a tool with nested objects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, so the parameters are well-documented in the schema itself. The description adds no extra meaning beyond what the schema provides, meeting the baseline for schema-rich tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (upload), the resource (vector data), and the target (namespace in Moorcheh). It effectively distinguishes from sibling tools like upload-file and upload-text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. No prerequisites or conditions are mentioned, though the context implies its use for vector data uploads.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.4answercreate-namespacedelete-datadelete-filedelete-namespacefetch-text-dataget-datalist-fileslist-namespacessearchupload-fileupload-textupload-vectorsScored across 13 tools
Most tools have distinct purposes, but 'answer' and 'search' could be confused as both involve querying data. However, descriptions clarify that 'answer' generates responses while 'search' retrieves results.
Tools use snake_case with a verb_noun pattern (e.g., create-namespace, delete-data), but 'answer' is a single verb without a noun, deviating from the pattern.
13 tools cover namespace management, file/document operations, search, and Q&A without being excessive or sparse for the domain.
The set includes CRUD for namespaces and data, but lacks update operations for namespaces and data, and missing a get-file tool for downloading. Minor gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
A Model Context Protocol server for Wix AI tools
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/moorcheh-ai/moorcheh-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server