Calypso Multimodal RAG MCP Server
OfficialThis server is a hosted multimodal RAG MCP server that lets agents ask grounded questions over text and visual knowledge files with verifiable citations.
Ask grounded, multi-turn RAG questions via
calypso-rag-agent, with optional model variants,fileIds, and/newto reset conversation context.List knowledge buckets to inspect ids, slugs, names, status, member/source counts, and bucket-store readiness.
Upload knowledge files individually or in batches (1–100), with local
filePathor base64 content, metadata, tags, idempotency keys, optional bucket creation, and indexing/batch readiness waits.Fetch knowledge file metadata and indexing status, optionally verifying against the provider.
Create buckets and RAG agent variants bound to buckets, with new agents becoming immediately available.
Discover resources such as server info, RAG model catalogs, bucket listings, workflow guides, and security notes, plus reusable prompts for grounded questions, ingestion, and conversation resets.
Supports natively multimodal content: PDFs, screenshots, charts, diagrams, and images via Gemini File Search.
Integrates with n8n workflows to enable AI agents to perform RAG queries and knowledge management through Calypso's multimodal retrieval layer.
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., "@Calypso Multimodal RAG MCP Serverfind the quarterly sales figures from the PDF report"
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.
Calypso MCP Server
Hosted multimodal RAG for Claude Desktop, Cursor, and agent workflows — in one npx command.
Ask questions across PDFs, screenshots, charts, and diagrams, and upload new source material, without running a vector store, a Docker stack, or an OCR pipeline. Answers come back with citations you can check.
This server is a Calypso Context surface — the same knowledge layer that backs Calypso on WhatsApp, exposed to MCP clients. How the pieces fit →
One-command setup:
npx -y @calypsohq/multimodal-rag-mcp-server --api-key sk-your-key-hereTrue multimodal RAG: handles text and visuals natively through Gemini File Search
Upload and query: dedicated tools for durable knowledge files and batch uploads
Multi-turn conversations: context-aware answers with
/newresetDiscoverable workflows: resources and prompts for safe RAG, upload, and ingestion flows
GitHub | Docs | Smithery | Official MCP Registry
Tags: multimodal-rag, gemini-rag, hosted-rag-mcp, mcp-server
Instead of wiring each agent or workflow to a one-off document search stack, use this MCP as the agent-facing entry point to one reusable answer layer: upload source material once, retrieve across text and visual content, and return answers with evidence users can verify.
Quick Start
# One-liner with npx
npx -y @calypsohq/multimodal-rag-mcp-server --api-key "sk-your-key-here"Or with environment variables:
CALYPSO_API_KEY="sk-..." npx -y @calypsohq/multimodal-rag-mcp-serverThen add the same command to Claude Desktop, Cursor, or Smithery using the configuration examples below.
Related MCP server: RAG-Anything MCP Server
Why Choose Calypso
No local vector store, no Docker Compose, and no separate OCR or vision pipeline before an agent can ask a grounded question. Point the server at a Calypso API key and it discovers your team's agents and knowledge buckets on connect.
Zero infrastructure: one
npxcommand; nothing to host or operate.Multimodal without a second pipeline: text and visuals are indexed together, so a chart or a screenshot is queryable the same way a paragraph is.
Answers carry evidence: responses include source references and retrieval metadata.
Read and write: query knowledge and add to it — files, batches, and websites — from the same server.
What you get
Production multimodal Calypso agent with multi-turn memory
Built-in upload tools for single files and batch knowledge uploads
Automatic discovery of your team's RAG variants and knowledge buckets
Verifiable citations with source references and retrieval metadata
Read-only resources and reusable prompts for safe workflows
Why Multimodal-First RAG
Most company knowledge is not only text. The answer often lives across a setup screenshot, a PDF table, a product diagram, a help-center page, or a chart inside a report. Calypso packages that full knowledge surface into a single retrieval layer so agents can ask grounded questions without guessing from generic model memory.
Search the formats users actually rely on: documentation, PDFs, screenshots, charts, diagrams, product images, support articles, manuals, policies, FAQs, and reports.
Ground answers before the model writes: Gemini File Search retrieves relevant text and visual context first, then the Calypso agent answers from that source material.
Show the evidence trail: responses can include source references, page-aware grounding, and retrieval metadata so people can verify before they trust.
Scope retrieval with metadata: use workspace, team, customer, language, file type, status, or other metadata to keep answers relevant without duplicating knowledge bases.
Reuse the same knowledge layer everywhere: connect Cursor, Claude Desktop, AI agents, n8n workflows, product UI, support flows, and website experiences to the same source-backed layer.
In practice, this means your agent can answer questions like:
"Explain this setup screenshot and the attached policy PDF. What should the support rep do next?"
"What does this onboarding PDF say about approval rules?"
"Why is this setup screen failing?"
"Compare the pricing chart with our plan documentation and recommend the right tier."
"Summarize the policy that applies to this support ticket."
"Which product plan fits this customer based on our pricing docs?"
"Compare the diagrammed ingestion flow with the retrieval flow."
What this MCP does
With calypso-agent you can:
Ask grounded questions against the configured Calypso knowledge base
Select any discovered team RAG variant with the optional
modelargumentContinue a multi-turn conversation via the native
/v1/responsesconversation modelReset the conversation context with
/newUse the same OpenAI-compatible Responses endpoint that serves
calypso-agentDiscover built-in resources and prompts for the supported Calypso workflows
Requirements
Node.js 18+
The server uses Web Fetch API primitives (
fetch,Headers,Request,Response,FormData,Blob, andFile) for API calls and SDK compatibility. The package bootstraps missing globals at startup for MCP runtimes that expose only part of the Node 18+ Web API surface.A Calypso API endpoint that exposes:
POST /v1/responsesGET /v1/rag-agent/modelsGET /v1/knowledge/bucketsPOST /v1/knowledge/files/upload-sessionPOST /v1/knowledge/files/upload-session/{session_id}/finalizePOST /v1/knowledge/files:batch/upload-sessionPOST /v1/knowledge/files:batch/upload-session/{batch_id}/finalizeGET /v1/knowledge/batches/{batch_id}
A Calypso API key (
sk-...)
Configuration
Environment variables:
CALYPSO_API_KEY(required)CALYPSO_API_BASE_URL(optional, defaulthttps://api.calypso.so/v1)
CLI flags:
--api-key--api-base-url
Configuration precedence:
CLI flags / Smithery-provided command arguments
Environment variables
Default base URL (
https://api.calypso.so/v1)
Run with npx
npx -y @calypsohq/multimodal-rag-mcp-server --api-key "sk-..."Run with environment variables
env CALYPSO_API_KEY="sk-..." CALYPSO_API_BASE_URL="https://api.calypso.so/v1" npx -y @calypsohq/multimodal-rag-mcp-serverConfigure in Cursor
Add a new MCP server (command type) like:
npx -y @calypsohq/multimodal-rag-mcp-server --api-key sk-... --api-base-url https://api.calypso.so/v1Configure in Claude Desktop
1. Open Claude Desktop MCP config
In Claude Desktop:
Claude -> Settings -> Developer -> Edit Config
On macOS, the file is usually:
~/Library/Application Support/Claude/claude_desktop_config.jsonClaude Desktop uses claude_desktop_config.json for desktop MCP servers. Claude Code uses separate config locations such as ~/.claude.json or project-level .mcp.json.
2. Add the Calypso MCP server
Paste this into claude_desktop_config.json:
{
"mcpServers": {
"Calypso Multimodal RAG": {
"command": "npx",
"args": [
"-y",
"@calypsohq/multimodal-rag-mcp-server"
],
"env": {
"CALYPSO_API_KEY": "sk-your-calypso-api-key",
"CALYPSO_API_BASE_URL": "https://api.calypso.so/v1"
}
}
}
}Replace:
sk-your-calypso-api-key
with your real Calypso API key.
3. Restart Claude Desktop fully
Fully quit Claude Desktop, then reopen it.
Do not only close the window. On macOS:
Cmd + QAfter restart, the MCP should appear in Claude with these tools available:
calypso-agentcalypso-list-bucketscalypso-upload-filecalypso-upload-files-batch
Optional: Save Claude Artifacts To Your Mac
Calypso provides hosted multimodal RAG tools. It does not write generated reports, summaries, CSVs, JSON files, or web-search artifacts directly to your local computer.
To let Claude Desktop save generated files locally, add the standard filesystem MCP server alongside Calypso and restrict it to a dedicated safe folder.
Create the folder first:
mkdir -p ~/ClaudeThen add both servers to claude_desktop_config.json:
{
"mcpServers": {
"Calypso Multimodal RAG": {
"command": "npx",
"args": [
"-y",
"@calypsohq/multimodal-rag-mcp-server"
],
"env": {
"CALYPSO_API_KEY": "sk-your-calypso-api-key",
"CALYPSO_API_BASE_URL": "https://api.calypso.so/v1"
}
},
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/Users/yourname/Claude"
]
}
}
}Fully quit and reopen Claude Desktop after changing the config.
Example prompt:
Use Calypso for the grounded RAG answer, then save the final report as /Users/yourname/Claude/report.md using the filesystem tool.For safety, only grant filesystem access to a dedicated folder such as ~/Claude, not your whole home directory.
Concern | Best Owner |
Source-backed RAG answers | Calypso MCP |
Uploading files into Calypso | Calypso MCP |
Writing | filesystem MCP |
Web search artifacts from Claude | Claude plus filesystem MCP prompt |
Smithery
The server is available on Smithery and launches through the same npx package path used by desktop clients.
Smithery user config:
calypsoApiKey(required)calypsoApiBaseUrl(optional, defaults tohttps://api.calypso.so/v1)
The Smithery launch path is equivalent to:
npx -y @calypsohq/multimodal-rag-mcp-server --api-key sk-... --api-base-url https://api.calypso.so/v1Use calypsoApiBaseUrl only when targeting a self-hosted Calypso-compatible deployment. The cloud default does not need an override.
Troubleshooting
Missing API key: provide
--api-keyorCALYPSO_API_KEYWrong API host: make sure
--api-base-url/CALYPSO_API_BASE_URLends in/v1Self-hosted deployment: only override the base URL if you are not using
https://api.calypso.so/v1Smithery launch mismatch: use the packaged
npx -y @calypsohq/multimodal-rag-mcp-serverpath instead of runningnode dist/index.jsfrom a fresh cloneFormData is not definedorHeaders is not defined: upgrade to the latest package. The MCP server bootstraps missing Web Fetch API globals before upload tools run.ENOENT for
/mnt/user-data/uploads/...: that path belongs to a hosted agent or attachment sandbox, not necessarily to the MCP server. Retry withcontentBase64instead offilePath.Local artifact saving: Calypso answers can be used with Claude Desktop's filesystem MCP server, but Claude must be explicitly asked to save the final output to an allowed local path.
Choosing filePath vs contentBase64
Use filePath for local MCP installs, including Claude Desktop and Cursor configs that launch this package with a local command such as:
npx -y @calypsohq/multimodal-rag-mcp-serverIn that setup, the MCP server process runs on your machine and can read paths available to the same user account. Pass the local path directly; the server reads raw bytes and uploads them through the Calypso upload-session URL. You do not need to base64-encode local files.
Use contentBase64 for hosted or remote MCP clients, including Smithery-hosted servers, browser/cloud runtimes, generated in-memory content, and agent containers. In those environments, a path on your Mac or workstation is not readable by the MCP server process.
If a path starts with /mnt/user-data/uploads, /mnt/data, /mnt/attachments, or another hosted sandbox prefix, do not send it as filePath unless this MCP server is running in that same sandbox. Use contentBase64 or another inline byte source instead.
Available tools
calypso-agent
Direct Calypso agent access.
Notes:
It does not auto-route to other personas or agents.
It automatically discovers the API key's available
calypso-agentvariants at startup.Use the optional
modelargument to choose a named variant such ascalypso-agent:pricing.Each model variant keeps its own MCP conversation chain, so switching variants does not continue the wrong thread.
It uses
POST /v1/responsesinstead ofPOST /v1/chat/completions.First turns create a named conversation, and follow-up turns chain with
previous_response_id.Optional
fileIdsare supported for retrieval-scoped questions. New uploads should use the durable knowledge upload tools and wait for indexing before asking.Use
/newas the prompt to reset the MCP conversation.
calypso-search
Searches your knowledge directly and returns matching passages, without asking an agent to compose an answer.
Use it when you want evidence rather than prose — checking whether something is indexed at all, gathering sources before a decision, or letting a calling agent do its own reasoning over the passages.
Notes:
Uses
POST /v1/search.queryis required.agentscopes the search to one agent variant's knowledge;bucketsnarrows it to specific buckets.maxResultsis clamped to 1–20.
Example:
{
"query": "annual plan refund window",
"buckets": ["support-handbook"],
"maxResults": 5
}calypso-list-buckets
Lists buckets for the team tied to the configured Calypso API key.
Notes:
Uses
GET /v1/knowledge/buckets.Does not accept
team_id; Calypso derives team scope from the API key.Returns bucket ids, slugs, names, status, member counts, source counts, and bucket-store readiness.
Defaults to active buckets only. Pass
includeArchived: truewhen you need archived buckets for audits or cleanup.Use this before
calypso-upload-fileorcalypso-upload-files-batchwhen you need to choose a destination bucket.calypso://rag-agent-modelsanswers which buckets are bound to each RAG variant.calypso-list-bucketsanswers which buckets exist for the API key's team.
Example:
{
"includeArchived": false
}calypso-get-file
Fetches one knowledge file's metadata and indexing status by file id.
Notes:
Uses
GET /v1/knowledge/files/{file_id}.Resolves the opaque
fileIdsfromcalypso-list-bucketsinto filename, mime type, size, indexing status, and per-bucket sync state.Pass
verify: trueto cross-check against the provider (?verify=gemini) — slower, but authoritative when a status looks stale.
Example:
{
"fileId": "file_123",
"verify": true
}calypso-add-website
Ingests a website into a knowledge bucket, so page content becomes queryable alongside uploaded files.
Notes:
Uses
POST /v1/knowledge/websites.urlis required, and so is a destination — one ofbucketIds,bucketSlugs, orbucket.Optional
title,tagsHint, andpreferredLanguagehelp classify the source.Pass
idempotencyKeyto make a retry safe; it is sent as theIdempotency-Keyheader.Like file uploads, acceptance is not the same as being queryable — the page still has to finish indexing.
Example:
{
"url": "https://example.com/pricing",
"bucket": "pricing",
"title": "Public pricing page",
"idempotencyKey": "pricing-page-2026-08"
}calypso-create-bucket
Creates an empty bucket for the create-then-fill workflow.
Notes:
Uses
POST /v1/knowledge/buckets(requires a backend with this endpoint deployed and theknowledge:bucket:createcapability on the API key).The server normalizes the slug; collisions return a typed
bucket_slug_existserror.idempotencyKeyreplays return the existing bucket instead of erroring.Uploads can still create buckets implicitly via
bucketSlugs+createMissingBuckets; this tool exists for creating the destination first.
Example:
{
"name": "Product docs",
"slug": "product-docs",
"idempotencyKey": "create-product-docs-1"
}calypso-create-agent
Creates a Calypso agent variant bound to one or more buckets.
Notes:
Uses
POST /v1/rag-agent/agents(requires a backend with this endpoint deployed and therag:agent:createcapability on the API key).The success payload leads with
model— pass it straight tocalypso-agent.Bucket bindings are validated server-side: unknown or archived buckets return
bucket_not_found; agent id collisions returnagent_id_exists; the plan's agent cap returnsagent_limit_reached.Creating an agent refreshes the model catalog and emits MCP
tools/list_changed+resources/list_changednotifications, so the new variant is usable without reconnecting.
Example:
{
"agentId": "support",
"name": "Support agent",
"bucketSlugs": ["product-docs"],
"idempotencyKey": "create-support-agent-1"
}calypso-upload-file
Uploads a file into the durable bucket-backed knowledge store and indexing pipeline.
Notes:
Uses
POST /v1/knowledge/files/upload-session, uploads bytes directly to storage, then finalizes withPOST /v1/knowledge/files/upload-session/{session_id}/finalize.Uploads use JSON session requests plus signed binary
PUTs, not multipart form uploads.Returns file and task metadata, not a chat attachment
file_id.Requires one bucket destination via
bucketIds,bucketSlugs, orbucket.Use
filePathfor local Claude Desktop/Cursor MCP installs where the server can read the path. UsecontentBase64for hosted or remote MCP clients that cannot read local paths.If an agent sees a path like
/mnt/user-data/uploads/file.pdf, it should not send that asfilePath; it should send the file bytes ascontentBase64.Supports optional
title,tags,metadata, andidempotencyKey.Route uploads into existing buckets with
bucketIdsorbucketSlugs, or usebucketas a single-slug shortcut.Pass
createMissingBuckets: truewith bucket slugs when you want Calypso to create missing destinations during upload.Can optionally wait until indexing reaches a ready state before returning.
Example:
{
"filename": "handbook.pdf",
"mimeType": "application/pdf",
"filePath": "/Users/me/Documents/handbook.pdf",
"bucket": "support-handbook",
"createMissingBuckets": true,
"waitForIndexing": true
}calypso-upload-files-batch
Uploads 1 to 100 files into the durable knowledge store in one request.
Notes:
Uses
POST /v1/knowledge/files:batch/upload-session, uploads each accepted item directly to storage, then finalizes withPOST /v1/knowledge/files:batch/upload-session/{batch_id}/finalize.Uploads use JSON session requests plus signed binary
PUTs, not multipart form uploads.Requires
batchIdempotencyKey; Calypso uses it to derive the durable batch id for retries.Requires a shared bucket destination via
bucketIds,bucketSlugs, orbucket, unless every item provides its own bucket destination.Supports shared
bucketIds,bucketSlugs,bucket, andcreateMissingBucketsdefaults, plus per-item overrides.Use per-item
filePathfor local Claude Desktop/Cursor MCP installs where the server can read each path. Use per-itemcontentBase64for hosted or remote MCP clients that cannot read local paths.Generates Firestore-safe
client_file_idvalues whenclientFileIdis omitted.acceptedorqueuedmeans the upload is durable, not necessarily query-ready. UsewaitForBatchReady: trueto pollGET /v1/knowledge/batches/{batch_id}?include_items=true.Inspect per-item status,
bucketSyncStatus, andbucketSyncto distinguish indexed content from bucket-ready retrieval.
Example:
{
"batchIdempotencyKey": "kb-seed-2026-06-04",
"bucket": "support-handbook",
"createMissingBuckets": true,
"items": [
{
"filename": "faq.txt",
"mimeType": "text/plain",
"filePath": "/Users/me/Documents/faq.txt"
}
],
"waitForBatchReady": true
}Available resources
calypso://server-info
Read-only server metadata, including package version, API base URL, transport, authentication model, and exposed capabilities.
calypso://rag-agent-models
Read-only runtime catalog of team-scoped calypso-agent model variants discovered from the configured API key, including each variant's active buckets, bucket_ids, and missing_bucket_ids. If discovery is unavailable, this resource falls back to the base calypso-agent.
calypso://buckets
Read-only runtime list of knowledge buckets for the team tied to the configured API key. Use it to inspect bucket ids/slugs and bucket-store readiness before uploads.
calypso://workflows
A compact guide to the supported RAG and file-upload workflows.
calypso://security
Operational security notes for API keys, local file reads, uploads, and logging.
Available prompts
calypso-question: draft a grounded knowledge-base question forcalypso-agentcalypso-ingestion: prepare a durable knowledge-store upload and follow-up querycalypso-reset-conversation: start a clean RAG thread with/new
Common workflows (copy/paste)
Knowledge retrieval
Summarize a topic:
Summarize the knowledge base guidance for campaign approvals
Ask for a specific answer:
What does our documentation say about indexing retries?
Compare two concepts:
Compare file indexing with retrieval execution in the current architecture
Start a fresh thread:
/new
Multi-turn follow-up
Refine a previous answer:
Focus only on the ingestion path and ignore retrieval
Ask for sources or justification:
Explain which documented components are involved and why
Knowledge-store file flow
Discover buckets:
Call
calypso-list-bucketsor readcalypso://bucketsbefore choosing a destination
Upload durable knowledge:
Call
calypso-upload-filewith the file payload and optionaltitle,tags, ormetadataPrefer
filePathfor local Claude Desktop/Cursor MCP installs; usecontentBase64for hosted or remote MCP clients that cannot read local paths
Route knowledge into buckets:
Use
bucket: "support-handbook"for one destination,bucketSlugsfor multiple slug-based destinations, orbucketIdswhen you already have stable bucket ids
Create bucket destinations on demand:
Add
createMissingBuckets: truewhen using slug-based bucket assignment and the destination may not exist yet
Wait for indexing:
Pass
waitForIndexing: trueif you want the tool to block until the knowledge file is indexed
Knowledge-store batch flow
Upload many durable files:
Call
calypso-upload-files-batchwithitems,batchIdempotencyKey, andfilePathper item for local MCP installs; usecontentBase64per item for hosted or remote MCP clients
Route the batch into buckets:
Put shared
bucket,bucketSlugs,bucketIds, orcreateMissingBucketson the tool call, then override per item only when needed
Wait for query readiness:
Use
waitForBatchReady: trueand inspect returned item status plus bucket sync fields before querying fresh content
Tips
Start over: use
/newto reset the MCP conversation (newconversation_id+ cleared response chain).
Version history
Version | Notes |
3.0.0 | Breaking. Removed legacy |
2.4.0 | Renamed the ask tool |
2.3.x | Search release and follow-up fixes. |
See CHANGELOG.md for detail.
Upgrading to 3.0.0
Two renames landed across 2.4.0 and 3.0.0, and neither is aliased.
The ask tool is
calypso-agent(wascalypso-rag-agent). MCP clients pick this up on their nexttools/list, but any saved prompt, agent instruction, or documentation that names the tool as a string needs updating.Model ids must be canonical.
calypso-rag-agentandcalypso-rag-agent:{id}are no longer rewritten tocalypso-agent[:{id}]. Passing one now fails withUnknown Calypso agent model, which namescalypso://rag-agent-modelsas the place to find valid ids. Read that resource, or omitmodelto use the discovered default.
The calypso://rag-agent-models resource URI is deliberately unchanged. It is a published address, not a compatibility shim.
Available Tools
4 toolscalypso-list-knowledge-bucketsA
[CALYPSO LIST KNOWLEDGE BUCKETS] Lists knowledge buckets for the team tied to the configured Calypso API key.
Use this before uploads when you need bucket ids, slugs, names, member counts, or bucket-store readiness. This complements RAG model discovery: model discovery shows which buckets are bound to each agent variant, while this tool lists all buckets for the API key team.
| Name | Required | Description | Default |
|---|---|---|---|
| includeArchived | No | If true, include archived buckets. Defaults to false. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It indicates a read-only listing operation and clarifies scope (team tied to the API key), but does not disclose potential rate limits, pagination, or default behavior nuances beyond the schema. It is adequate but not rich.
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 concise and front-loaded with the core action. The bracketed header repeats the tool name, adding slight redundancy, but every other sentence contributes meaningful usage context. It earns a high score for efficiency without unnecessary detail.
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 one-parameter tool with no output schema, the description provides a complete picture of purpose, usage context, and relationship to other tools. It hints at return values by listing retrievable fields, but does not explicitly describe the response format (e.g., array of objects). This is a minor gap.
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 the includeArchived parameter already described in the schema. The description does not add parameter-specific meaning beyond the schema, only mentions the types of data returned (bucket ids, slugs, etc.), which are not directly parameter semantics. Baseline 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 tool's function with a specific verb ('Lists'), resource ('knowledge buckets'), and scope ('for the team tied to the configured Calypso API key'). It also differentiates from sibling tools by explaining its use before uploads and how it complements model discovery.
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 gives explicit when-to-use guidance: 'Use this before uploads when you need bucket ids, slugs, names, member counts, or bucket-store readiness.' It also contrasts with RAG model discovery. However, it lacks explicit when-not-to-use or alternative tool exclusions, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calypso-rag-agentA
[CALYPSO RAG AGENT] Sends each prompt directly to the Calypso RAG agent using the full conversation context.
Use this when you want Calypso knowledge retrieval and grounded answers from the RAG backend. Typical requests:
"Summarize the key points from our onboarding documentation"
"What does the knowledge base say about campaign approval rules?"
"Compare the documented indexing flow with the retrieval flow"
"Answer using the uploaded file ids: ["file_123"]"
Responses API behavior:
First turns start a named Calypso conversation via
/v1/responses.Follow-up turns chain with
previous_response_idso the backend owns conversation state.When
fileIdsare provided, the MCP usesrag_policyretrieval semantics instead of inline attachment stuffing.
MCP session behavior:
This tool maintains a stable conversation id in the background for multi-turn retrieval context.
Use
/newto start a fresh conversation and clear the current context window.
Quick commands (examples):
"Summarize the latest indexed knowledge about WhatsApp templates"
"Find the source of truth for campaign approval behavior"
"Start a new topic" (or use
/new)
Available RAG models: calypso-rag-agent.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Optional RAG model variant. Defaults to `calypso-rag-agent`. Available models: calypso-rag-agent. | |
| prompt | Yes | Your request. Include context, constraints, and desired output. | |
| fileIds | No | Optional uploaded agent-store `file_id` values to attach with `rag_policy` retrieval semantics. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains behavior: maintains conversation state, chains follow-up turns via previous_response_id, uses rag_policy for fileIds, and supports /new to reset context. This goes well beyond what the schema reveals.
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 fairly long but organized into sections (Responses API, MCP session, quick commands). Every section adds value, though some repetition (model name listed twice) and length could be trimmed slightly.
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's complexity and no output schema/annotations, the description covers conversation state, file handling, and usage examples. Missing return format details, but the overall context is sufficiently complete for effective use.
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 meaning by explaining fileIds trigger rag_policy retrieval semantics, and clarifies model default. This enriches the parameter documentation.
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 explicitly states the tool's verb and resource: 'Sends each prompt directly to the Calypso RAG agent using the full conversation context.' It clearly distinguishes this from sibling tools (which list/upload knowledge files) by focusing on retrieval and grounded answers.
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?
It gives explicit usage context: 'Use this when you want Calypso knowledge retrieval and grounded answers from the RAG backend.' It provides typical request examples and quick commands. However, it does not explicitly mention when NOT to use it or name alternative tools for other actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calypso-upload-knowledge-fileA
[CALYPSO UPLOAD KNOWLEDGE FILE] Uploads a file into the durable bucket-backed knowledge store and indexing pipeline.
Use this when you want a file indexed into the broader knowledge corpus instead of
attached directly to a single RAG chat turn. This tool returns knowledge-file and task metadata.
A bucket destination is required: pass bucketIds, bucketSlugs, or bucket.
Choose exactly one file source. Use filePath when this MCP server runs locally and can read the path, including Claude Desktop or Cursor configs that launch this package with npx. Use contentBase64 for hosted or remote MCP clients, browser uploads, generated in-memory content, or remote sandbox files that this MCP process cannot read. Do not base64-encode local files just to use this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | Optional tags for knowledge-store organization. | |
| title | No | Optional human-readable title stored with the knowledge file. | |
| bucket | No | Convenience single bucket slug for this upload. Required unless bucketIds or bucketSlugs is provided. | |
| filePath | No | Preferred for local MCP installs, including Claude Desktop and Cursor configs that run this package with a local command such as npx. Absolute or relative path readable by the machine running this MCP server. The server reads raw bytes and uploads them through the Calypso upload-session URL; no user-side base64 conversion is needed. | |
| filename | Yes | Display filename for the uploaded knowledge file. | |
| metadata | No | Optional metadata object serialized onto the upload request. | |
| mimeType | Yes | Content type for the uploaded knowledge file. | |
| bucketIds | No | Existing knowledge bucket ids to assign this upload to. Required unless bucketSlugs or bucket is provided. | |
| bucketSlugs | No | Knowledge bucket slugs to assign this upload to. Required unless bucketIds or bucket is provided. | |
| contentBase64 | No | Inline file bytes as base64. Use when filePath is not possible, such as hosted or remote MCP servers, browser-provided files, generated content, or remote sandbox attachment paths that the MCP process cannot read. | |
| idempotencyKey | No | Optional idempotency key for durable upload retries. | |
| waitForIndexing | No | If true, wait until indexing reaches a terminal ready state before returning. | |
| createMissingBuckets | No | If true, create missing bucket slugs before assignment. |
TDQS
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 durable bucket-backed nature, the indexing pipeline, return metadata, the requirement to choose exactly one file source, and explains how filePath avoids base64 conversion. It also mentions idempotency for retries. Some aspects like error conditions or permission needs are not covered, but the description adds significant behavioral context beyond the schema.
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 front-loaded with the core purpose and then efficiently covers usage guidance, parameter selection, and constraints in a compact block. Every sentence adds value; no filler or repetition.
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?
Despite 13 parameters and no output schema, the description is complete: it states what the tool returns, when to use each source parameter, bucket requirements, and optional behaviors like waitForIndexing and createMissingBuckets. It addresses the complexity effectively.
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 baseline is 3, but the description adds substantial meaning: it explains the trade-offs between filePath and contentBase64, clarifies the bucket alternatives (bucketIds, bucketSlugs, bucket), and notes the idempotency key's purpose. 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?
The description clearly states 'Uploads a file into the durable bucket-backed knowledge store and indexing pipeline', which is a specific verb+resource action. It also distinguishes from siblings by noting this is for the broader knowledge corpus rather than a single RAG chat turn, and indirectly from the batch upload tool.
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?
Explicit guidance is provided: 'Use this when you want a file indexed into the broader knowledge corpus instead of attached directly to a single RAG chat turn.' It also details when to use filePath vs contentBase64 with concrete examples (local vs hosted/remote), and implies batch tool for multiple files. No alternatives are excluded but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
calypso-upload-knowledge-files-batchA
[CALYPSO UPLOAD KNOWLEDGE FILES BATCH] Uploads 1 to 100 files into the durable knowledge store and indexing queue in one request.
Use this for bulk corpus ingestion. Shared bucket fields apply to every item unless an item
provides its own bucket fields. The tool returns batch-level status and, when requested,
polls until the batch reaches active, partially_active, partially_failed, failed, or timeout.
A shared bucket destination is required unless every item provides its own bucket destination.
Choose exactly one file source per item. Use filePath when this MCP server runs locally and can read each path, including Claude Desktop or Cursor configs that launch this package with npx. Use contentBase64 for hosted or remote MCP clients, browser uploads, generated in-memory content, or remote sandbox files that this MCP process cannot read. Do not base64-encode local files just to use this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | Knowledge files to upload in this batch. | |
| bucket | No | Convenience single bucket slug applied to all items by default. Required unless every item has a bucket destination. | |
| bucketIds | No | Existing bucket ids applied to all items by default. Required unless every item has a bucket destination. | |
| bucketSlugs | No | Bucket slugs applied to all items by default. Required unless every item has a bucket destination. | |
| waitForBatchReady | No | If true, poll batch status with include_items=true until terminal or timeout. | |
| batchIdempotencyKey | Yes | Required idempotency key used to derive the durable batch id. | |
| createMissingBuckets | No | If true, create missing shared bucket slugs before assignment. |
TDQS
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 discloses write side-effects (durable store, indexing queue), batch status return, optional polling with terminal states, and bucket field override rules. It does not mention all possible failure semantics or idempotency behavior in depth, but the core workflow is transparent.
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 longer than minimal but every sentence serves a purpose: purpose, usage, file-source selection, bucket rules, and status behavior. It is well-structured and front-loaded with the main action, then details, with no filler.
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 or annotations, the description is remarkably complete: it covers the tool's operation, return behavior, polling, and preconditions (bucket destination). It could add more on error handling or what 'batch-level status' contains, but it covers the essentials for a batch upload tool.
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 baseline is 3. The description adds important contextual meaning: when to use filePath vs contentBase64, and that shared bucket fields are overridden by item-specific fields. This enriches parameter understanding beyond 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 uploads 1 to 100 files into the durable knowledge store and indexing queue in one request, with the explicit use case of bulk corpus ingestion. This distinguishes it from the sibling single-file upload tool by scope and batch behavior.
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 gives explicit usage guidance: use for bulk corpus ingestion. It also provides specific direction on choosing filePath for local MCP installs and contentBase64 for hosted/remote clients, plus a warning not to base64 local files. However, it does not explicitly reference the singular alternative tool (calypso-upload-knowledge-file), so it lacks full alternative guidance.
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.
4 tool updates
v1.0.40- First observed
calypso-list-knowledge-buckets - First observed
calypso-rag-agent - First observed
calypso-upload-knowledge-file - First observed
calypso-upload-knowledge-files-batch
TDQS
Scored across 4 tools
Each tool has a clearly distinct purpose: listing buckets, uploading a single file, uploading a batch of files, and querying the RAG agent. The two upload tools are well-separated by single vs. batch semantics, and the descriptions reinforce the boundaries.
Most tools follow a consistent `calypso-<verb>-<object>` pattern (list-knowledge-buckets, upload-knowledge-file, upload-knowledge-files-batch). The `calypso-rag-agent` tool deviates as it names a service rather than an action, but the prefix and hyphenation maintain a readable, predictable style.
Four tools is well-scoped for a focused multimodal RAG server. Each tool addresses a core need (bucket discovery, ingestion, bulk ingestion, and retrieval/chat), and none feel redundant or unnecessary.
The core workflow is covered: list buckets to find destinations, upload files (single or batch), and query via the RAG agent. Minor gaps exist (no explicit file deletion/update or bucket creation), but they are likely outside the intended scope and do not block the primary use case.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
Hosted MCP server: convert PDFs to clean, LLM-ready Markdown with tables, formulas and OCR.
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
The CustomGPT.ai MCP server is a fully managed, RAG-powered endpoint that connects large language models with private knowledge bases and external data sources. It provides tools for retrieval-augmented generation queries (send_message), data ingestion (upload_file), and source listing, enabling AI agents to query private documents like PDFs with high accuracy and real-time citations.
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Related MCP Servers
- AlicenseNot gradedqualityFmaintenanceAn MCP server that provides comprehensive multimodal Retrieval-Augmented Generation (RAG) capabilities for processing and querying document directories, supporting text, images, tables, and equations.35MIT
- AlicenseNot gradedqualityDmaintenanceA Model Context Protocol server that enables any MCP-compatible application to perform advanced multi-modal document processing and retrieval using RAG-Anything.MIT
- AlicenseNot gradedqualityCmaintenanceRAGX MCP Server enables retrieval-augmented generation with document ingestion, hybrid search, and agentic answering using Claude, exposing tools for querying, searching, and managing documents.2MIT
- FlicenseNot gradedqualityCmaintenanceAn MCP server for document parsing, ingestion, query (including multimodal), and lightweight knowledge graph inspection, enabling RAG workflows via the Model Context Protocol.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/calypso-so/calypso-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server