YantrikDB MCP

Overview Schema Source Related Servers Discussions Admin

atlas

Read-onlyIdempotent

Export your store's memory graph as a static local page—including entity links, claims, revision history, and tasks—and serve it on 127.0.0.1. Also check status of running servers.

Instructions

Export this store's Memory Atlas (a static page: every memory, its entity links, claims, revision history and tasks) and serve it on 127.0.0.1. Read-only; nothing leaves the machine.

ACTIONS:

"export": (default) export and serve; returns the local URL, the output directory and the exporter's report. Re-running refreshes the files under the same URL.
"status": the atlas servers this process is running.

Args: out_dir: Output directory (default <store>.atlas/ beside the store). port: Local port (0 = free one). label: Provenance label shown in the page header. open_browser: Also open the URL in the browser.

Embedded mode only (cluster mode: use the yantrikdb atlas CLI on a node). Needs an engine that ships yantrikdb/atlas/.

Input Schema

TableJSON Schema

Name	Required	Default
`port`	No
`label`	No
`action`	No	export
`out_dir`	No
`open_browser`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.24.0Sep 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Description matches annotations (read-only, idempotent) and adds detail: serves locally on 127.0.0.1, nothing leaves the machine, re-running refreshes files, and status action lists servers. This goes beyond annotation hints and provides actionable context.

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?

Well-structured with a clear purpose upfront, followed by actions, args, and mode. No fluff; every sentence adds value. The formatting (headings, bullet points) aids scanning.

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

Completeness5/5

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

Covers the tool's purpose, actions, parameters, output (URL, directory, report), and operational constraints (embedded mode, engine requirement). Output schema exists so return values need not be elaborated. Nothing essential is missing.

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

Parameters5/5

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

Schema coverage is 0%, but the description's 'Args' section explains each parameter (out_dir, port, label, open_browser) with defaults and purpose, and the action parameter is covered in ACTIONS. It fully compensates for the lack of schema descriptions.

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 exports and serves a Memory Atlas, listing its contents (memories, entity links, claims, revision history, tasks). It is distinct from siblings which focus on individual memory operations, so an agent can tell this is for full-atlas export.

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?

Explicitly states embedded mode only and directs cluster mode users to the CLI, which is a clear condition. It does not compare directly to sibling tools, but the purpose is unique enough that the condition suffices.

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

Deploy Server