Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
ANUMANA_DSNNoPostgres connection string (DSN) used by Anumana to read your real schema via EXPLAIN. Use a read-only Postgres role. Omit ANUMANA_DSN to run in schema-only mode (DDL in, no DB connection).

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,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_targetsA

List the databases Anumana is configured to analyse — each with its name, engine, and whether it's diagnosable. Call this FIRST in a multi-DB setup to see which target holds the data the user asked for, then pass target= to the other tools. In a single-DB setup you can omit target and the one database is used. Never returns connection strings or secrets.

list_policiesA

List the operator's standing enforcement policies — the rules that can BLOCK or WARN on a query regardless of what you intend. Each has a name, scope (which target/engine), condition (risk tier and/or flag), and action (block/warn/allow). preflight_query and suggest_query already apply these and attach the verdict; call this to explain to a user WHY a query was blocked. No policies configured means open by default (nothing blocked).

preflight_queryA

Before running ANY SQL query you (the agent) just wrote, check how costly it will be on the real schema — WITHOUT executing it. Returns a risk tier (cheap/moderate/expensive/dangerous), rows scanned vs returned, scan strategy, and overhead flags (missing index, SELECT *, no LIMIT, N+1 / nested-loop blowup). EXPLAIN only — never runs the query. In a multi-DB setup pass target= (see list_targets). For similarity search use preflight_vector_search; with no DB use preflight_schema_only.

preflight_vector_searchA

Before running a VECTOR SIMILARITY SEARCH (pgvector: ORDER BY embedding <-> $1 LIMIT k, cosine <=>, inner-product <#>), check its cost WITHOUT running it — for any RAG / semantic-search / nearest-neighbour query you generate. Catches the vector traps a plain SQL check misses: brute-force scan with no HNSW/IVFFlat index (FULL_VECTOR_SCAN), top_k too large (TOP_K_TOO_LARGE), unbounded search (UNBOUNDED_VECTOR_SEARCH), and metadata- filter/ANN recall loss (VECTOR_FILTER_INTERACTION). EXPLAIN only. Pass target= in a multi-DB setup; the target should be a pgvector engine.

rewrite_queryA

Rewrite a slow query into a cheaper, equivalent one and PROVE the improvement by EXPLAIN-ing both and comparing planner cost. Call after a preflight flags a query expensive/dangerous. Returns the rewritten query, what changed, before/after cost, and index suggestions — ONLY suggesting a btree index when the filter is selective enough to help (an HNSW index for a vector target). Includes equivalence caveats. Pass target= in a multi-DB setup.

explain_query_workingA

Explain in plain English HOW a query behaves — two layers: (1) the logical gather order (FROM -> WHERE -> GROUP BY -> HAVING -> SELECT -> ORDER BY -> LIMIT), why 'LIMIT 10' can still be slow; and (2) the actual physical plan the engine chose for THIS query, bottom-up. Call when a user asks why a query is slow or how it runs. Teaching tool. Pass target= in a multi-DB setup.

describe_schema_toolA

Read a database's REAL schema — tables/collections, columns/fields, INDEXES, and row counts — so you can write a grounded, cost-aware query BEFORE guessing. Call this FIRST when a user asks for data and you don't already know the schema; it tells you which columns are indexed so your query hits an index, not a full scan. READ-ONLY catalog access — never reads data rows. If the schema can't be read it returns need_from_user naming what to ask the user for. Pass target= in a multi-DB setup; combine with list_targets to find which DB has the data.

suggest_queryA

Grade a query you (the agent) wrote for a user's data request and get told whether to RUN it or REFINE it — the check step of generate->check-> refine. Workflow: (1) describe_schema_tool to learn columns + indexes, (2) write a candidate for the user's intent, (3) call this. Returns next_action: 'accept' (cheap/moderate — run it) or 'refine' (expensive/ dangerous — here are the high-severity flags + a VERIFIED cheaper rewrite; fix and call again). You write the SQL; Anumana owns cost truth. Bound your loop to ~3 rounds. Pass target= in a multi-DB setup.

preflight_schema_onlyA

Analyse a query against pasted CREATE TABLE DDL with NO database connection — the zero-trust, offline front door. Call when the user gave you their schema (DDL) but not DB credentials. Catches SELECT *, missing LIMIT, un-indexed filter columns, LIKE '%...', functions on filtered columns. HEURISTIC only (no live counts) and says so. No target needed.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.1/5.0

Scored across 9 tools

Disambiguation3/5

The set has a dense cluster around cost-checking a query: preflight_query, suggest_query, and rewrite_query all assess/verify query cost and rewrite behavior, making it non-obvious which to call first (descriptions do disambiguate via the generate->check->refine framing). The preflight_* trio is well-separated by scope (SQL vs vector vs offline DDL), and explain_query_working is distinct as a teaching tool.

Naming Consistency3/5

Most names follow a verb_noun pattern (list_targets, list_policies, rewrite_query, suggest_query) and the preflight_* prefix is consistent. However, describe_schema_tool adds a redundant '_tool' suffix and explain_query_working ends in '_working', breaking the pattern in two places.

Tool Count5/5

Nine tools is well-scoped for a query cost-analysis/enforcement server, with each tool covering a recognizably distinct surface (targets, policies, three preflight variants, rewrite, explanation, schema, grading). No bloat or thinness.

Completeness4/5

The domain (analyze/grade/rewrite queries without executing them) is covered end-to-end: discover targets, inspect schema, learn policies, preflight SQL/vector/offline, rewrite, and explain. Minor gaps exist, e.g. no explicit connectivity/health probe or standalone equivalence-verification tool, but core workflows are complete.

Maintenance

ActivityMaintained
ResponsivenessNo issues