Skip to main content
Glama

nlqdb — analytical memory for AI agents

by com.nlqdb

Connect an existing database so the agent can query it in English

nlqdb_connect_database

Connect an existing ClickHouse or Postgres database so the agent can query it in natural language with nlqdb_query — no migration, no schema upload. Pass the engine and a connection URL; the credential is stored sealed server-side and never echoed back. Returns the new dbId and a preview of the discovered schema.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoOptional display name for the connection; defaults to the database/host name.
engineYesWhich engine the existing database runs — 'clickhouse' or 'postgres'.
connection_urlYesThe full connection URL for the database, including credentials (e.g. postgres://user:pass@host:5432/db or https://host:8443?user=…). Stored sealed server-side and never echoed back.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations only provide destructiveHint=false, so the description carries the transparency burden. It adds key behavioral context: no migration or schema upload, credentials stored sealed server-side and never echoed back, and the return of a new dbId plus schema preview. This is substantive and does not contradict the annotations.

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 crisp sentences that front-load the core purpose, then provide usage, security, and return information. Every phrase earns its place; no fluff or repetition of schema field names beyond necessary context.

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 the tool's moderate complexity and lack of output schema, the description covers the goal, required inputs, security behavior, and return value. It lacks explicit error-handling or network/prerequisite details, but the essential flow (connect, get dbId, query later) is clear, making it fairly complete.

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?

Schema description coverage is 100%, so the schema already documents all three parameters. The description mostly reinforces existing schema details (engine and connection URL) without adding new semantic meaning. It does not explain the 'name' parameter beyond what schema provides, yielding a baseline score of 3.

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 states a specific action (Connect an existing ClickHouse or Postgres database) with a clear purpose (so the agent can query it in natural language with nlqdb_query). It clearly distinguishes this tool from siblings like nlqdb_query by positioning it as the setup step that returns a dbId for later queries.

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 gives clear context: use this to connect an existing database, pass engine and connection URL, and it enables subsequent nlqdb_query calls. It implies the tool should be called before querying, but it doesn't explicitly state when not to use it or name alternatives such as nlqdb_remember or nlqdb_list_databases.

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

All nlqdb — analytical memory for AI agents toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
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.

Resources