Provides tools for exploring and querying MySQL databases, including schema discovery, safe query execution, natural language to SQL, and CSV export.
Provides natural language to SQL generation using OpenAI-compatible language models, enabling users to describe queries in plain English.
Provides tools for exploring and querying PostgreSQL databases, including schema discovery, safe query execution, natural language to SQL, and CSV export.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Database Assistant MCP Server describe the customers table"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A read-only MCP (Model Context Protocol) server for database exploration and querying. Connect any MCP-compatible client (AWS Kiro, Claude Desktop, etc.) to your PostgreSQL or MySQL database and explore schemas, run queries, generate SQL from natural language, and export results as CSV.
Schema Discovery — List databases, schemas, tables, columns, constraints, indexes, and foreign key relationships
Safe Query Execution — AST-based SQL validation ensures only read-only queries run
Natural Language to SQL — Describe what you want in plain English and get a validated SQL query
CSV Export — Export any query result to a CSV file
Query Explanation — Run EXPLAIN ANALYZE to understand query performance
Pagination — Large results are paginated (100 rows/page) automatically
Audit Logging — Every query is logged with timestamp, execution time, and row count
Related MCP server: Read-only Database MCP
Tool | Description |
| List all databases on the server |
| List schemas (filtered by allowlist) |
| Tables in a schema with types and row counts |
| Columns, types, constraints, and indexes |
| Foreign key tree (incoming + outgoing) |
| Quick N-row preview of a table |
| Check if a query is safe before running |
| Execute a validated read-only query |
| EXPLAIN ANALYZE with execution plan |
| Natural language → SQL (LLM-powered) |
| Execute query and save results as CSV |
This server enforces strict read-only access:
AST-based validation — SQL is parsed into an abstract syntax tree using sqlglot, not regex
Blocked operations — INSERT, UPDATE, DELETE, DROP, ALTER, TRUNCATE, CREATE, GRANT, REVOKE, COPY, CALL
Single-statement only — Multi-statement queries (; separated) are rejected
Dangerous function blocking — pg_read_file, lo_export, dblink, LOAD_FILE, etc.
Automatic LIMIT — Queries without a LIMIT get one injected (default: 1000 rows max)
Query timeout — Enforced at the database level (default: 10 seconds)
Schema allowlist — Restrict access to specific schemas only
Generated SQL re-validation — LLM-generated queries pass through the same validator
Python 3.10+
uv package manager
PostgreSQL or MySQL database
Clone and install dependencies:
cd /path/to/RDS
uv syncConfigure environment:
cp .env.example .env
# Edit .env with your database credentialsSeed a test database (optional):
psql -U postgres -f seed.sqlThis creates an ecommerce database with 50 tables and ~25,000 rows across customers, products, orders, analytics, support, and more.
Set these environment variables (via .env file or system environment):
Variable | Required | Default | Description |
| Yes | — | Database hostname or RDS endpoint |
| No |
| Database port |
| Yes | — | Database name |
| Yes | — | Database user (use a read-only user) |
| Yes | — | Database password |
| No |
|
|
| No | (all) | Comma-separated schema allowlist |
| No |
| Max query execution time (seconds) |
| No |
| Maximum rows returned per query |
| No |
| Directory for CSV exports |
| No | — | LLM API endpoint (for |
| No | — | LLM API key (for |
| No |
| LLM model ID |
Add to your Kiro MCP configuration:
{
"mcpServers": {
"database-assistant": {
"command": "/opt/homebrew/bin/uv",
"args": ["run", "--directory", "/path/to/database_mcp_server", "mcp_server.py"],
"env": {
"DB_HOST": "your-rds-endpoint.rds.amazonaws.com",
"DB_PORT": "5432",
"DB_NAME": "ecommerce",
"DB_USER": "readonly_user",
"DB_PASSWORD": "your_password",
"DB_TYPE": "postgresql",
"ALLOWED_SCHEMAS": "store"
}
}
}
}Add to claude_desktop_config.json:
{
"mcpServers": {
"database-assistant": {
"command": "uv",
"args": ["run", "--directory", "/path/to/RDS", "mcp_server.py"]
}
}
}uv run mcp dev mcp_server.pyuv run mcp_server.pyUser: What tables are in this database?
→ list_tables(schema="store")
User: Tell me about the orders table
→ describe_table(table="store.orders")
User: What relates to orders?
→ describe_relationships(table="store.orders")User: Show me the top 10 customers by revenue this year
→ generate_sql(question="top 10 customers by total order revenue in 2024")
→ validate_sql(query="SELECT ...")
→ run_sql(query="SELECT ...")User: Export all orders from last month as CSV
→ generate_sql(question="all orders created in the last 30 days with customer name and total")
→ export_csv(query="SELECT ...")
→ Returns: /tmp/db_exports/export_20240715_143022_a1b2c3d4.csvMCP Client (Kiro / Claude Desktop)
│
▼ (stdio)
┌─────────────────────────────┐
│ mcp_server.py │ FastMCP server, 11 tools
├─────────────────────────────┤
│ sql/validator.py │ AST-based safety validation (sqlglot)
│ sql/generator.py │ NL→SQL via OpenAI-compatible LLM
│ db/schema.py │ Schema introspection service
│ db/connection.py │ Async connection pool (asyncpg/aiomysql)
│ export/csv_export.py │ CSV file generation
│ config.py │ Environment-based configuration
└─────────────────────────────┘
│
▼
PostgreSQL / MySQL / AWS RDS.
├── mcp_server.py # MCP server entry point with tool definitions
├── config.py # Configuration from environment variables
├── db/
│ ├── connection.py # Async connection manager with pooling
│ └── schema.py # Schema introspection service
├── sql/
│ ├── validator.py # SQL validation (sqlglot AST)
│ └── generator.py # LLM-based SQL generation
├── export/
│ └── csv_export.py # CSV export utility
├── seed.sql # Sample database (50 tables, 25k+ rows)
├── pyproject.toml # Dependencies and project metadata
├── .env.example # Environment variable template
└── .gitignoreFor production use, create a dedicated read-only user:
-- PostgreSQL
CREATE USER readonly_user WITH PASSWORD 'secure_password';
GRANT CONNECT ON DATABASE ecommerce TO readonly_user;
GRANT USAGE ON SCHEMA store TO readonly_user;
GRANT SELECT ON ALL TABLES IN SCHEMA store TO readonly_user;
ALTER DEFAULT PRIVILEGES IN SCHEMA store GRANT SELECT ON TABLES TO readonly_user;-- MySQL
CREATE USER 'readonly_user'@'%' IDENTIFIED BY 'secure_password';
GRANT SELECT ON ecommerce.* TO 'readonly_user'@'%';
FLUSH PRIVILEGES;mcp — Model Context Protocol SDK
sqlglot — SQL parser for validation
asyncpg — Async PostgreSQL driver
aiomysql — Async MySQL driver
openai — LLM API client (for SQL generation)
python-dotenv — Environment variable loading
pydantic — Data validation
MIT
Show foreign key relationships for a table: both outgoing (this table references others) and incoming (others reference this table).
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name in 'schema.table' format (e.g., 'public.orders') |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the basic operation and does not disclose any behavioral traits such as read-only nature, performance impact, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the tool's purpose efficiently without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the tool is relatively simple, the description is adequate. It could optionally mention what the output includes (e.g., column details), but the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds no additional meaning beyond what the schema already provides for the 'table' parameter. The schema's description is already clear about the format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows foreign key relationships for a table, specifying both outgoing and incoming directions. It distinguishes itself from sibling 'describe_table' which likely describes table structure, not relationships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one needs to see foreign key relationships, but it does not explicitly state when to use this tool versus alternatives like 'describe_table' or 'explain_query'. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed table information: columns (name, type, nullable, default), constraints (PK, FK, unique), and indexes.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name. Use 'schema.table' format (e.g., 'public.users') or just 'table' for the default schema. |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose read-only nature, authentication needs, or potential side effects. It only states what is returned, leaving behavioral traits ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence listing key return categories. No redundant words, but could be slightly more structured with bullet points. Efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity and presence of output schema, description adequately covers return categories. Lacks high-level context like performance implications or pagination, but sufficient for basic understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'table' with schema description (100% coverage). Description adds value by explaining the 'schema.table' format and default schema behavior, beyond the schema's basic field description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns detailed table information including columns, constraints, and indexes. It distinguishes from sibling tools like list_tables (which lists names only) and describe_relationships (focus on relationships).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly suggests use for getting table details, but no explicit when-to-use or when-not-to-use compared to siblings like describe_relationships. Lacks guidance on alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run EXPLAIN ANALYZE on a SQL query to show the execution plan. Helps understand performance characteristics like index usage, sequential scans, and estimated costs.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL SELECT query to explain |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It correctly notes that the tool executes EXPLAIN ANALYZE, which runs the query, but does not disclose potential performance impact or that it is read-only. The lack of side-effect or safety caveats limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no unnecessary words, front-loaded with the main action and purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the core functionality and examples of insights. It could mention that the output is an execution plan (though implied) and caution about query execution cost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'query' parameter. The description adds context about EXPLAIN ANALYZE but does not significantly enhance parameter meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs EXPLAIN ANALYZE on a SQL query and lists specific performance insights (index usage, scans, costs). It distinguishes from siblings like run_sql (execution) and validate_sql (syntax) by focusing on performance analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for understanding query performance but does not explicitly state when not to use it (e.g., for non-SELECT queries or when execution cost is high). No alternatives are mentioned, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SQL query and export results as a CSV file. The query is validated for safety. Returns the file path of the generated CSV.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL SELECT query to export |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description reveals query validation and file path return, but omits side effects, permissions, or storage duration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief (three sentences) and front-loaded with core action, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists and tool is simple, description covers main action, safety validation, and return value; minor gaps on error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description does not add meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool executes a SQL query and exports results as a CSV file, which is distinct from siblings like 'run_sql' that return results directly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'run_sql'. The description only implies usage for CSV export without contrasting with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a SQL query from a natural language question. Uses the database schema as context and an LLM to produce a valid SELECT query. The generated query is validated for safety.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema to use for context | public |
| question | Yes | Natural language question (e.g., 'What are the top 10 customers by order count?') |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions validation for safety but lacks specifics (e.g., ensures read-only?). Does not disclose constraints like output always being SELECT.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key purpose and process, no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main purpose and safety validation but lacks detail on what safety entails and any limitations. With output schema present, not necessary to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline applies. Description adds minimal value beyond schema: mentions SELECT and validation, but does not elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool generates SQL from natural language, using schema context and LLM, and validates for safety. Distinguishes from sibling tools like run_sql and validate_sql.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for generating SELECT queries from natural language, but does not explicitly state when not to use (e.g., for DDL) or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available databases on the connected server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states it lists databases, implying a read operation, but lacks details about authentication, permissions, or edge cases. Minimal but acceptable for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema present), the description is adequate. It fully communicates the tool's function, though it could optionally mention if it requires authentication or returns an empty list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the input schema has full coverage. The description adds no parameter information, but with no parameters, this is not a deficiency. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all available databases, with a specific verb (List) and resource (databases). It distinguishes itself from sibling tools like list_tables or list_schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, but for a simple listing tool, the purpose is self-explanatory. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all schemas in the connected database. For PostgreSQL returns schema names, for MySQL returns databases.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states the basic function and does not disclose whether the tool is read-only, any permissions required, side effects, or error conditions. For a simple listing tool, more transparency would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no unnecessary words. It is front-loaded and gets straight to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an existing output schema, the description adequately explains the tool's purpose and database-specific behavior. However, it could mention behavior for other database types (e.g., SQLite) and whether the output is a list of names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the input schema is empty with 100% coverage. The description adds meaning by explaining the database-specific behavior, which is relevant context. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists all schemas in the connected database, with specific behavior for PostgreSQL and MySQL. It uses a specific verb-resource pair and distinguishes from sibling tools like list_tables and list_databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides some context about database-specific behavior (PostgreSQL vs MySQL) but does not explicitly guide when to use this tool versus alternatives like list_databases or list_tables. No usage exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in a schema with their types (BASE TABLE or VIEW) and approximate row counts.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (e.g., 'public' for PostgreSQL) | public |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly implies a read-only operation ('List'), but does not explicitly state side-effect-free behavior or potential limitations (e.g., row counts may be approximate). However, the behavior is transparent enough for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and expected output. No extraneous words, front-loaded with key information, and every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one simple parameter, and an output schema exists (though not shown). The description covers what the tool does and what is returned (types and row counts). There are no obvious gaps given the low complexity and presence of output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage; the schema already documents the parameter with a clear description. The tool description does not add new meaning beyond confirming the role of the schema parameter, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List all tables', specifies the resource 'tables in a schema', and includes the specific attributes returned (types and row counts). This distinguishes it from siblings like describe_table (single table) and list_schemas (schemas).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as describe_table or run_sql. While the purpose is clear, there is no mention of when not to use it or trade-offs, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a read-only SQL query. The query is validated for safety before execution. Supports pagination (100 rows per page). Returns columns, rows, row count, and execution time.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination (100 rows per page) | |
| query | Yes | SQL SELECT query to execute |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Details read-only constraint, safety validation, pagination (100 rows per page), and return values (columns, rows, count, execution time). No annotations provided, so description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with purpose, no wasted words. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema and the description explains return values. Parameters fully described in schema. Complete for a read-only query tool with pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. Description repeats pagination info but adds no new detail beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Execute a read-only SQL query', specifying the verb (execute) and resource (SQL query), and distinguishes itself from siblings like generate_sql and validate_sql by emphasizing read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States it is read-only and validated for safety, which implies when to use. However, does not explicitly contrast with siblings like validate_sql or explain_query, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a quick preview of data in a table. Returns the first N rows to help understand data format and contents.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of rows to return (1-50, default: 5) | |
| table | Yes | Table name in 'schema.table' format |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates a read-only operation ('preview') and non-destructive behavior, which is adequate for this simple tool. However, it does not explicitly confirm no side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, presence of an output schema (which likely documents return values), and clear purpose, the description provides sufficient context for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context about returning first N rows and understanding data format, but does not add new semantic meaning beyond the schema descriptions for 'limit' and 'table'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get a quick preview' and the resource 'data in a table', and specifies it returns the first N rows. This differentiates it from sibling tools like describe_table (structure) and list_tables (list names).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for quick previews but does not explicitly state when to use this over alternatives like describe_table or export_csv. No exclusions or comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a SQL query is safe to execute. Validates that it is read-only, single-statement, and contains no dangerous operations. Use before run_sql to preview validation.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL query to validate |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists validation criteria but does not describe what happens upon success/failure (e.g., returns boolean, throws error) or mention any side effects. Partially transparent but lacks behavioral outcomes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values need not be explained. Description covers input and purpose well. Minor gap: could mention output type or error cases, but not critical given the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with a basic description of the query parameter. The description reinforces it's a SQL query but adds no further semantics like format, examples, or constraints. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool checks SQL query safety for read-only, single-statement, and no dangerous operations. Distinguishes itself from the sibling `run_sql` by emphasizing preview validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent to use this before `run_sql` to preview validation, giving clear when-to-use direction. No exclusion criteria needed beyond that.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0describe_relationshipsdescribe_tableexplain_queryexport_csvgenerate_sqllist_databaseslist_schemaslist_tablesrun_sqlsample_datavalidate_sqlEach tool has a clearly distinct purpose covering schema browsing, querying, validation, and export. There is no overlap or ambiguity between tools.
All tool names follow a consistent verb_noun pattern using snake_case, making them predictable and easy to navigate.
11 tools provide comprehensive coverage for database exploration and safe querying without being excessive or sparse.
Covers essential CRUD-like operations for a read-only assistant, but lacks a direct row count tool and alternative export formats like JSON.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Query PostgreSQL databases in plain English — LLM-generated, safety-validated SQL.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vinycoolguy2015/database_mcp_server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
