What can you do with this server?

The @dropdat/mcp server allows AI clients to interact with a user's dropdat capsule library — a personal knowledge store for saving and retrieving AI conversations — through the following tools: * Semantic Search (dropdat_recall): Perform hybrid vector + BM25 search across capsule titles, summaries, and message bodies to find relevant past conversations or decisions, with optional tag filtering and result limits. * Read Capsule (dropdat_read): Fetch the full message contents of a specific capsule by its ID, with an optional flag to include its lineage. * Browse Recent Capsules (dropdat_list): List recently saved capsules, optionally filtered by tag, for browsing rather than targeted searching. * Save a Conversation Slice (dropdat_capsule): Save a meaningful portion of the current conversation as a new capsule, with a title, messages, summary, tags, and source metadata. * Autosave Full Session (dropdat_autocapsule): Save an entire Claude Code session verbatim by reading the on-disk .jsonl transcript directly, requiring only a title and optional metadata.

How do I use @dropdat/mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@dropdat/mcp recall capsules about natural language processing" 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.

@dropdat/mcp

Official

by dropdat

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

@dropdat/mcp

MCP server for dropdat. Lets any MCP-capable AI client (Claude Code, Cursor, Cline, Claude Desktop) recall, read, and save capsules in the user's dropdat library.

Tools

Tool	Purpose
`dropdat_recall`	Keyword-search capsules (titles, summaries, message bodies).
`dropdat_read`	Fetch one capsule's full contents by id (optional lineage).
`dropdat_list`	Browse recent capsules, optional tag filter.
`dropdat_capsule`	Save the current conversation slice as a new capsule (model picks the messages).
`dropdat_autocapsule`	Save the full verbatim Claude Code session by reading the on-disk `.jsonl` transcript.

dropdat_recall calls the hybrid /capsules/search endpoint (vector + BM25 fused via RRF). Set OPENAI_API_KEY on the API for full semantic recall; without it the endpoint degrades to BM25.

Related MCP server: NeuronSearchLab

Install

# from npm (recommended — clients can also `npx -y @dropdat/mcp`)
npm install -g @dropdat/mcp

# or from source
git clone https://github.com/dropdat/mcp.git
cd mcp && npm install && npm run build

Configure

Issue an API key in the dashboard → API Keys (token shown once, shape dk_live_…). Export it:

export DROPDAT_API_KEY=dk_live_xxx
# Optional — defaults to https://dropdat.app, the hosted API.
# Set this only if you're running the API locally or self-hosted.
# export DROPDAT_API_BASE=http://localhost:8080

If you're self-hosting the API and have DEV_AUTH_BYPASS=1 enabled, the API ignores tokens entirely and assumes DEV_USER_ID. Use a real key against any normal deployment.

Wire into a client

Claude Code

Add to ~/.claude/mcp.json (or project .mcp.json):

{
  "mcpServers": {
    "dropdat": {
      "command": "npx",
      "args": ["-y", "@dropdat/mcp"],
      "env": {
        "DROPDAT_API_KEY": "dk_live_xxx"
      }
    }
  }
}

Cursor / Cline / Claude Desktop

Same shape — npx -y @dropdat/mcp as the command, DROPDAT_API_KEY in env. Transport is stdio.

Develop

npm run dev   # tsx, no rebuild
npm run build # emit dist/

The compiled dist/index.js starts with a #!/usr/bin/env node shebang and is chmod +x'd on build — once published, clients can npx -y @dropdat/mcp instead of pinning a path.

Endpoint surface used

All against the Go API under /api/v1:

GET /capsules?q=&tag=&limit=
POST /capsules/search
GET /capsules/{id}
GET /capsules/{id}/lineage
POST /capsules

Bearer auth — accepts either a Clerk session JWT or a dk_* API key. The MCP server uses the API-key path so it survives long-running agent sessions without a refresh dance.

Available Tools

5 tools

dropdat_autocapsuleA

Save the FULL verbatim Claude Code session as a capsule by reading its on-disk .jsonl transcript directly. Use this instead of dropdat_capsule when the user wants the entire conversation, not just a model-reconstructed slice. The server reads the file itself — no need to pass messages.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Short human title for the capsule.
`summary`	No
`tags`	No
`transcriptPath`	No
`cwd`	No
`sourceUrl`	No

TDQS

A4.2/5.0

Behavior4/5

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

The description discloses that the tool reads a .jsonl transcript file directly and saves a capsule. It does not explicitly mention side effects or idempotency, but the read-and-save behavior is reasonably transparent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences deliver purpose, usage guidance, and a key behavioral point. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the high-level purpose and usage guidance are clear, the description lacks detail on parameters, return value, and error handling. Given the tool has 6 parameters and no output schema or annotations, more context would be beneficial.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 17% and the description does not explain any of the 6 parameters. It only mentions that no messages need to be passed, leaving the agent uninformed about parameters like transcriptPath, summary, tags, etc.

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 saves the full verbatim Claude Code session by reading an on-disk transcript. It distinguishes itself from dropdat_capsule by specifying it captures the entire conversation rather than a model-reconstructed slice.

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

Usage Guidelines5/5

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

Explicitly tells the agent to use this tool instead of dropdat_capsule when the full conversation is needed. It also notes that no messages need to be passed, implying a different workflow from sibling tools.

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

dropdat_capsuleB

Save the current conversation (or a relevant slice of it) as a new capsule. Call when the user says 'remember this', 'save this conversation', or at the end of a meaningful session.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Short human title for the capsule.
`summary`	No
`source`	No
`sourceUrl`	No
`tags`	No
`messages`	Yes

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It states 'save' but does not disclose critical behaviors like whether it overwrites, requires permissions, or returns confirmation. The behavioral context is limited to the trigger phrases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, directly to the point, with no filler. It front-loads the action and then gives usage triggers.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no annotations and no output schema, the description lacks detail on what the tool actually does internally, what it returns, and how parameters work. It is insufficient for a tool with 6 parameters and no other documentation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 17% schema description coverage (only title described), the description must compensate but adds no explanation for summary, source, sourceUrl, tags, or messages. It provides no parameter-level guidance beyond the schema.

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

Purpose5/5

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

The description clearly states the tool saves a conversation as a new capsule, using specific verb and resource. It also distinguishes from siblings like list/read/recall by focusing on saving, though it doesn't explicitly differentiate from autocapsule.

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 provides explicit triggers ('remember this', 'save this conversation', end of session) for when to call the tool. It lacks guidance on when not to use, but the use case is well-scoped.

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

dropdat_listB

List recent capsules, optionally filtered by tag. Use to browse, not to search.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No
`limit`	No

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided, so description carries full burden. Mentions listing recent capsules with optional tag filter, but omits critical details: ordering, pagination, scope of 'recent', authentication needs, side effects, or performance implications.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with core purpose, no filler. Every word adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, description fails to cover essential context: return format, default behavior (e.g., default limit), error handling, or how this tool relates to sibling tools like dropdat_recall for search.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, description partially compensates by explaining 'tag' as a filter. However, 'limit' parameter is entirely unexplained despite being a common pagination parameter.

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

Purpose4/5

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

Description uses specific verb 'list' and resource 'capsules', adds qualifier 'recent' and filtering by tag. Distinguishes from search via 'use to browse, not to search', but does not explicitly differentiate from siblings like dropdat_capsule or dropdat_recall.

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

Usage Guidelines3/5

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

Provides clear usage direction: 'Use to browse, not to search.' Implies it is for casual listing rather than precise retrieval, but no explicit alternatives or when-not-to-use conditions are given.

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

dropdat_readA

Fetch one capsule's full contents (all messages) by id. Pair with dropdat_recall to drill into a hit.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Capsule id (uuid v7).
`includeLineage`	No

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so description must disclose behavior. It states it fetches full contents (read-only implied) but lacks details on idempotency, side effects, or permissions. Adequate but not comprehensive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no waste. The primary purpose is front-loaded, and the pairing advice is additional without redundancy.

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, description sufficiently conveys what the tool returns ('full contents'). However, given sibling tools exist, more context on when to use read vs capsule could improve completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Description does not mention any parameters. Schema covers 50% (id description only). The includeLineage parameter is left without description. Description fails to add meaning beyond schema.

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

Purpose5/5

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

Description clearly states the tool fetches full contents of one capsule by ID. The mention of pairing with dropdat_recall distinguishes its role from siblings like dropdat_recall (for drilling) and dropdat_list (presumably listing).

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?

Description provides guidance on pairing with dropdat_recall for deeper investigation, but does not explicitly state when not to use this tool or alternatives. Still useful for context.

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

dropdat_recallA

Hybrid (vector + keyword) semantic search across the user's dropdat capsule library. Use this whenever the user asks about prior decisions, past sessions, or anything they may have discussed with another AI — even if their phrasing doesn't match exact words from earlier conversations. Returns ranked hits with id, title, summary, tags, and a fused score.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Keyword search across capsule titles, summaries, and message bodies.
`tag`	No
`limit`	No

TDQS

A4.2/5.0

Behavior4/5

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

Discloses that it performs hybrid (vector+keyword) semantic search and returns ranked results with specific fields. Without annotations, this is valuable behavioral context, though it could explicitly state it's read-only and mention any authorization 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two well-structured sentences with no fluff. The first sentence states the core function, the second provides usage context, and the return fields are clearly listed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers return fields and general scope, but does not describe how parameters interact (e.g., tag filtering) or pagination behavior. For a search tool with no output schema, the description is adequate but has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Only the 'query' parameter is implicitly described via usage guidance. The 'tag' and 'limit' parameters lack descriptions in both schema and description, leaving the agent guessing their semantics despite 33% coverage.

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

Purpose5/5

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

The description clearly states it performs hybrid semantic search across the user's capsule library, specifying the verb+resource and return fields. It implicitly distinguishes from sibling tools like dropdat_list (listing) and dropdat_read (reading a specific capsule) by focusing on search.

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

Usage Guidelines5/5

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

Provides explicit guidance on when to use: 'whenever the user asks about prior decisions, past sessions, or anything they may have discussed with another AI — even if their phrasing doesn't match exact words.' This is highly actionable for an AI agent.

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.

5 tool updatesv0.1.0May 16, 2026
- First observeddropdat_autocapsule
- First observeddropdat_capsule
- First observeddropdat_list
- First observeddropdat_read
- First observeddropdat_recall

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-05-16 14:10 across 5 tools

Disambiguation5/5

Each tool has a clear and distinct purpose: autocapsule saves full sessions, capsule saves current slice, list browses, read fetches by ID, and recall searches. No overlap or ambiguity.

Naming Consistency4/5

All tools use the 'dropdat_' prefix followed by a verb (autocapsule, capsule, list, read, recall). 'autocapsule' is a compound but still readable; overall pattern is consistent.

Tool Count5/5

5 tools is well-scoped for a capsule management server. Each tool covers an essential operation without unnecessary redundancy.

Completeness4/5

Core CRUD-like operations are present: create (capsule, autocapsule), read (list, read), and search (recall). Missing delete or update may cause minor gaps, but the primary workflow is covered.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

KeepFlash Agent Access
io.github.dante-is-shipping
Search, read, cite, create, and safely update a user's private KeepFlash knowledge library.
Note Taking Knowledge & Memory Search
1
Tolstoy LibraryOAuth
io.github.GoTolstoy
Browse, search, rename, and favorite your Tolstoy media library from any AI client.
Entertainment & Media Search
2
Dewey
com.meetdewey
Agentic search over your Dewey document collections from any MCP-compatible client.
Search Knowledge & Memory RAG Systems
2
ragie
com.mcparmory
Ingest, manage, and retrieve documents for RAG-powered AI applications
RAG Systems Databases Knowledge & Memory
2

Related MCP Servers

Rememberizer MCP Server for
Knowledge & Memory Search RAG Systems
skydeckai
A
license
Not graded
quality
D
maintenance
Enables accessing and managing personal/team internal knowledge repository with tools for semantic search, smart search, document listing, and saving information for future recall.
Updated 5 months ago (2026-04-20 07:17 UTC)
Apache 2.0
NeuronSearchLabofficial
AI & Machine Learning E-commerce & Retail
NeuronSearchLab
A
license
Not graded
quality
B
maintenance
Enables MCP-compatible AI clients to access the NeuronSearchLab recommendation engine for fetching personalized recommendations, tracking user interactions, and managing catalogue items through natural language.
Updated 19 days ago (2026-09-02 20:57 UTC)
96 npm
MIT
Compoid MCP Serverofficial
Content Management Systems Search Research & Data
compoid
A
license
Not graded
quality
F
maintenance
Enables AI agents to search, download, create, and manage records and communities on Compoid repositories using natural language.
Updated 5 months ago (2026-05-05 12:31 UTC)
MIT
cortexify-mcpofficial
Knowledge & Memory Note Taking Search
Illumintrix
F
license
Not graded
quality
B
maintenance
Enables any MCP client to read and write a Cortexify library, including saved links, documents, notes, collections, and the Cortex AI copilot.
Updated 18 days ago (2026-09-04 13:17 UTC)
-

@dropdat/mcp

Tools

Install

Configure

Wire into a client

Claude Code

Cursor / Cline / Claude Desktop

Develop

Endpoint surface used

Available Tools

TDQS

TDQS

TDQS

TDQS

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Rememberizer MCP Server for

NeuronSearchLabofficial

Compoid MCP Serverofficial

cortexify-mcpofficial