de en es ja ko ru zh

SqlAugur

Name: SqlAugur
Author: mbentham

by mbentham

Overview Schema Related Servers Score Discussions

Hybrid

SqlAugur

NuGet NuGet Downloads License: MIT .NET 10.0

An MCP server that gives AI assistants safe, read-only access to SQL Server databases. Every query is parsed into a full AST using Microsoft's official T-SQL parser — not regex — so comment injection, string literal tricks, and encoding bypasses are blocked at the syntax level.

┌──────────────┐          ┌───────────────────────────────────────────┐        ┌──────────────┐
│              │  stdio   │  SqlAugur                                 │        │              │
│  AI Client   │◄────────►│                                           │───────►│  SQL Server  │
│              │          │  ┌────────────┐  ┌──────────────────────┐ │        │              │
└──────────────┘          │  │  Query     │  │  Schema / Diagram /  │ │        └──────────────┘
                          │  │  Validator │  │  DBA Services        │ │
                          │  └────────────┘  └──────────────────────┘ │
                          │  ┌────────────────────────────────────┐   │
                          │  │  Rate Limiter                      │   │
                          │  └────────────────────────────────────┘   │
                          └───────────────────────────────────────────┘

Quick Start

Prerequisite: .NET 10.0 runtime

1. Install

dotnet tool install -g SqlAugur

2. Configure — create ~/.config/sqlaugur/appsettings.json (Linux/macOS) or %APPDATA%\sqlaugur\appsettings.json (Windows), setting the connection string for your environment:

{
  "SqlAugur": {
    "Servers": {
      "production": {
        "ConnectionString": "Server=myserver;Database=master;Integrated Security=True;TrustServerCertificate=False;Encrypt=True;"
      }
    }
  }
}

3. Connect — add to your MCP client:

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "sqlaugur": {
      "command": "sqlaugur"
    }
  }
}

claude mcp add --transport stdio sqlaugur -- sqlaugur

Or add to .mcp.json in your project root:

{
  "mcpServers": {
    "sqlaugur": {
      "type": "stdio",
      "command": "sqlaugur"
    }
  }
}

Add to .vscode/mcp.json in your workspace:

{
  "servers": {
    "sqlaugur": {
      "command": "sqlaugur"
    }
  }
}

4. Verify — ask your AI assistant to list_servers and you should see your configured connection.

For Docker, Podman, and other install methods, see Installation.

Related MCP server: mcp-sqlserver-readonly

Why This Approach

AST-level query validation — Most MCP database servers use keyword blocking or no validation at all. This project parses every query into a full syntax tree using Microsoft's official TSql180Parser. Comment injection, string literal tricks, and encoding bypasses are blocked at the syntax level, not with fragile regex patterns.
Rate limiting — Token bucket throughput limiting and concurrency control prevent runaway AI query loops from overwhelming production SQL Servers. No other MCP database server offers this.
DBA diagnostic tooling — Integrated support for First Responder Kit, DarlingData, and sp_WhoIsActive with parameter blocking that prevents write operations. This is an entirely new MCP capability category.
Response size optimisation — DBA tools exclude verbose columns (XML query plans, deadlock graphs, metric breakdowns) and truncate long strings by default, reducing response sizes by 90–99%. Use verbose and includeQueryPlans parameters to get full untruncated output when needed.
Progressive discovery — Up to 29 tools organized into toolsets that load on demand. Only 6 core tools are exposed initially, keeping the AI's context window small and reducing token usage. Additional toolsets are discovered and enabled as needed.

Features

Security

Read-only by design — only SELECT and CTE queries are permitted
AST-based query validation using ScriptDom (not regex)
Parameter blocking on all diagnostic stored procedures to prevent writes
Concurrency and throughput rate limiting

Database Tooling

Multi-server support — named connections to multiple SQL Server instances
Schema overview — concise Markdown schema maps with PKs, FKs, constraints, and defaults
Table documentation — Markdown descriptions of columns, indexes, foreign keys, and constraints
ER diagram generation — PlantUML and Mermaid diagrams with smart cardinality detection
Schema exploration — list programmable objects, view definitions, extended properties, dependency graphs
Query plan analysis — estimated or actual XML execution plans
DBA diagnostics — optional integration with First Responder Kit, DarlingData, and sp_WhoIsActive with automatic response size optimisation
Progressive discovery — dynamic toolset mode reduces initial context window usage by exposing tools on demand

Installation

All methods produce the same MCP server.

NuGet Global Tool (recommended)

Prerequisite: .NET 10.0 runtime

dotnet tool install -g SqlAugur

Create your configuration file:

# Linux/macOS
mkdir -p ~/.config/sqlaugur
# Edit ~/.config/sqlaugur/appsettings.json with your server connections

# Windows (PowerShell)
mkdir "$env:APPDATA\sqlaugur" -Force
# Edit %APPDATA%\sqlaugur\appsettings.json with your server connections

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "sqlaugur"
    }
  }
}

To update: dotnet tool update -g SqlAugur

Docker / Podman

# Volume-mount a config file
docker run -i --rm \
  -v /path/to/appsettings.json:/app/appsettings.json:ro,Z \
  ghcr.io/mbentham/sqlaugur:latest

# Or use environment variables (no config file needed)
docker run -i --rm \
  -e SqlAugur__Servers__production__ConnectionString="Server=host.docker.internal;Database=master;..." \
  ghcr.io/mbentham/sqlaugur:latest

Note: To reach a SQL Server on the host machine, use host.docker.internal (Docker Desktop) or --network=host (Linux). Replace docker with podman — all commands are identical. The :Z flag on volume mounts is required for SELinux-enabled systems (Fedora, RHEL); Docker Desktop users on macOS/Windows can omit it.

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "docker",
      "args": ["run", "-i", "--rm",
        "-v", "/path/to/appsettings.json:/app/appsettings.json:ro,Z",
        "ghcr.io/mbentham/sqlaugur:latest"]
    }
  }
}

services:
  sqlaugur:
    image: ghcr.io/mbentham/sqlaugur:latest
    stdin_open: true
    volumes:
      - ./appsettings.json:/app/appsettings.json:ro,Z

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "docker",
      "args": ["compose", "run", "-i", "--rm", "sqlaugur"]
    }
  }
}

Build from Source

Prerequisite: .NET 10.0 SDK

git clone git@github.com:mbentham/SqlAugur.git
cd SqlAugur
dotnet publish SqlAugur -c Release -o SqlAugur/publish
cp SqlAugur/appsettings.example.json SqlAugur/publish/appsettings.json
# Edit SqlAugur/publish/appsettings.json with your server connections

MCP client configuration:

{
  "mcpServers": {
    "sqlserver": {
      "command": "dotnet",
      "args": ["/absolute/path/to/SqlAugur/publish/SqlAugur.dll"]
    }
  }
}

Configuration

The server loads configuration from multiple sources. Higher-priority sources override lower ones:

Command-line arguments
Environment variables — using __ as section delimiter (e.g., SqlAugur__Servers__production__ConnectionString=...)
Current working directory — appsettings.json in the directory you run the command from
User config directory — ~/.config/sqlaugur/appsettings.json on Linux, %APPDATA%\sqlaugur\appsettings.json on Windows
Azure Key Vault — when AzureKeyVaultUri is set (see below)
App directory — appsettings.json next to the DLL

Example configuration (Windows Authentication — recommended):

{
  "SqlAugur": {
    "Servers": {
      "production": {
        "ConnectionString": "Server=myserver;Database=master;Integrated Security=True;TrustServerCertificate=False;Encrypt=True;"
      }
    },
    "MaxRows": 1000,
    "CommandTimeoutSeconds": 30,
    "MaxConcurrentQueries": 5,
    "MaxQueriesPerMinute": 60,
    "EnableFirstResponderKit": false,
    "EnableDarlingData": false,
    "EnableWhoIsActive": false,
    "EnableDynamicToolsets": false
  }
}

Option	Default	Description
`Servers`	—	Named SQL Server connections (name → connection string)
`MaxRows`	1000	Maximum rows returned per query
`CommandTimeoutSeconds`	30	SQL command timeout for all queries and procedures
`MaxConcurrentQueries`	5	Maximum number of SQL queries that can execute concurrently
`MaxQueriesPerMinute`	60	Maximum queries allowed per minute (token bucket rate limit)
`EnableFirstResponderKit`	false	Enable First Responder Kit diagnostic tools (sp_Blitz, sp_BlitzFirst, sp_BlitzCache, sp_BlitzIndex, sp_BlitzWho, sp_BlitzLock)
`EnableDarlingData`	false	Enable DarlingData diagnostic tools (sp_PressureDetector, sp_QuickieStore, sp_HealthParser, sp_LogHunter, sp_HumanEventsBlockViewer, sp_IndexCleanup, sp_QueryReproBuilder)
`EnableWhoIsActive`	false	Enable sp_WhoIsActive session monitoring
`EnableDynamicToolsets`	false	Enable progressive tool discovery — DBA tools load on demand via 3 meta-tools instead of at startup. Reduces initial context window usage. The `Enable*` flags still control which toolsets are allowed.
`AzureKeyVaultUri`	—	Azure Key Vault URI (e.g., `https://myvault.vault.azure.net/`). When set, secrets from the vault are added as a configuration source using `DefaultAzureCredential`. Key Vault secret names use `--` as a section separator (e.g., a secret named `SqlAugur--Servers--prod--ConnectionString` maps to `SqlAugur:Servers:prod:ConnectionString`).

Security Note: appsettings.json is gitignored to prevent accidental credential commits. See SECURITY.md for recommended authentication methods including Windows Authentication, Azure Managed Identity, and secure credential storage options.

Tools

The server provides 30 tools organized into toolsets. Six core tools are always available. Additional toolsets are loaded at startup (static mode) or on demand (dynamic mode).

Core Tools

Tool	Description
`list_servers`	Lists available SQL Server instances configured in `appsettings.json`.
`list_databases`	Lists all databases on a named server with names, IDs, states, and creation dates.
`read_data`	Executes a read-only SQL SELECT query. Only `SELECT` and `WITH` (CTE) queries are allowed. Results returned as JSON with a configurable row limit.
`get_query_plan`	Returns the estimated or actual XML execution plan for a SELECT query.
`get_schema_overview`	Concise Markdown schema overview: tables, columns, PKs, FKs, unique/check constraints, defaults. Supports `compact` mode, schema and table filtering.
`describe_table`	Comprehensive table metadata in Markdown: columns, data types, nullability, defaults, identity, computed expressions, indexes, FKs, constraints.

Tool	Description
`list_programmable_objects`	Lists views, stored procedures, functions, and triggers. Filterable by type and schema.
`get_object_definition`	Returns the source definition (CREATE statement) of a programmable object.
`get_extended_properties`	Reads extended properties (descriptions, metadata) on tables, columns, and other objects.
`get_object_dependencies`	Shows what an object references and what references it — upstream and downstream dependency graphs.

Tool	Description
`get_plantuml_diagram`	Generates a PlantUML ER diagram with tables, columns, PKs, and FK relationships. Saves to a `.puml` file. Supports `compact` mode, schema/table filtering, and a configurable table limit (max 200).
`get_mermaid_diagram`	Generates a Mermaid ER diagram with tables, columns, PKs, and FK relationships. Saves to a `.mmd` file. Supports `compact` mode, schema/table filtering, and a configurable table limit (max 200).

DBA Diagnostic Tools

Each toolkit is enabled independently via config flags and requires the corresponding stored procedures installed on the target SQL Server.

All DBA tools apply response size optimisation by default — XML query plan columns are excluded and long string values are truncated to keep responses within AI context window limits. Every tool supports these optional parameters:

Parameter	Description
`verbose`	Return all columns with no truncation.
`includeQueryPlans`	Include XML execution plan columns in the output.
`maxRows`	Maximum rows to return per result set. Available on tools with variable-length output: BlitzIndex, BlitzLock, HealthParser, LogHunter (default 200), IndexCleanup, QueryReproBuilder.

Some tools have additional parameters: includeXmlReports (BlitzLock, HealthParser, HumanEventsBlockViewer), compact (sp_WhoIsActive), verboseMetrics (QuickieStore).

Install from: github.com/BrentOzarULTD/SQL-Server-First-Responder-Kit

Tool	Description
`sp_blitz`	Overall SQL Server health check — prioritized findings for performance, configuration, and security.
`sp_blitz_first`	Real-time performance diagnostics — samples DMVs over an interval for waits, file latency, and perfmon counters.
`sp_blitz_cache`	Plan cache analysis — top queries by CPU, reads, duration, executions, or memory grants.
`sp_blitz_index`	Index analysis — missing, unused, and duplicate indexes with usage patterns.
`sp_blitz_who`	Active query monitor — what's running, blocking info, tempdb usage, query plans.
`sp_blitz_lock`	Deadlock analysis from the `system_health` extended event session.
`sp_blitz_plan_compare`	Cross-server query plan comparison — captures a plan snapshot on one server and compares it to the cached plan on a second server without using linked servers. Requires the demon_hunters branch until merged to main.

Install from: github.com/erikdarling/DarlingData

Tool	Description
`sp_pressure_detector`	Diagnoses CPU and memory pressure — resource bottlenecks, high-CPU queries, memory grants, disk latency.
`sp_quickie_store`	Query Store analysis — top resource-consuming queries, plan regressions, wait statistics.
`sp_health_parser`	Parses the `system_health` extended event session for historical waits, disk latency, CPU, memory, and locking.
`sp_log_hunter`	Searches SQL Server error logs for errors, warnings, and custom messages.
`sp_human_events_block_viewer`	Analyzes blocking events from `sp_HumanEvents` sessions — blocking chains, lock details, waits.
`sp_index_cleanup`	Finds unused and duplicate indexes that are candidates for removal.
`sp_query_repro_builder`	Generates reproduction scripts for Query Store queries with parameter values.

Install from: whoisactive.com

Tool	Description
`sp_whoisactive`	Monitors active sessions and queries — wait info, blocking details, tempdb usage, resource consumption.

Progressive Discovery

When EnableDynamicToolsets is true, only core tools load at startup. Three meta-tools let the AI discover and enable additional toolsets on demand, reducing initial context window usage:

Tool	Description
`list_toolsets`	Lists available toolsets with status (available, enabled, not configured) and tool counts.
`get_toolset_tools`	Returns detailed tool and parameter info for a specific toolset before enabling it.
`enable_toolset`	Enables a toolset, making its tools available. Only works if the admin has enabled the toolset via the corresponding `Enable*` config flag.

Example flow:

AI calls list_toolsets — sees first_responder_kit is "available" (configured but not yet enabled)
AI calls get_toolset_tools("first_responder_kit") — reviews the 6 tools and their parameters
AI calls enable_toolset("first_responder_kit") — the 6 tools are now registered and usable
AI calls sp_blitz — runs the health check as normal

In static mode (EnableDynamicToolsets: false), all enabled toolsets load at startup and the discovery tools are not registered. Schema Exploration and Diagrams toolsets are always loaded regardless of mode.

Known limitation: Progressive discovery relies on the MCP notifications/tools/list_changed notification to inform clients that new tools have been registered. Claude Code does not currently handle this notification (anthropics/claude-code#4118), so dynamically enabled toolsets will not appear. Use static mode (EnableDynamicToolsets: false) when using Claude Code.

Security

Query Validation

Every query is parsed into an Abstract Syntax Tree (AST) using Microsoft's official TSql180Parser and must pass these rules:

Single statement only — multiple statements are rejected
SELECT only — INSERT, UPDATE, DELETE, DROP, EXEC, CREATE, ALTER, and all other statement types are blocked
No SELECT INTO — prevents table creation via SELECT
No external data access — OPENROWSET (all variants including BULK, Cosmos DB, and internal), OPENQUERY, OPENDATASOURCE, OPENXML blocked
No linked servers — four-part name references are rejected
No MAXRECURSION hint — prevents overriding the default recursion limit
Cross-database queries are allowed — three-part names work by design; the security boundary is the server, not the database. To restrict to a single database, limit the login's permissions.

Because validation operates on the parsed AST, it correctly handles edge cases that defeat string-based approaches: keywords inside comments, string literals, nested block comments, and encoding tricks.

Parameter Blocking

Diagnostic stored procedures execute via whitelisted procedure names with blocked parameters that prevent writes:

First Responder Kit — all @Output* parameters blocked (prevents writing results to server tables)
DarlingData — logging and output parameters blocked (prevents table creation and data retention)
sp_WhoIsActive — @destination_table, @return_schema, @schema, @help blocked

Rate Limiting

All tool executions are subject to concurrency limiting (MaxConcurrentQueries, default 5) and throughput limiting (MaxQueriesPerMinute, default 60). Excess requests are rejected with a retry message.

Connection Security

Use Windows Authentication or Azure Managed Identity where possible to avoid storing credentials in config files. When SQL Authentication is required, use environment variable overrides to inject credentials at runtime. See SECURITY.md for detailed guidance including credential stores and connection string encryption.

Known Risks

This project depends on the official Microsoft MCP C# SDK (ModelContextProtocol NuGet package, version 1.2.0). As the MCP framework handles all protocol I/O, any vulnerability in it directly affects this application's security boundary. Monitor the package for updates and upgrade when new versions are released.
The data returned from a SQL Server query could include malicious prompt injection targeting AIs. This is a risk of all AI use and cannot be mitigated by this project. Ensure you're following best practices for AI security and only connecting to trusted data sources.

Contributing

Contributions are welcome. See CONTRIBUTING.md for architecture details, development setup, testing instructions, and guidelines for adding new tools.

License

MIT

Available Tools

12 tools

describe_tableDescribe Table StructureA

Read-onlyIdempotent

Get comprehensive metadata about a single table including columns, data types, indexes, primary key, foreign keys, check constraints, and default constraints.

ParametersJSON Schema

Name	Required	Description	Default
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)
`databaseName`	Yes	Name of the database to query (use list_databases to see available databases)
`tableName`	Yes	Name of the table to describe
`schemaName`	No	Schema name (default 'dbo')	dbo

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so safety is clear. The description adds useful detail on the metadata returned (indexes, foreign keys, etc.), which goes beyond annotations and helps the agent understand the scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence of 23 words, front-loaded with the core action and resource, no wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters, high schema coverage, and no output schema, the description adequately lists the metadata types returned and mentions prerequisite tools. It is complete enough for an AI agent to understand the tool's purpose and usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers 100% of parameters with descriptions, including tips to use sibling tools for server/database names. The tool description does not add further meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states 'Get comprehensive metadata about a single table' and lists specific elements (columns, data types, indexes, etc.), distinguishing it from siblings like get_schema_overview or read_data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Does not explicitly state when to use versus alternatives like get_schema_overview or get_mermaid_diagram. It hints at prerequisites by referencing list_servers and list_databases, but lacks clear usage context for an AI agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_extended_propertiesGet Extended PropertiesA

Read-onlyIdempotent

Read extended properties (descriptions, metadata) from tables and columns. Returns JSON with schema, table, column, property name, and value.

ParametersJSON Schema

Name	Required	Description
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`schemaName`	No	Optional schema name filter
`tableName`	No	Optional table name filter
`columnName`	No	Optional column name filter

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds that it returns JSON with specific fields, but does not disclose further behavioral details (e.g., permissions, error behavior).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no redundancy. The action and output are stated upfront.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read tool with good annotations and schema, the description covers the core purpose and output. Some missing context like error handling or typical use, but adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so parameters are well-documented. The description adds no additional meaning beyond the schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it reads extended properties from tables and columns, specifying the output fields. This distinguishes it from siblings like describe_table or get_object_definition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs. alternatives. The description implies usage for retrieving metadata, but does not mention exclusions or when to prefer other tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_mermaid_diagramGet Mermaid ER DiagramA

Generate a Mermaid ER diagram saved to a file. Shows tables, columns, PKs, and FK relationships with smart cardinality.

ParametersJSON Schema

Name	Required	Description
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`outputPath`	Yes	File path for output (e.g. '/tmp/diagram.mmd')
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
`includeTables`	No	Optional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
`excludeTables`	No	Optional comma-separated tables to exclude. Ignored if includeTables set.
`maxTables`	No	Max tables to include (1-200, default 50)
`compact`	No	true/false. Show only PK/FK columns without non-key columns

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations indicate readOnlyHint=false and idempotentHint=false, which aligns with the description's mention of saving a file (write operation). However, the description adds no further behavioral details, such as overwrite behavior or prerequisites.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is concise, front-loaded, and contains no unnecessary words. It efficiently conveys the core functionality.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (9 parameters, no output schema), the description is adequate but not comprehensive. It lacks details about the output format, error conditions, or behavior with omitted parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema fully documents all 9 parameters with descriptions. The tool's description does not add any additional semantics beyond what is already in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool generates a Mermaid ER diagram, saves it to a file, and shows tables, columns, PKs, and FK relationships. It clearly distinguishes from sibling tools like get_plantuml_diagram.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

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 (e.g., PlantUML diagram). The description implies its purpose but does not provide usage context or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_object_definitionGet Object DefinitionA

Read-onlyIdempotent

Get the T-SQL source code of a stored procedure, function, view, or trigger. Returns Markdown with the object type and definition.

ParametersJSON Schema

Name	Required	Description	Default
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`objectName`	Yes	Object name (e.g. 'usp_GetOrders')
`schemaName`	No	Schema name (default 'dbo')	dbo

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, destructiveHint, and idempotentHint. The description adds that output is Markdown with object type and definition, but does not disclose other behaviors like error handling, permission requirements, or performance impact.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no unnecessary words. Efficiently conveys purpose and output format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With all parameters documented and no output schema needed, the description sufficiently describes the return format (Markdown with object type and definition). Could mention error cases like missing object, but overall adequate for a simple retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for each parameter (e.g., serverName from list_servers, objectName with example). The description does not add additional meaning beyond what the schema provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves T-SQL source code for specific object types (stored procedure, function, view, trigger) and returns Markdown with object type and definition, distinguishing it from sibling tools like describe_table or get_query_plan.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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. The description implies it is for retrieving source code, but does not mention scenarios where it should not be used or suggest alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_object_dependenciesGet Object DependenciesA

Read-onlyIdempotent

Show what a database object references and what references it. Returns JSON with 'references' and 'referencedBy' arrays for dependency analysis.

ParametersJSON Schema

Name	Required	Description	Default
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`objectName`	Yes	Object name (e.g. 'vw_ActiveProducts')
`schemaName`	No	Schema name (default 'dbo')	dbo

TDQS

A4.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds value by specifying the output format ('references' and 'referencedBy' arrays), going beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loads the action, and provides key output details. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (dependency analysis), the input schema is fully described, and the output is explained. Sibling tools provide context, and no missing information is critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each parameter has a description. The tool description adds no extra meaning beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Show what...references') and clearly identifies the resource (database object dependencies). It distinguishes from siblings like get_object_definition and describe_table by focusing on dependencies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for dependency analysis but does not explicitly state when to use this tool vs alternatives like get_object_definition. No exclusions or contexts are provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_plantuml_diagramGet Database ER DiagramA

Generate a PlantUML ER diagram saved to a file. Shows tables, columns, PKs, and FK relationships with smart cardinality.

ParametersJSON Schema

Name	Required	Description
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`outputPath`	Yes	File path for output (e.g. '/tmp/diagram.puml')
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
`includeTables`	No	Optional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
`excludeTables`	No	Optional comma-separated tables to exclude. Ignored if includeTables set.
`maxTables`	No	Max tables to include (1-200, default 50)
`compact`	No	true/false. Show only PK/FK columns without data types

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Discloses file-saving side effect, consistent with readOnlyHint=false. Does not elaborate on overwrite behavior, permissions, or other traits beyond what annotations already indicate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences packed with essential purpose and content. No wasted words. Front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Reasonably complete for a diagram generation tool with no output schema. Could clarify that no result content is returned beyond file write. Otherwise covers key behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

All 9 parameters have descriptions in schema (100% coverage), so description adds no new parameter meaning beyond the schema. Baseline score applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it generates a PlantUML ER diagram and saves to file, mentioning key content (tables, columns, PKs, FK relationships). Distinguishes from sibling get_mermaid_diagram and describe_table.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use vs. alternatives like get_mermaid_diagram. Implies usage for ER diagram generation but lacks when-not-to-use or selection criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_query_planGet Query Execution PlanA

Read-onlyIdempotent

Get the estimated or actual XML execution plan for a SELECT query. Estimated plans show the optimizer's plan without executing. Actual plans execute the query and include runtime statistics. Uses the same query validation as read_data (SELECT only).

ParametersJSON Schema

Name	Required	Description	Default
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)
`query`	Yes	SQL SELECT query to get the execution plan for. Only SELECT and WITH (CTE) queries are permitted.
`databaseName`	Yes	Name of the database to query (use list_databases to see available databases)
`outputPath`	Yes	File path for output (e.g. '/tmp/plan.sqlplan')
`planType`	No	Plan type: 'estimated' (default, does not execute) or 'actual' (executes the query)	estimated

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds specifics beyond annotations: estimated plans don't execute, actual plans execute with runtime stats, and validation restricts to SELECT. No contradiction with readOnlyHint and idempotentHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the core purpose and efficiently cover key details without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but description omits return value or success indication after saving to outputPath. Adequate but not fully complete for an agent's invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

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 value by clarifying planType behavior and default, which enhances understanding beyond schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves estimated or actual XML execution plans for SELECT queries, distinguishing between plan types and stating it uses same validation as read_data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides context for when to use each plan type and validation constraint, but lacks explicit exclusion of alternatives or when-not-to-use scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_schema_overviewGet Database Schema OverviewA

Read-onlyIdempotent

Markdown overview of database schema: tables, columns, types, PKs, FKs, unique/check constraints, defaults. Use get_plantuml_diagram for visual ER output or describe_table for single-table detail.

ParametersJSON Schema

Name	Required	Description
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
`includeTables`	No	Optional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
`excludeTables`	No	Optional comma-separated tables to exclude. Ignored if includeTables set.
`maxTables`	No	Max tables to include (1-200, default 50)
`compact`	No	true/false. Show only PK/FK columns without data types

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint and idempotentHint. The description adds that the output is a Markdown overview including constraints and defaults, which is consistent and provides further behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no wasted words. The critical information (output format, content, alternatives) is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter tool with full schema coverage and no output schema, the description covers the essential purpose and alternatives well. However, it could briefly note that filtering parameters allow narrowing the overview, but that is implicitly clear from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The description does not reiterate parameter meanings but adds high-level context about what the tool returns. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Markdown overview of database schema' with specific details (tables, columns, types, PKs, FKs, etc.). It also distinguishes from siblings by recommending get_plantuml_diagram for visual ER and describe_table for single-table detail.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly provides when-to-use guidance: 'Use get_plantuml_diagram for visual ER output or describe_table for single-table detail.' This helps the agent choose correctly among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_databasesList Databases on SQL ServerA

Read-onlyIdempotent

List all databases on a named SQL Server instance. Returns database names, IDs, states, and creation dates. Use list_servers first to discover available server names.

ParametersJSON Schema

Name	Required	Description	Default
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only and idempotent. Description adds return field details and prerequisite, complementing annotations without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with action and purpose, no redundant words. Highly efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with one parameter, description covers return fields, prerequisite, and action. No output schema but return info is stated. Sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description. Description adds use-case context (list_servers prerequisite) but not much beyond schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Describes specific verb 'List' and resource 'databases on SQL Server', lists return fields, and distinguishes from sibling by mentioning prerequisite 'list_servers'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states to use list_servers first to discover server names, providing clear guidance on when to use this tool. No need for exclusions given simplicity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_programmable_objectsList Programmable ObjectsA

Read-onlyIdempotent

List stored procedures, functions, views, and triggers in a database. Returns JSON with schema, name, type, and create/modify dates.

ParametersJSON Schema

Name	Required	Description
`serverName`	Yes	Server name from list_servers
`databaseName`	Yes	Database name from list_databases
`includeSchemas`	No	Optional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
`excludeSchemas`	No	Optional comma-separated schemas to exclude (e.g. 'sys,INFORMATION_SCHEMA'). Ignored if includeSchemas set.
`objectTypes`	No	Optional comma-separated object types to filter: PROCEDURE, FUNCTION, VIEW, TRIGGER

TDQS

A4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that the output is JSON with schema, name, type, and dates, providing context beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence with no wasted words, front-loading the purpose and output format.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description covers return structure adequately. It lacks minor context like behavior when no objects found, but is sufficient for use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add meaning beyond what the schema already provides for each parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists stored procedures, functions, views, and triggers in a database, specifying the exact resource and action. This distinguishes it from sibling tools like get_object_definition or describe_table.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for listing programmable objects but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_serversList SQL ServersA

Read-onlyIdempotent

List the available SQL Server instances that can be queried. Call this first to discover server names before using read_data.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, so the description adds no extra behavioral details. It confirms the read-only nature but nothing beyond that.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no wasted words. Front-loaded with key action and purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only tool with no output schema, the description covers what's needed: what it does (list servers) and when to use it (first).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters in schema, so description doesn't need to add any. Rule: 0 params = baseline 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it lists available SQL Server instances and positions itself as the first call for discovery. It distinguishes from sibling tools by specifying this is the initial step before using read_data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call this first before read_data, providing clear usage context. Does not mention when not to use or alternatives, but the directive is sufficient for this simple tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

read_dataRead Data from SQL ServerA

Read-onlyIdempotent

Execute a read-only SQL SELECT query against a named SQL Server instance. Only SELECT and WITH (CTE) queries are allowed. Use list_servers first to discover available server names.

ParametersJSON Schema

Name	Required	Description
`serverName`	Yes	Name of the SQL Server to query (use list_servers to see available names)
`query`	Yes	SQL SELECT query to execute. Only SELECT and WITH (CTE) queries are permitted.
`databaseName`	Yes	Name of the database to query (use list_databases to see available databases)

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, indicating safety. The description reinforces that only read-only queries are allowed, adding clarity beyond annotations. It does not contradict annotations, and the restriction on query types enhances transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise: two sentences that front-load the purpose and then provide usage guidance. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the read-only nature and absence of output schema, the description adequately covers the main concerns: what query types are allowed and how to identify the server. However, it could mention the return format (result set) or error behavior to be fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema covers all parameters with descriptions, achieving 100% coverage. The description adds that serverName should be discovered via list_servers and repeats the query type restriction, but does not provide significant new meaning beyond what schema already offers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool executes a read-only SQL SELECT query against a named SQL Server instance, specifying allowed query types (SELECT and WITH). It distinguishes itself from siblings by focusing on arbitrary query execution, while siblings like describe_table or list_databases serve specific schema or listing roles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises using list_servers first to discover server names, providing a prerequisite. It restricts queries to SELECT and WITH (CTE), preventing write operations. However, it lacks explicit guidance on when to prefer this tool over siblings like describe_table for schema exploration.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv1.4.0May 7, 2026
- Changedget_extended_properties3 fields changed
  - changedInput schema / properties / columnName / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / schemaName / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / tableName / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedget_mermaid_diagram4 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / excludeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedget_plantuml_diagram4 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / excludeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedget_schema_overview4 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / excludeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeTables / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
- Changedlist_programmable_objects3 fields changed
  - changedInput schema / properties / excludeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / includeSchemas / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
  - changedInput schema / properties / objectTypes / type
```
Previous value: -"string"New value: +[
+  "string",
+  "null"
+]
```
12 tool updatesv1.3.1Feb 20, 2026
- First observeddescribe_table
- First observedget_extended_properties
- First observedget_mermaid_diagram
- First observedget_object_definition
- First observedget_object_dependencies
- First observedget_plantuml_diagram
- First observedget_query_plan
- First observedget_schema_overview
- First observedlist_databases
- First observedlist_programmable_objects
- First observedlist_servers
- First observedread_data

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct operation: describing tables, reading data, listing servers/databases, getting definitions/dependencies/diagrams. The only overlap is between get_mermaid_diagram and get_plantuml_diagram, but these are clearly differentiated by output format, so no ambiguity.

Naming Consistency4/5

Tools use a mix of get_, list_, describe_, and read_ prefixes. While each group is internally consistent, the overall pattern is not uniform. However, the naming is still predictable and readable.

Tool Count5/5

With 12 tools, the server covers all essential database exploration tasks without being bloated. Each tool serves a clear purpose, and the count feels appropriate for the scope.

Completeness4/5

The tool set covers schema discovery, object details, dependencies, diagrams, query plans, and read-only data access. Missing a dedicated 'list_tables' tool, but get_schema_overview provides table information. Overall very comprehensive for a read-only database exploration tool.

Maintenance

ActivityStale

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

dataOAuth
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
classquill-mcp
io.github.EquateItAu
Read-only MCP server for ClassQuill, a tutoring-business-management platform.
Education & Learning Tools CRM
2
sixta-connect AOAuth
ai.sixta
DBRE-grade SQL analysis inside any MCP client. No connection. No install. Paste a query.
Databases Code Analysis
2
The Quiet Protocol Growth Offense MCP A
com.thequietprotocol.www
Read-only MCP server for The Quiet Protocol's engines, benchmarks, proof, and business data.
Databases Research & Data Finance
292

Related MCP Servers

sql-explorer-mcp
Databases Search
govern-agents
A
license
Not graded
quality
F
maintenance
Read-only MCP server for SQL databases (SQL Server, Postgres, SQLite) with multi-server support and three-layer safety using AST validation and linting.
Updated a month ago (2026-07-29 13:07 UTC)
MIT
mcp-sqlserver-readonly
Databases Developer Tools
gbfeliped
A
license
Not graded
quality
C
maintenance
Read-only SQL Server MCP server enabling safe database queries, table listing, and schema inspection with built-in security protections.
Updated 3 months ago (2026-06-18 13:49 UTC)
MIT
MSSQL MCP Python Server
Databases Observability
lorenzouriel
A
license
Not graded
quality
A
maintenance
MCP server for safely exposing SQL Server database capabilities to LLM clients, with read-only mode, security features, and observability.
Updated 25 days ago (2026-08-12 13:49 UTC)
28
MIT
MSSQL-MCP
Databases Search
esasiyun17
A
license
Not graded
quality
A
maintenance
Security-first, read-only MCP server for Microsoft SQL Server, enabling safe natural-language querying of databases.
Updated 2 months ago (2026-07-06 17:04 UTC)
15
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mbentham/SqlAugur'

If you have feedback or need assistance with the MCP directory API, please join our Discord server