Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

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
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
db_listA

List the connection profiles from the anydb config file (~/.anydb/db.json): name, description, driver, which one is the default, and whether it is read-only. Call this first whenever you do not already know a profile name, then pass the name to the other tools as "profile". The result never contains a connection string, a host, a username or a password -- not masked, absent -- because this text goes into your context window and a config file is writable by anyone who can write files. If there is no config file, use "uri" with the other tools instead.

db_queryA

Run one statement against one database (PostgreSQL, MySQL/MariaDB, SQLite, MongoDB or Redis, inferred from the connection). READ-ONLY BY DEFAULT: writes are refused unless "readOnly" is false, and statements that change schema or privileges additionally require "allowDestructive" to be true. Call db_list and db_schema first so table and column names are not guessed, and prefer "params" over inlining values in "query" so the values never appear in the statement text. Put a LIMIT in every query: results are capped anyway, and a cap you did not ask for is how a table gets silently half-read. MongoDB: "collection" is required and "action" picks the operation -- find, count, distinct, aggregate and explain read; insert, update, updateOne, replace, delete and deleteOne write and need "readOnly": false. Prefer the *One actions: one document, not every match. Redis: "query" is a single command such as GET or SCAN.

db_schemaA

Describe the structure of a database: tables and their columns for SQL, collections with their indexes for MongoDB, keyspace statistics for Redis. Call it before writing a query so names are not guessed -- it is almost always cheaper than a failed query. Runs read-only introspection statements only, never a statement of yours, and "table"/"collection" are bound as parameters wherever the driver allows rather than pasted into SQL. "detail": "full" adds foreign keys, index definitions, primary and unique constraints, row estimates, and inferred field schemas for MongoDB.

db_explainA

Return the execution plan for a statement WITHOUT running it. Read-only by construction: the statement is planned and not executed, so this is the safe way to catch a sequential scan over a large table and the cheapest way to find a missing index. ANALYZE variants are refused here on purpose, because "EXPLAIN ANALYZE" runs the statement it plans. MongoDB: pass "collection" and a find filter as "query"; a pipeline cannot be explained, use db_query action "aggregate" with a small limit. Redis has no plans, so this tool refuses it.

db_healthA

Ask the database about itself: reachable or not, server version, the role this server authenticated as, whether that role or the server is read-only, object counts, and this server's pool and cache state. Use it instead of guessing at why a connection or a write failed. Note what "readOnly": false does and does not do: it is a request to THIS server, not a security boundary. The boundary is the database role -- a role holding INSERT will succeed whatever these flags say, and a role without them will fail however many are set.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.7/5.0

Scored across 5 tools

Disambiguation5/5

Each tool targets a clearly distinct aspect: db_query executes statements, db_explain plans without executing, db_schema introspects structure, db_list lists connection profiles, and db_health reports server status. The descriptions explicitly differentiate execution vs planning vs introspection vs connection listing vs health, so an agent can easily select the right tool.

Naming Consistency5/5

All five tools share a uniform db_ prefix and snake_case style, making the naming predictable and easy to scan. Although the second component is sometimes a verb (query, list, explain) and sometimes a noun (schema, health), the overall convention is consistent and unambiguous.

Tool Count5/5

Five tools is a well-scoped set for a multi-database MCP server. Each tool has a distinct, non-redundant role, and no obvious gaps or bloat exist within the stated scope of querying, schema inspection, planning, and health checking.

Completeness5/5

The surface covers the full lifecycle for database interaction: discovering connections (db_list), understanding structure (db_schema), executing read/write statements (db_query), safely planning (db_explain), and health/status (db_health). It handles multiple database types and includes safeguards, leaving no significant missing operations for the stated purpose.

Maintenance

ActivityMaintained
ResponsivenessNo issues