Anumana
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANUMANA_DSN | No | Postgres 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
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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: |
| 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 |
| 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
|
| 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
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
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.
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.
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.
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.