Skip to main content
Glama
aimdb-dev

aimdb-mcp

Official

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
RUST_LOGNoLog level for the server (e.g., info, debug). Logs go to stderr, keeping stdio clean for the MCP protocol.
AIMDB_CONNECTNoThe endpoint to connect to (e.g., unix:///tmp/aimdb-demo.sock). Resolved after any tool-supplied endpoint and before falling back to auto-discovery. Can also be set via the `--connect` flag.

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
discover_instancesA

Discover all running AimDB instances on the system. Scans /tmp/.sock and /var/run/aimdb/.sock for AimDB servers.

list_recordsB

List all records from a specific AimDB instance. Returns metadata including buffer type, capacity, producer/consumer counts, and timestamps.

get_recordB

Get the current value of a specific record from an AimDB instance. Returns the record's current JSON value.

set_recordB

Set the value of a writable record in an AimDB instance. Only works for records with write permissions.

get_instance_infoB

Get detailed information about a specific AimDB instance. Returns server version, protocol, permissions, and capabilities.

query_schemaA

Get JSON schema and type information for a record.

Returns the data structure, field types, and metadata. Use this before setting record values to understand expected format.

Schema is inferred from current value + database metadata.

πŸ’‘ TIP: Field names like 'celsius', 'timestamp', 'sensor_id' carry semantic meaning. If units or formats are unclear, ask the user for clarification.

drain_recordA

Drain all pending values from a record since the last drain call. Returns values in chronological order. This is a destructive read β€” drained values won't be returned again. Use this for batch analysis of accumulated data (e.g., time-series analysis, trend detection). The first drain call creates a reader and returns empty (cold start). Subsequent calls return all values accumulated since the previous drain.

graph_nodesB

Get all nodes in the dependency graph. Returns metadata for all records as graph nodes, including origin (source/link/transform/passive), buffer configuration, and connection counts. Useful for understanding database topology and data flow.

graph_edgesB

Get all edges in the dependency graph. Returns directed edges representing data flow between records. Shows how data flows from sources through transforms to consumers.

graph_topo_orderA

Get the topological ordering of records in the dependency graph. Returns record keys ordered so all dependencies appear before their dependents. Reflects the spawn/initialization order used by AimDB.

get_architectureA

Return the current architecture state from .aimdb/state.toml as structured JSON, including record count, validation summary, and decision log length. Run this first when entering an architecture session.

propose_add_recordA

Propose adding a new record to the architecture. All payload fields are explicit and typed β€” no guessing required. Present the proposal to the user before calling resolve_proposal.

propose_modify_bufferA

Propose changing the buffer type (and optionally capacity) of an existing record. Present the proposal to the user before calling resolve_proposal.

propose_add_connectorA

Propose adding a connector (MQTT, KNX, etc.) to an existing record. Present the proposal to the user before calling resolve_proposal.

propose_modify_fieldsA

Propose replacing the value struct fields of an existing record. This replaces ALL fields β€” include unchanged fields too. Present the proposal to the user before calling resolve_proposal.

propose_modify_key_variantsA

Propose updating the key variants of an existing record. Use this when adding a record with no variants (e.g. ["Default"]) or expanding a fleet (e.g. adding a new device). Present the proposal to the user before calling resolve_proposal.

propose_add_taskA

Propose adding a new task definition. Tasks are async functions that produce, transform, or consume record data. Present the proposal to the user before calling resolve_proposal.

propose_add_binaryA

Propose adding a new binary definition. Binaries are deployable crates that group tasks together and optionally declare external broker connections. Present the proposal to the user before calling resolve_proposal.

remove_taskA

Propose removal of an existing task. Creates a pending proposal β€” call resolve_proposal to confirm. Note: removing a task affects binaries that reference it.

remove_binaryA

Propose removal of an existing binary. Creates a pending proposal β€” call resolve_proposal to confirm. Task definitions are preserved; only the binary grouping is removed.

resolve_proposalA

Resolve a pending proposal. On confirm: applies the change, writes state.toml, generates Mermaid and Rust artefacts. On reject: discards without changes. On revise: discards with a redirect message.

remove_recordA

Propose removal of an existing record. Creates a pending proposal β€” call resolve_proposal to confirm. Note: removing a record breaks generated type aliases.

rename_recordA

Propose renaming a record. Creates a pending proposal β€” call resolve_proposal to confirm. Note: renames the generated key enum and value struct, breaking existing references.

validate_against_instanceA

Compare state.toml against a live AimDB instance and return a conflict report. Detects missing records, buffer type mismatches, capacity differences, and connector mismatches.

get_buffer_metricsB

Get live buffer metrics for records matching a key string from a running AimDB instance.

get_stage_profilingA

Get automatic stage profiling (per-.source()/.tap()/.link() callback wall-clock timing) for records matching a key from a running AimDB instance, including the slowest stage ('bottleneck'). Requires the instance to be built with the profiling feature.

reset_stage_profilingA

Reset stage profiling counters for every record on a running AimDB instance (requires write permission and the profiling feature).

reset_buffer_metricsA

Reset buffer introspection counters (produced/consumed/dropped/occupancy) for every record on a running AimDB instance (requires write permission and the metrics feature).

save_memoryA

Persist ideation context and design rationale to .aimdb/memory.md. Call this after every confirmed proposal with a narrative summary of what the user is building, the key question asked, the answer received, why the chosen buffer type fits, alternatives that were considered and rejected, and any future considerations noted. On session start, read aimdb://architecture/memory to restore this context.

reset_sessionA

Reset the architecture agent session, discarding any pending proposals. Use when the user wants to start over or abandon the current ideation cycle.

Prompts

Interactive templates invoked by user choice

NameDescription
architecture_agentCore system prompt for the AimDB architecture agent: buffer semantics, ideation loop, proposal format, and confirmation protocol
onboardingGuided first architecture session: walks the user through describing their system and producing their first state.toml
breaking_change_reviewSafety protocol for schema evolution: what to check when a buffer type change or record removal could break the running instance
troubleshootingCommon issues and debugging steps for AimDB MCP server

Resources

Contextual data attached and managed by the client

NameDescription
AimDB InstancesList of all discovered AimDB instances with metadata
Architecture DiagramMermaid flowchart generated from .aimdb/state.toml. Reflects the current proposed architecture.
Architecture StateRaw .aimdb/state.toml as a TOML document. Contains all record definitions and connector config.
Architecture ValidationValidation errors and warnings from .aimdb/state.toml. Does not require a running instance.
Mermaid Diagram ConventionsThe canonical visual language for AimDB architecture diagrams: node shapes per buffer type, arrow styles for data flow vs connector metadata, and labelling rules. Embedded in the binary β€” read-only.
Architecture MemoryIdeation context and design rationale from .aimdb/memory.md. Captures the conversational why behind every decision: questions asked, answers received, alternatives rejected, and future considerations. Read this on session start to restore full design context.

TDQS

A3.6/5.0

Scored across 30 tools

Disambiguation4/5

Most tools target clearly distinct runtime or architecture actions, such as get_record vs. drain_record vs. set_record. The proposal tools are mostly well separated, though propose_add_record, propose_modify_fields, and propose_modify_key_variants can overlap for record-definition edits, requiring description-level reading to choose correctly.

Naming Consistency4/5

The set is overwhelmingly snake_case and most names follow a verb_noun pattern like get_record, set_record, and propose_add_task. Minor deviations exist: graph_nodes/graph_edges/graph_topo_order are noun-first, and remove_task/rename_record behave like proposals but lack the propose_ prefix used elsewhere.

Tool Count3/5

With 30 tools, the server is heavy for an agent tool surface and splits attention across runtime inspection, graph analysis, profiling, and architecture proposals. The tools are not redundant, but the count is high enough that selection pressure and prompt load become concerns.

Completeness4/5

The surface covers runtime discovery, reads/writes, schema, metrics, profiling, graph topology, validation, and a broad architecture proposal lifecycle. A few gaps remain, such as no explicit remove_connector or modify_task/binary operation, but agents can likely work around them through adjacent proposals.

Maintenance

ActivityActive
ResponsivenessSlow