The OtterStax MCP Server
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| OTTERSTAX_URL | No | PostgreSQL-wire address of the OtterStax server | postgresql://localhost:8817 |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_sqlA | Run any SQL statement on OtterStax (SELECT, DDL, DML, COPY, CREATE SOURCE/STREAM). Tables must be fully qualified: alias.db.table or alias.db.schema.table. Returns {columns, rows, row_count}; all values come back as text or JSON numbers. |
| explain_queryB | Show the plan of a statement (EXPLAIN ). The OtterStax build you talk to may not support EXPLAIN yet; then this returns the server's error. |
| list_databasesA | List OtterStax databases. kind 'connection' is a registered backend (MySQL/PostgreSQL/ClickHouse) whose tables are named .. or ...; kind 'local' is an engine database. |
| list_schemasA | List the schemas inside a database: '' for a MySQL/ClickHouse connection, '.' for a PostgreSQL one. A local database has none. |
| list_tablesB | List tables and views under the full SQL names to use in execute_sql. |
| describe_tableB | Columns of a table with their SQL types and nullability. |
| search_objectsA | Search tables or columns by name across all databases with a LIKE pattern. detail_level: names (minimal), summary (tables: column and row counts; columns: type), full (tables: also columns and indexes). summary/full on tables run COUNT(*) on each match. |
| table_statsA | Profile a table in one query: row count and, per column, distinct count, NULL count, MIN and MAX. Without columns every column is profiled, which scans the whole table on its backend. |
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 8 tools
Each tool has a fairly clear role: discovery (list_databases/list_schemas/list_tables/describe_table), execution (execute_sql), planning (explain_query), and profiling (table_stats). However, execute_sql can already run any statement including EXPLAIN, so explain_query overlaps, and search_objects versus list_tables/describe_table have partially overlapping lookup purposes.
Seven of eight tools follow a clean verb_noun pattern (explain_query, execute_sql, list_databases, list_schemas, list_tables, describe_table, search_objects). table_stats deviates to a noun_noun form, a minor inconsistency but still readable.
Eight tools is well-scoped for a SQL database engine, covering discovery, execution, planning, and profiling without redundancy. Each tool earns its place.
The surface covers exploration (databases, schemas, tables, columns, search) plus execution, explain, and profiling, which is strong for a query engine. Minor gaps like query cancellation or session/connection management are absent but not blocking for typical agent workflows.