This server is an MCP server for Hydra DB that provides agentic memory management with knowledge-graph enriched context. It allows you to:
Query memories (hydradb_query): Search stored memories using semantic search (fast mode) or deeper graph-traversal-based recall (thinking mode), with optional knowledge graph context including entity paths and relations.
Ingest information (hydradb_ingest): Store notes, documents, or conversation histories; supports plain text and markdown. Hydra DB automatically extracts insights, preferences, and builds a knowledge graph.
List contents (hydradb_list): Browse memories or knowledge sources, optionally filtered by source IDs.
Inspect sources (hydradb_inspect): Fetch full original content of a source by ID, returning text, a presigned URL, or both.
Delete (hydradb_delete): Permanently remove a memory or knowledge source by ID.
All tools have deprecated aliases (e.g., hydra_db_search, hydra_db_store) for backward compatibility. Configuration requires an API key and database name, with optional environment variables for custom collection and base URL.
Click on "Deploy 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., "@Hydra DB MCP Server search my memories for key learnings"
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.
MCP (Model Context Protocol) server for Hydra DB, the state-of-the-art agentic memory. Provides tools for storing, recalling, and managing memories with knowledge-graph enriched context.
Run it two ways, same tools either way:
Local (stdio) — the npx @hydradb/mcp binary each client spawns. No server to operate; credentials live in the client's config. This is the default and everything below the Configuration section documents it.
Remote (HTTP) — one hosted process behind a URL like https://mcp.hydradb.com that many clients point at, with nothing to install. See Remote / hosted server.
Tool | What it does |
| Search memories and knowledge together, with knowledge-graph context |
| Save a note, a document, or a conversation |
| Enumerate one family — every memory, or every knowledge source |
| Fetch one source's full content by id |
| Remove one or more items by id, irreversibly |
| Check whether an ingested source has finished indexing |
| Everything connected to one item — its thread, replies, parents, children, links |
| Report whether a query's results were useful, by its |
Ids flow between these: hydradb_query, hydradb_list and hydradb_subgraph emit them;
hydradb_inspect, hydradb_delete, hydradb_status and hydradb_subgraph accept them.
Hydra DB also runs property graphs you model and own end to end, queried in Cypher. This is a different product surface from the memory and knowledge above, and nothing crosses between them: hydradb_query cannot see graph data, and hydradb_graph_query cannot see memories.
Tool | What it does |
| Run Cypher — reads and writes |
| List the graphs in a graph database |
| Create a graph database; drop a collection or a database |
hydradb_graph_query is annotated destructiveHint, because it runs arbitrary Cypher and DELETE is as reachable through it as MATCH. There is deliberately no separate read-only Cypher tool and no read-only mode: both would mean classifying Cypher text client-side to decide what to refuse, which is a heuristic — a promise the server can keep and a client cannot. This server does not inspect your query at all; it sends it and reports what HydraDB says. To lock the graph surface down, withhold the tools (below) — that is a real guarantee.
// Everyone Alice knows within four hops
{"query": "MATCH (a:Person {name:$n})-[:KNOWS*1..4]->(r) RETURN DISTINCT r.name AS name",
"params": {"n": "Alice"}}
// Bulk load, re-runnable after a failure
{"query": "UNWIND $rows AS row MERGE (p:Person {ext_id: row.ext_id}) SET p += row",
"params": {"rows": [{"ext_id": "a", "name": "Alice"}]}}Differences from Neo4j worth knowing before you write Cypher. Each is rejected before execution, so a rejected query changes nothing and fails identically on retry:
Procedure calls (CALL db.*, CALL apoc.*) are rejected by the server, before it executes anything. CALL { ... } subqueries are fine. There is no schema tool and no apoc.meta.schema(); to learn a collection's structure, query it — MATCH (n) UNWIND labels(n) AS l RETURN l, count(*) AS c ORDER BY l.
LOAD CSV is rejected — pass data through params instead.
Existence checks are bare pattern predicates (WHERE (p)-[:KNOWS]->()); EXISTS { ... } and exists() are not accepted.
shortestPath belongs in RETURN/WITH, not MATCH p = ..., and must be directed.
EXPLAIN/PROFILE execute the query rather than planning it — do not use them to preview one.
Collections auto-create on first write, so there is no create-collection call. Requests are capped at 256 KiB (enforced locally, before upload) and large result sets are truncated server-side — paginate with ORDER BY ... SKIP $offset LIMIT $limit.
To turn the graph tools off entirely:
HYDRADB_MCP_GRAPH_TOOLS=0 # withhold all threeThe previous hydra_db_* tool names are no longer registered by default as
of 1.2.0. If your mcp.json still calls them, set:
HYDRADB_MCP_LEGACY_TOOLS=1Deprecated alias | Use instead |
|
|
|
|
|
|
|
|
|
|
Searches both memories and ingested knowledge sources. Returns matching chunks with their source id, a relevance score, and knowledge-graph context.
Parameter | Type | Required | Description |
| string | Yes | What you want to know, as a question or topic |
| string | No |
|
| number | No | Maximum chunks to return (1-50, default: 10) |
| string | No |
|
| string | No |
|
| boolean | No | Include knowledge-graph relations (default: true) |
| string | No |
|
| array | No | Restrict the search to these sources |
| array | No | Restrict to exact document titles (case-insensitive); resolved to source IDs before normal search |
| object | No | Exact-match filters over stored metadata |
| number | No | Adjacent chunks to attach per match (0-5, default: 0) |
| number | No | Favour recently-updated sources when ranking, 0-1 (default: 0). Re-ranks only; it never excludes older sources |
| boolean | No | App-aware retrieval over connector sources — exact IDs and actors, thread reconstruction, parent/child expansion (default: false) |
| array | No | Search several collections at once. Pass either this or |
Saves information so it outlives the session. Provide exactly one of text
or turns.
Parameter | Type | Required | Description |
| string | No* | A note, fact, decision, or document body |
| array | No* | Conversation turns, each with |
| string | No |
|
| string | No | Label shown in later search results — always set it |
| string | No | Identifier for this entry. Reusing one REPLACES what is stored under it |
| boolean | No | Allow that replacement (default: true) |
| boolean | No | Extract insights and graph entities (default: true) |
| boolean | No | Chunk on markdown structure (default: false) |
| object | No | Key/value metadata, matchable later via |
| string | No | When the fact was true, as |
| string | No | What to call the user, used with |
* Passing both is an error; passing neither is an error.
Ingestion is asynchronous — content is not searchable the instant it is
saved. Use hydradb_status to confirm.
Enumerates one family at a time. These are separate corpora: listing memories tells you nothing about which knowledge sources exist.
Parameter | Type | Required | Description |
| string | Yes |
|
| array | No | Restrict to these ids |
| array | No | Deprecated alias for |
| number | No | Page to return, 1-indexed (default: 1) |
| number | No | Items per page (1-100) |
The response reports how many of the total it showed and how to reach the rest.
Fetches one source's full content by id.
Parameter | Type | Required | Description |
| string | Yes | The source id, from |
| string | No | Deprecated alias for |
| string | No |
|
| number | No | Character offset to read from (default: 0) |
| number | No | Maximum characters to return (max 20000) |
| number | No | How long a |
Long sources come back in slices, and binary sources are never inlined — you get
their type and size, and mode: "url" returns a download link.
Records whether a query's results were actually useful. Correlated to that query
by its request_id, which hydradb_query prints at the end of its output — copy
it verbatim, it cannot be guessed or reconstructed.
Parameter | Type | Required | Description |
| string | Yes | The id |
| string | No | What was wrong, missing or good, in plain words (max 8000) |
| string | No |
|
| string | No | The answer a correct system would have given |
| string[] | No | Sources that actually contain the answer (max 100) |
| object | No | Your own string labels, e.g. an eval run name (max 20) |
| string | No | Scope overrides |
Send text, ground truth, or both — a submission with neither records nothing and
is refused. Ground truth is worth far more than prose because it is
machine-checkable: source_ids turns one submission into a retrieval judgement
(did the query surface these, at what rank, at all?), which is recall measured on
real traffic rather than on a benchmark that stops resembling production the day
it is written.
Feedback never changes the result of the query it describes and never alters
stored data. Rows are labelled source: agent, because everything reaching this
server came from a model — agent feedback is a different population from human
feedback and is separated at write time.
Returns the connected subgraph of one item: every item reachable from it through item-level links — explicit relations declared at ingest, a shared thread, parent/child hierarchy — traversed breadth-first. Use it when one result is not enough and you need what surrounds it: the rest of a Slack thread, the replies under a ticket, the documents a page links to.
Parameter | Type | Required | Description |
| string | Yes | The item to start from, from |
| string | No |
|
| number | No | Hops to traverse (default 5, max 10) |
| number | No | Cap on members returned (default 200, max 1000) |
| string | No | Scope overrides |
Each member carries its id, title, depth from the start item and how it was
reached — discovered_relation is the mechanism (same_thread, parent,
child, or a relates_to type such as reply_to) and discovered_via the id
of the member it was reached from, so the list is also a tree.
structuredContent carries those same members, in the same order, plus
relations: the edges among them as {from, to, type}, so a client can rebuild
the graph and not just the list. truncated means max_sources clipped the
traversal; structural_link_count and structural_truncated report the
structural graph (entities, comments, attachments, actors) around the members.
Chunk-level entity relations are not included; those come from hydradb_query.
Removes items by id. Irreversible.
Parameter | Type | Required | Description |
| array | No* | The ids to delete — accepts several at once |
| string | No* | A single id |
| string | No |
|
* Provide one of them.
Checks whether ingested sources have finished indexing.
Parameter | Type | Required | Description |
| array | Yes | The source ids to check |
Related MCP server: MCP-Mem0
Get your Hydra DB API Key from Hydra DB
Get your database name from the Hydra DB dashboard
Variable | Description | Default |
| Your Hydra DB API key | Required |
| Your Hydra DB database (tenant scope) | Required |
| Collection (sub-tenant) for partitioning | none — unset means the workspace's own collection; the model can also name one per call via |
| Base URL override |
|
| Log level: DEBUG, INFO, WARN, ERROR |
|
| Per-attempt request timeout |
|
| Retries per request (0 disables) |
|
| Register the deprecated | off |
| Default graph database for the Cypher tools |
|
| Default graph collection |
|
| Register the graph tools ( | on |
A graph database is a different namespace from the memory database: the same
name can exist as both, and Cypher aimed at the wrong one reads an empty graph
rather than failing. Every graph tool also takes database and collection
per call, overriding these defaults.
The legacy HYDRA_DB_* names — HYDRA_DB_API_KEY, HYDRA_DB_TENANT_ID,
HYDRA_DB_SUB_TENANT_ID, HYDRA_DB_BASE_URL, HYDRA_DB_LOG_LEVEL — remain
honoured as deprecated aliases (canonical wins when both are set; using an
alias prints a one-time warning naming its replacement).
{
"mcpServers": {
"hydradb": {
"command": "npx",
"args": ["-y", "@hydradb/mcp@latest"],
"env": {
"HYDRADB_API_KEY": "your-api-key",
"HYDRADB_DATABASE": "your-database"
}
}
}
}Client | Config File |
Cursor |
|
Windsurf |
|
{
"mcpServers": {
"hydradb": {
"command": "npx",
"args": ["-y", "@hydradb/mcp@latest"],
"env": {
"HYDRADB_API_KEY": "your-api-key",
"HYDRADB_DATABASE": "your-database"
}
}
}
}Add to .vscode/mcp.json:
{
"servers": {
"hydradb": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@hydradb/mcp@latest"],
"env": {
"HYDRADB_API_KEY": "your-api-key",
"HYDRADB_DATABASE": "your-database"
}
}
}
}To partition data, set the HYDRADB_COLLECTION environment variable:
{
"mcpServers": {
"hydradb": {
"command": "npx",
"args": ["-y", "@hydradb/mcp@latest"],
"env": {
"HYDRADB_API_KEY": "your-api-key",
"HYDRADB_DATABASE": "your-database",
"HYDRADB_COLLECTION": "my-project"
}
}
}
}Everything above spawns the server locally over stdio. The same server also runs
as a long-lived HTTP endpoint that many clients reach at one URL — nothing to
install or update per user. This is what powers a hosted deployment like
https://mcp.hydradb.com, and what you run yourself with npm run start:http
or the Docker image.
The tool surface is identical; only how a client connects and authenticates changes.
MCP clients that support a remote (streamable-http) server take a URL and
headers instead of a command:
{
"mcpServers": {
"hydradb": {
"url": "https://mcp.hydradb.com",
"headers": {
"Authorization": "Bearer YOUR_HYDRADB_API_KEY",
"X-HydraDB-Database": "your-database"
}
}
}
}Every request carries its own credentials, so one hosted process serves any number of independent users. The headers a request may send:
Header | Maps to | Required |
| Hydra DB API key ( | Yes* |
| Default database (tenant scope) | Yes* |
| Default collection (sub-tenant); unset means the workspace's own collection | No |
| Default graph database for the Cypher tools; defaults to the request's database | No |
| Default graph collection; defaults to | No |
* Unless the server was started with HYDRADB_API_KEY / HYDRADB_DATABASE in
its environment (single-tenant self-host, below), in which case a request may
omit them and fall back to the server's own credentials. A request that supplies
neither a header nor a server-side default is refused: 401 with no key, 400
with a key but no database.
Every tool additionally accepts optional database and collection parameters
directly in its arguments (e.g. hydradb_query with {"query": "...", "database": "tenant_b"}),
allowing multi-tenant agents to switch tenant scope per tool call while falling
back to the session defaults when omitted.
Base URL, request timeout and retry count are
operator settings read from the server's environment and are never taken
from a request header.
Node:
npm ci && npm run build
# Single-tenant: the server holds one account; clients send no credentials.
HYDRADB_API_KEY=your-key HYDRADB_DATABASE=your-database npm run start:http
# Multi-tenant: no account in the env; every client sends its own headers.
BIND_ADDRESS=0.0.0.0 ALLOWED_HOSTS=mcp.hydradb.com npm run start:httpDocker:
docker build -t hydradb-mcp .
# Single-tenant
docker run -p 8080:8080 -e HYDRADB_API_KEY=your-key -e HYDRADB_DATABASE=your-database hydradb-mcp
# Multi-tenant (clients authenticate per request)
docker run -p 8080:8080 -e ALLOWED_HOSTS=mcp.hydradb.com hydradb-mcpThe primary MCP endpoint is / (with /mcp supported as an alias); GET /health is an unauthenticated liveness probe.
The image binds 0.0.0.0 inside the container (the host controls exposure with
-p) and runs as an unprivileged user.
With three extra variables the hosted server also speaks the MCP authorization flow: a client that arrives with no credentials gets a 401 pointing at /.well-known/oauth-protected-resource, discovers the HydraDB dashboard as its authorization server, opens the browser, and the user signs in and picks a database. No key is ever pasted into a client.
Variable | Description |
| The authorization server, e.g. |
| This server's public URL as clients see it, e.g. |
| Shared secret the issuer's |
All three are required together. With any of them missing, OAuth stays off and the server behaves exactly as before: no new routes, no new headers. Token introspection answers are memoised for up to 30 seconds, so disconnecting an app from the dashboard takes effect within that window.
OAuth is purely additive. API keys in Authorization / X-HydraDB-Api-Key headers, the X-HydraDB-Database header and the single-tenant environment fallback all keep working unchanged on the same URL.
These configure the HTTP process itself (the stdio server ignores them). All
the HYDRADB_* variables from Environment Variables
also apply — as the single-tenant default and as operator settings.
Variable | Description | Default |
| Port to listen on |
|
| Interface to bind ( |
|
| Extra | (loopback only) |
| CORS origins for browser clients (comma-separated; | (none) |
| Express | off |
The defaults are safe for local use and must be widened deliberately for a public deployment — see SECURITY.md:
Bind loopback by default. BIND_ADDRESS stays 127.0.0.1 until you set
otherwise; 0.0.0.0 exposes the server on every interface and logs a warning.
Host allowlist. Requests whose Host is not loopback or in ALLOWED_HOSTS
get 421 Misdirected Request — a DNS-rebinding defence. Add your public
hostname when binding publicly.
CORS is closed by default. No cross-origin browser request is accepted
until you list its origin in ALLOWED_ORIGINS. Non-browser clients (no
Origin header) are unaffected.
Terminate TLS in front. Run the server behind a reverse proxy / load balancer that handles HTTPS; do not expose plain HTTP to the internet.
The server talks to Hydra DB through the generated @hydradb/sdk
(pinned exactly), behind a thin hand-owned wrapper in src/hydra. The wrapper
owns scope injection, envelope unwrapping and error translation; the tools call
it and render the results.
hydradb_query retrieves relevant memories and returns graph-enriched context (entity paths, chunk relations, extra context). Supports fast and thinking recall modes.
hydradb_ingest stores a note (text) or a conversation (turns) as a memory, with configurable infer, is_markdown, title, and source_id. Hydra DB extracts insights and builds a knowledge graph automatically.
hydradb_list browses stored memories (kind: memory) or ingested knowledge sources (kind: knowledge, with an optional source_ids filter).
hydradb_inspect retrieves the original ingested content of a source, with mode options (content, url, or both).
hydradb_delete removes a memory or knowledge source by ID.
npm ci
npm run build
HYDRADB_API_KEY=your-key HYDRADB_DATABASE=your-database npm startFor development with auto-reload:
HYDRADB_API_KEY=your-key HYDRADB_DATABASE=your-database npm run devTo run the HTTP transport locally (see Remote / hosted server):
HYDRADB_API_KEY=your-key HYDRADB_DATABASE=your-database npm run dev:http
# then: curl localhost:8080/health# unit + conformance tests (wrapper driven against a mocked SDK transport)
npm test
# just the shared conformance vectors
npm run test:conformance
# live integration test against Hydra DB (drives the wrapper end to end)
RUN_LIVE_TESTS=true HYDRADB_API_KEY=your-key HYDRADB_DATABASE=your-database npm run test:integrationAPI Key Issues: Ensure HYDRADB_API_KEY is set correctly
Connection Errors: Check your internet connection and API key validity
Tool Not Found: Make sure the package is installed and the command path is correct
Debug Logging: Set HYDRADB_LOG_LEVEL=DEBUG for verbose output
Get up and running quickly with the bootstrap script:
git clone https://github.com/usecortex/hydradb-mcp.git
cd hydradb-mcp
make bootstrapThis will install dependencies, build the project, and create a .env file from .env.example. Edit .env with your HydraDB credentials, then:
make dev # Start MCP server in dev mode (auto-reload)
make test # Run unit tests
make test-all # Run unit + integration tests
make check-types # Type-check without emittingRun make help to see all available targets.
Delete a memory or knowledge source from Hydra DB by its ID. Use kind to select which family the ID belongs to. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the item to delete | |
| kind | No | Which context family the ID belongs to: 'memory' or 'knowledge' (default: 'memory') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds the irreversible nature of the action, which is a key behavioral trait. However, it lacks details on side effects, error handling, or authorization requirements.
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 sentences are concise and front-loaded with the action. Every sentence adds value: action description and irreversibility hint. 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 no output schema, the description should explain return behavior or confirmation. It only states the action and irreversibility, omitting what happens on success/failure or if the item doesn't exist.
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% via descriptions, and the description adds no additional meaning beyond the schema for parameters 'id' and 'kind'. It does not provide formatting or usage tips beyond what's in the schema.
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 'Delete a memory or knowledge source from Hydra DB by its ID,' with a specific verb and resource. It implicitly distinguishes from sibling 'hydra_db_delete_memory' by mentioning 'kind' to select family, but does not explicitly differentiate.
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 warns 'This action is irreversible' but provides no guidance on when to use this tool versus alternatives (e.g., hydra_db_delete_memory). No context on prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — use hydradb_delete instead. Delete a specific user memory from Hydra DB by its memory ID. This action is irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes | The ID of the memory to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses key behavior: action is irreversible. Could add more about side effects, but sufficient for simple delete.
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 sentences with front-loaded deprecation warning; no wasted words.
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?
Full context for a one-parameter delete tool: deprecation, alternative, irreversibility. No output schema needed.
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 100%, description adds no extra meaning beyond 'by its memory ID' which is already in the schema.
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 deletes a memory by ID, includes deprecation warning and alternative tool name.
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?
Explicitly says DEPRECATED and directs to hydradb_delete instead; also notes irreversibility, guiding cautious use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — use hydradb_inspect instead. Fetch the full content of a specific source by its source ID from Hydra DB. Returns the original text content that was ingested. Use this to retrieve the complete content of a previously stored source.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Fetch mode: 'content' for text, 'url' for presigned URL, 'both' for both (default: 'content') | |
| source_id | Yes | The source ID to fetch content for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds minimal extra behavioral detail beyond the action itself (e.g., no mention of error handling or access requirements), but does not contradict annotations.
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?
Extremely concise: a single sentence plus deprecation notice. No filler or redundant information; every word serves a 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?
For a simple read-only fetch with comprehensive annotations and schema, the description covers the key action and return value ('original text content'). Could mention error scenarios or format, but overall sufficient given simplicity.
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 schema already documents both parameters adequately. Description adds no extra meaning 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?
Clearly states it fetches full content of a source by source ID. Includes deprecation note directing to alternative, which further clarifies purpose and distinguishes from siblings.
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?
Explicitly says 'DEPRECATED — use hydradb_inspect instead' and follows with when to use it ('Use this to retrieve the complete content of a previously stored source'), providing both when-not and when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save important information to Hydra DB State-of-the-art agentic memory. Use this to persist facts, preferences, decisions, notes, or any text the user wants remembered across sessions. Hydra DB automatically extracts insights, preferences, and builds a knowledge graph from the stored content. Supports plain text and markdown. To ingest a conversation instead of a single note, provide turns (user/assistant pairs) rather than text.
| Name | Required | Description | Default |
|---|---|---|---|
| text | No | The information to store in memory | |
| infer | No | Whether Hydra DB should extract insights and build knowledge graph from this text (default: true) | |
| title | No | Optional title for the memory entry (default: 'MCP Memory') | |
| turns | No | Optional conversation turns to ingest instead of `text`; each has a 'user' and 'assistant' field | |
| source_id | No | Optional source identifier to group related memories together. You can use this as your session ID or any other unique identifier for a conversation | |
| user_name | No | Optional name of the user for personalisation (default: 'User') | |
| is_markdown | No | Whether the text is in markdown format (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses automatic insight extraction and knowledge graph building, and supports plain text/markdown. However, it does not address side effects, mutual exclusivity of `text` and `turns`, required permissions, or return behavior, leaving gaps.
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 at five sentences, front-loaded with the core purpose, and logically structured: purpose, usage, features, alternative mode, and format support. Every sentence adds value without 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 7 optional parameters, no output schema, and no annotations, the description covers primary usage and features but lacks details on output format, error handling, and differentiation from close siblings like hydra_db_store. This is adequate for basic use but not comprehensive.
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 all parameters described. The description adds value by clarifying that `turns` is an alternative to `text`, and that Hydra DB auto-extracts insights (context for `infer`). This goes beyond the schema's individual 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's purpose: 'Save important information to Hydra DB' and specifies the types of content (facts, preferences, decisions, notes). It distinguishes from sibling by mentioning the alternative use of `turns` for conversation ingestion, differentiating from hydra_db_ingest_conversation.
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 clear context on when to use the tool (persisting user-remembered information) and offers an alternative approach for conversations via the `turns` parameter. However, it does not explicitly exclude other siblings like hydra_db_store or hydra_db_ingest_conversation, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — use hydradb_ingest instead. Ingest one or more user-assistant conversation turns into Hydra DB memory. Hydra DB will extract insights, preferences, and knowledge graph entities from the conversation. Use this to store conversation history so it can be recalled later. Each turn is a pair of user message and assistant response.
| Name | Required | Description | Default |
|---|---|---|---|
| turns | Yes | Array of conversation turns, each with a 'user' and 'assistant' field | |
| source_id | Yes | Source identifier to group all turns from the same session together | |
| user_name | No | Optional name of the user for personalisation (default: 'User') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It discloses that tool extracts insights/preferences/KG entities. However, does not discuss side effects (e.g., idempotency, performance) typical 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?
Single paragraph, front-loaded with deprecation warning. Efficient and informative, though could be slightly more structured (e.g., bullet points for clarity).
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 low complexity (3 params, no output schema), description covers purpose, deprecation, functionality, and usage. Missing return value info but acceptable for a simple ingestion 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 parameters are well-documented in schema. Description adds context about turn pairs and source grouping, but no significant additional meaning beyond what 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?
Description clearly states the tool ingests conversation turns into Hydra DB memory, with specific verb and resource. Deprecation and explicit alternative (hydradb_ingest) distinguish it from siblings.
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?
Deprecation strongly guides agent to use an alternative. Also describes when to use (store conversation history). However, lacks detailed when-not-to-use beyond deprecation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch the full content of a specific source by its source ID from Hydra DB. Returns the original text content that was ingested. Use this to retrieve the complete content of a previously stored source.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Fetch mode: 'content' for text, 'url' for presigned URL, 'both' for both (default: 'content') | |
| source_id | Yes | The source ID to fetch content for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. The description adds no additional behavioral context beyond stating it returns text content. No contradictions.
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, no wasted words. The purpose is stated upfront and efficiently.
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 fetch tool with annotations, the description adequately conveys purpose and return value. Lacks details on error behavior or output structure, but acceptable given no output schema.
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 extra meaning to the parameters beyond what the schema already 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 clearly states the tool fetches full content by source ID and returns original text. However, it does not distinguish from the similar sibling hydra_db_fetch_content.
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 tells when to use the tool (to retrieve stored source content) but does not mention when not to use it or provide alternatives like hydra_db_fetch_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List stored memories or ingested knowledge sources in Hydra DB. Use kind to choose which family to browse.
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Which context family to list: 'memory' or 'knowledge' (default: 'memory') | |
| source_ids | No | Optional array of specific source IDs to filter by. If omitted, lists all sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint as true, so the agent knows this is a safe, read-only operation. The description adds minimal behavioral context beyond that, but it does not contradict annotations.
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 extremely concise at two sentences, with no wasted words. It is front-loaded with the verb and resource, making it easy to scan.
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 simplicity of the tool (list operation, no output schema, well-defined parameters), the description is fairly complete. It could benefit from mentioning return format or pagination, but annotations cover the safety profile, and schema covers parameters.
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 base level is 3. The description adds marginal value by explaining that 'kind' chooses the family and that 'source_ids' is an optional filter, but these are largely redundant with 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 the verb 'list' and the resources 'memories or ingested knowledge sources', with a scope that is further defined by the 'kind' parameter. It distinguishes itself from sibling tools like hydra_db_list_memories and hydra_db_list_sources by offering a unified browsing experience.
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 a hint about using the 'kind' parameter to choose a family, but it does not explicitly state when to use this tool versus the more specific sibling tools, nor does it provide exclusion criteria or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — use hydradb_list instead. List all stored user memories in Hydra DB. Returns memory IDs and their content. Use this to browse what has been stored, verify memories exist, or find memory IDs for deletion.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint; the description adds that it returns memory IDs and content, which is useful but not extensive. No contradiction, and behavior is well described for a read-only 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?
Two sentences with no wasted words, deprecation front-loaded, and clear purpose articulated efficiently.
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, the description properly mentions return values (IDs and content). It covers the main use cases; could mention pagination or limits, but with 0 params and deprecation, this is adequate.
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?
No parameters exist, and schema coverage is 100%. The description correctly indicates no parameters needed, which is sufficient. Baseline 4 for zero-parameter 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 it lists memories and returns IDs and content, with a deprecation notice directing to an alternative (hydradb_list). This distinguishes it from siblings and specifies the resource and action.
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?
Explicitly states when to use (browse, verify existence, find IDs for deletion) and when not (use hydradb_list instead), providing clear guidance and a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — use hydradb_list instead. List all ingested sources in Hydra DB memory. Returns source IDs, titles, types, and metadata. Use this to see what data sources have been ingested and to find source IDs for fetching content.
| Name | Required | Description | Default |
|---|---|---|---|
| source_ids | No | Optional array of specific source IDs to filter by. If omitted, lists all sources. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint, indicating no side effects. The description adds that it returns source IDs, titles, types, and metadata, but does not disclose additional behavioral traits beyond the annotations. No contradictions.
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 plus a deprecation note, front-loaded with the most important information (deprecation). Every sentence serves a purpose: deprecation warning, action (listing sources), return values, and use case.
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 deprecated status, the description adequately covers what it does, what it returns, and how to find an alternative. No output schema exists, but the description lists return fields. Lacks mention of pagination or limits, but acceptable for a deprecated 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% with a description for the optional `source_ids` parameter. The description only mentions filtering by source IDs, which is already provided in the schema, so no additional meaning is added.
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 lists ingested sources in Hydra DB memory, returns specific fields (IDs, titles, types, metadata), and mentions deprecation. It distinguishes from siblings by directing to `hydradb_list`.
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 explicitly advises using `hydradb_list` instead due to deprecation, and explains when to use this tool: to see ingested sources and find source IDs. It lacks explicit when-not-to-use scenarios but the deprecation serves as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through Hydra DB State-of-the-art agentic memories. Returns relevant chunks with graph-enriched context including entity paths and knowledge graph relations. Use this to find previously stored information, past conversations, user preferences, or any knowledge that has been ingested into Hydra DB memory. Supports both fast semantic search and deeper thinking mode with graph traversal.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Recall mode: 'fast' for quick semantic search, 'thinking' for deeper personalised recall with graph traversal (default: 'thinking') | |
| query | Yes | The search query to find relevant memories | |
| max_results | No | Maximum number of memory chunks to return (1-50, default: 10) | |
| graph_context | No | Whether to include knowledge graph relations in results (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint. Description adds that tool returns chunks with graph-enriched context and supports fast/thinking modes. Beyond annotations, it does not disclose additional behaviors like rate limits or authentication needs.
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?
Description is two sentences, front-loaded with main action, and no wasted words. Could be slightly more structured, but overall efficient and easy to parse.
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 four parameters, no output schema, and existing annotations, description adequately explains return format (chunks with entity paths and knowledge graph relations) and usage scenarios. It compensates for missing output schema by describing enriched 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% and describes all parameters with enums, ranges, defaults. Description adds minimal new meaning beyond restating modes and graph context. Baseline 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?
Description clearly states the tool searches through Hydra DB agentic memories and returns chunks with graph-enriched context. Verb 'Search' and resource 'Hydra DB memories' are specific. No explicit distinction from sibling 'hydra_db_search', but the focus on graph context differentiates it.
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?
Description explicitly states when to use: to find previously stored information, past conversations, user preferences, or ingested knowledge. It provides clear context but does not mention when not to use or compare with alternatives like hydra_db_search or hydradb_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — use hydradb_query instead. Search through Hydra DB State-of-the-art agentic memories. Returns relevant chunks with graph-enriched context including entity paths and knowledge graph relations. Use this to find previously stored information, past conversations, user preferences, or any knowledge that has been ingested into Hydra DB memory. Supports both fast semantic search and deeper thinking mode with graph traversal.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Recall mode: 'fast' for quick semantic search, 'thinking' for deeper personalised recall with graph traversal (default: 'thinking') | |
| query | Yes | The search query to find relevant memories | |
| max_results | No | Maximum number of memory chunks to return (1-50, default: 10) | |
| graph_context | No | Whether to include knowledge graph relations in results (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds valuable behavioral context: returns chunks with graph-enriched context, supports two modes with different graph traversal behavior. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the most critical information (deprecation). Every sentence earns its place: deprecation notice, what it does and returns, and use cases with mode choices. No unnecessary words.
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, the description explains return format (chunks with graph context) and mentions use cases. It covers modes, deprecation, and replacement. Lacks details on pagination or empty results, but the deprecation context makes it sufficiently complete.
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 baseline 3. The description does not add significant new meaning beyond what the schema descriptions already provide for 'mode', 'query', 'max_results', and 'graph_context'. It repeats the mode options but not in more detail.
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 searches Hydra DB memories and returns relevant chunks with graph-enriched context. It explicitly distinguishes from siblings by noting deprecation and pointing to hydradb_query as replacement. The verb 'Search through' and resource 'Hydra DB State-of-the-art agentic memories' are specific.
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 starts with 'DEPRECATED — use `hydradb_query` instead', providing explicit when-not and alternative usage. It also describes the two modes (fast/thinking) and their use cases, giving clear context for when to use each mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEPRECATED — use hydradb_ingest instead. Save important information to Hydra DB State-of-the-art agentic memory. Use this to persist facts, preferences, decisions, notes, or any text the user wants remembered across sessions. Hydra DB automatically extracts insights, preferences, and builds a knowledge graph from the stored content. Supports plain text and markdown.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | The information to store in memory | |
| infer | No | Whether Hydra DB should extract insights and build knowledge graph from this text (default: true) | |
| title | No | Optional title for the memory entry (default: 'MCP Memory') | |
| source_id | No | Optional source identifier to group related memories together. You can use this as your session ID or any other unique identifier for a conversation | |
| is_markdown | No | Whether the text is in markdown format (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that Hydra DB automatically extracts insights and builds a knowledge graph, which is a key behavioral trait. However, it does not mention whether calls are idempotent, how duplicates are handled, or any potential side effects like overwriting existing memories.
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 very concise: two informative sentences plus a deprecation notice. It is front-loaded with the most important guidance (deprecation) and each sentence adds value.
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 deprecated tool, the description covers the essential aspects: purpose, usage, and key features (automatic extraction). It lacks details about return values or limits, but the deprecation reduces the need for completeness. It is sufficient for an agent to understand and avoid the 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 description coverage is 100%, so baseline is 3. The description adds context by mentioning support for plain text and markdown, which is already reflected in the is_markdown parameter description. It does not significantly enhance parameter understanding beyond the schema.
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 purpose: saving important information to Hydra DB memory, and explicitly lists use cases (facts, preferences, etc.). It also distinguishes itself from the sibling tool hydradb_ingest by marking itself as deprecated.
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 opens with 'DEPRECATED — use hydradb_ingest instead,' which is a strong when-not-to-use guideline. It also explains when to use: to persist facts, preferences, decisions, or notes for cross-session memory.
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.
v1.0.0hydra_db_delete_memoryhydra_db_fetch_contenthydra_db_ingest_conversationhydra_db_list_memorieshydra_db_list_sourceshydra_db_searchhydra_db_storehydradb_deletehydradb_ingesthydradb_inspecthydradb_listhydradb_queryScored across 12 tools
The five current tools (hydradb_query, hydradb_ingest, hydradb_list, hydradb_inspect, hydradb_delete) each have a clear, distinct purpose. Deprecated tools are explicitly marked and can be ignored, so an agent can easily select the correct active tool.
There are two naming conventions: current tools use 'hydradb_' prefix with a single verb, while deprecated tools use 'hydra_db_' prefix with varying verb_noun structures. This inconsistency and the presence of both sets create confusion.
With 12 tools, many are deprecated duplicates. The effective set of 5 tools is well-scoped for a memory database server. The count is slightly bloated by deprecated items, but still reasonable.
The tool set covers create (ingest), read (query, list, inspect), and delete, but lacks an update/modify tool. This is a notable gap for full lifecycle management, though the surface is otherwise sufficient.
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent cloud memory for AI agents. Store and search key-value memories across sessions.
