Skip to main content
Glama
calypso-so

Calypso Multimodal RAG MCP Server

Official
by calypso-so

calypso-upload-knowledge-files-batch

Upload 1–100 knowledge files in one request to the Calypso RAG knowledge store for bulk indexing, with batch status polling until ready.

Instructions

[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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
itemsYesKnowledge files to upload in this batch.
bucketNoConvenience single bucket slug applied to all items by default. Required unless every item has a bucket destination.
bucketIdsNoExisting bucket ids applied to all items by default. Required unless every item has a bucket destination.
bucketSlugsNoBucket slugs applied to all items by default. Required unless every item has a bucket destination.
waitForBatchReadyNoIf true, poll batch status with include_items=true until terminal or timeout.
batchIdempotencyKeyYesRequired idempotency key used to derive the durable batch id.
createMissingBucketsNoIf true, create missing shared bucket slugs before assignment.
Behavior4/5

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.

Conciseness4/5

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.

Completeness4/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/calypso-so/calypso-mcp-server'

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