Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
PGSTEWARD_ENV_SUFFIXESNoComma-separated list of suffixes to label environments. Example: prod,staging
PGSTEWARD_DB_CONNECTIONSYesCSV of id:prefix pairs for database connections. Example: web-shop:WEB_SHOP,analytics:ANALYTICS

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
tasks
{
  "list": {},
  "cancel": {},
  "requests": {
    "tools": {
      "call": {}
    },
    "prompts": {
      "get": {}
    },
    "resources": {
      "read": {}
    }
  }
}
tools
{
  "listChanged": true
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_connectionsA

List the configured connections: id, read_only and inferred environment. Start here; every other tool needs a connection_id. Set probe=true to also test reachability, which opens a connection to each database.

list_databasesA

List the databases on this connection's server. Querying one needs its own configured connection: PostgreSQL cannot read across databases in a session.

list_schemasA

List the non-system schemas in this connection's database.

list_tablesB

List tables and views in a schema (default "public").

describe_tableA

Describe one table or view: columns, primary key, foreign keys, indexes and an instant row-count estimate. Fails with an explicit error if the relation does not exist.

search_schemaA

Find tables and columns whose name contains a substring, across every non-system schema. Use it when you know the field you need but not which table holds it. Note that "_" and "%" are wildcards.

queryA

Run a single SQL statement. Read-only by default; writes need the connection policy to allow them. Use params for positional parameters ($1) rather than string interpolation. Rows are capped by min(limit, the connection max_rows): applied_limit is the cap that was used and truncated says rows were dropped. When applied_limit is below the limit you asked for, max_rows cut the result and the answer is incomplete. A separate cap on response size can also cut it; when it does, notes says so and the fix is fewer columns, not fewer rows.

explain_queryA

Execution plan via EXPLAIN (FORMAT JSON), parsed into a tree with warnings for sequential scans and stale statistics. analyze=true physically executes the statement to get actual row counts and timings; without it there are planner estimates and no timings.

analyze_db_healthA

Eleven deterministic checks over the system catalog: connections, idle transactions, long queries, cache hit rate, invalid, unused and duplicate indexes, constraints, wraparound, sequences, replication. No extensions required. A check returns skipped, not ok, when the role lacks the privilege or the statistics window is too short to judge; overall_status is unknown when nothing could be checked.

pingA

Check that a connection is reachable (SELECT 1).

get_server_infoC

Server version and current database behind a connection.

get_security_configA

Effective policy of a connection: read_only, whether DML and DDL are allowed, max_rows, max_bytes and query_timeout. Check it before attempting a write.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.7/5.0

Scored across 12 tools

Disambiguation4/5

Each tool maps to a distinct level of PostgreSQL hierarchy (connection → database → schema → table) or a distinct action (query, explain, health analysis), so selection is straightforward. Minor overlaps exist: ping largely duplicates list_connections with probe=true, and get_server_info overlaps slightly with list_databases, but descriptions clarify the intended use.

Naming Consistency4/5

Names are uniformly snake_case and mostly follow a verb_noun pattern (list_tables, describe_table, analyze_db_health). Two bare verbs (ping, query) are the only deviations and are conventional enough to remain predictable.

Tool Count5/5

Twelve tools is well-scoped for a PostgreSQL introspection and stewardship server; each earns its place across discovery, execution, planning, health, and policy concerns. No obvious redundancy that should be merged.

Completeness4/5

The surface covers the full exploration lifecycle plus query execution, EXPLAIN, health checks, and policy inspection, with writes handled via query under policy. Minor gaps remain: no session/cancel tool, no standalone index or role/privilege listing, and no extension enumeration, though these are largely reachable through query.

Maintenance

ActivityMaintained
ResponsivenessNo issues