Skip to main content
Glama

nlqdb — analytical memory for AI agents

Server Details

Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.

Ownership verified

Glama couldn't complete the latest health check. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.

If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.

Status
Unhealthy
Uptime
42.5% over 36 days
OAuth
Works in Glama
Last Tested
Transport
Streamable HTTP
URL
Repository
nlqdb/nlqdb
GitHub Stars
1
Server Listing
nlqdb

TDQS

A4.4/5.0

Scored across 6 tools

Disambiguation4/5

The toolset is mostly well-separated: connect, list/describe, remember, and read/query serve clear roles. The main overlap is between nlqdb_read and nlqdb_query, both of which are natural-language query tools; their read-only vs. general-purpose safety distinction is described, but it can still cause some selection ambiguity.

Naming Consistency4/5

All tools share the nlqdb_ prefix, lowercase snake_case, and a verb-first style, which makes the set feel coherent. The main inconsistency is that some names include an object, like list_databases or connect_database, while others like describe, read, and query do not.

Tool Count5/5

Six tools is a well-scoped size for this domain: connecting, inspecting, listing, querying, read-only querying, and writing memory each have a clear role. No tool feels redundant, and none is missing a needed counterpart at the tool-count level.

Completeness4/5

The server covers the core memory lifecycle: connect databases, describe/list them, query them, safely read them, and write typed memory rows. There are minor gaps around explicit disconnect/forget/delete affordances, though destructive queries with confirmation can cover much of that behavior.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool update
    • Addednlqdb_read
  2. 1 tool update
    • Changednlqdb_remember3 fields changed
      • changedInput schema / properties / kind / description
        Previous value: -"Which memory table to write into: 'fact' (a durable statement to recall later), 'episode' (one conversation/tool turn), or 'entity' (a person/project/thing — upserts on agent+kind+name)."New value: +"Which memory table to write into. Prefer 'entity' for anything with a current state (a project, a person, a config) — an entity is the CURRENT SNAPSHOT and upserts on (agent+kind+name), so re-remembering refreshes it in place instead of accumulating stale rows. Use 'fact' for a statement whose truth is time-bound (a status update, an observation, an idea) — give it a ttlSeconds when it's transient. Use 'episode' for one conversation/tool turn (append-only log)."
      • changedInput schema / properties / payload / description
        Previous value: -"Kind-specific fields. fact: { content, kind?, tags?, source? }. episode: { role, content, tool_calls?, tokens? }. entity: { kind, canonical_name, properties? }. Write for the queries you'll ask later: fact kind + tags become GROUP BY columns — reuse a small lower_snake kind vocabulary (leaving every row on the default 'fact' makes categories unqueryable) and tag every id/topic the row touches. Keep numeric measures in entity properties (JSONB), not inside prose content; an entity re-remember replaces properties when provided, so re-send the whole object. Make content one self-describing sentence, so a row reads correctly on its own in a result set."New value: +"Kind-specific fields. fact: { content, kind?, tags?, source? }. episode: { role, content, tool_calls?, tokens? }. entity: { kind, canonical_name, properties? }. Write for the queries you'll ask later: fact kind + tags become GROUP BY columns — reuse a small lower_snake kind vocabulary (leaving every row on the default 'fact' makes categories unqueryable) and tag every id/topic the row touches. Entities are current snapshots: keep the state in `properties` (JSONB) and re-remember the entity to update it — an upsert on (agent, kind, canonical_name) replaces properties when provided, so re-send the whole object. Prefer updating an entity over accumulating facts about it. Supersede rather than accumulate: when a fact becomes wrong or outdated, write the corrected fact (same tags) rather than piling on — old facts fade via ttlSeconds; entities are refreshed in place. Make content one self-describing sentence, so a row reads correctly on its own in a result set."
      • changedInput schema / properties / ttlSeconds / description
        Previous value: -"Optional TTL in seconds — sets expires_at on a fact so it can be swept later."New value: +"Optional TTL in seconds — sets expires_at on a fact. Expired facts stop appearing in queries (RLS filters them out) and are physically evicted opportunistically on subsequent writes, so memory forgets what it no longer needs. Set this on any fact whose relevance is time-bound (a status, an observation, a hypothesis) — a day for daily standups, a week for weekly plans, a month for quarterly context. Facts without a TTL live forever; entities never expire (update them in place instead)."
  3. 1 tool update
    • Changednlqdb_remember2 fields changed
      • changedInput schema / properties / db / description
        Previous value: -"The agent_memory_v1 database id (db_agent_memory_v1_…). Provision one with db.create { preset: 'agent_memory_v1' }; a non-memory DB is rejected with wrong_preset."New value: +"Optional. The agent_memory_v1 database id (db_agent_memory_v1_…). Omit on first use and this tool will find (or provision) your account's memory DB automatically and return the new dbId in the result — pass that on subsequent calls. A non-memory DB is rejected with wrong_preset and the recovery is the same: omit `db` to auto-provision."
      • changedInput schema / required
        Previous value: -[
        -  "db",
        -  "kind",
        -  "payload"
        -]New value: +[
        +  "kind",
        +  "payload"
        +]
  4. 5 tool updates
    • First observednlqdb_connect_database
    • First observednlqdb_describe
    • First observednlqdb_list_databases
    • First observednlqdb_query
    • First observednlqdb_remember

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    B
    maintenance
    An MCP server that gives AI agents direct read-only access to PostgreSQL databases, enabling natural language analytics through tools for schema exploration, querying, trend analysis, and data quality checks.
    11
    5
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    A personal memory MCP server that ingests AI agent conversation logs from multiple platforms into a searchable PostgreSQL+pgvector database, enabling cross-session recall of past reasoning and decisions.
    6
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    Agent memory as a PostgreSQL extension: hybrid HNSW+BM25 recall, write-time provenance gates, and outcome-weighted confidence. The MCP server exposes ingest and recall tools over stdio for Claude Code, Codex CLI, and Gemini CLI.
    8
    Apache 2.0
Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.