Skip to main content
Glama
deenesjakoruzh
mbentham

SqlAugur

by mbentham
OverviewSchemaRelated ServersScoreDiscussions
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

Use this order for all install methods:

  1. Install SqlAugur

  2. Save appsettings.json in the correct location

  3. Add SqlAugur to your MCP client config

  4. Verify by asking your assistant to call list_servers

Start with Installation for exact commands and file paths.

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 31 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. Follow this order: install, save config, wire client, verify.

NuGet Global Tool (recommended)

1. Install (prerequisite: .NET 10.0 runtime)

dotnet tool install -g SqlAugur

2. Save config 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

Example appsettings.json to save at that location:

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

3. Add to MCP client

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

To update: dotnet tool update -g SqlAugur

Docker / Podman

1. Run SqlAugur container

# 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.

If you mount a config file, save it as /path/to/appsettings.json and mount it to /app/appsettings.json.

2. Add to MCP client

{
  "mcpServers": {
    "sqlaugur": {
      "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": {
    "sqlaugur": {
      "command": "docker",
      "args": ["compose", "run", "-i", "--rm", "sqlaugur"]
    }
  }
}

Build from Source

1. Build (prerequisite: .NET 10.0 SDK)

git clone git@github.com:mbentham/SqlAugur.git
cd SqlAugur
dotnet publish SqlAugur -c Release -o SqlAugur/publish

2. Save config file

# Linux/macOS
cp SqlAugur/appsettings.example.json SqlAugur/publish/appsettings.json
# Edit SqlAugur/publish/appsettings.json with your server connections

# Windows (PowerShell)
Copy-Item SqlAugur\appsettings.example.json SqlAugur\publish\appsettings.json
# Edit SqlAugur\publish\appsettings.json with your server connections

3. Add to MCP client

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

Verify the MCP connection (LLM-first)

After restarting your MCP client, ask the assistant:

  • Call list_servers

  • Call list_databases for server "production"

Expected result:

  • list_servers returns your configured server name (for example production)

  • list_databases returns a JSON array of databases, not a connection or authentication error

If verification fails:

  1. Confirm MCP config runs the expected command (sqlaugur, docker run ..., or dotnet /path/to/SqlAugur.dll)

  2. Confirm appsettings.json is saved where your install method expects it:

    • Local tool: ~/.config/sqlaugur/appsettings.json (Linux/macOS) or %APPDATA%\sqlaugur\appsettings.json (Windows)

    • Container: mounted to /app/appsettings.json

    • Source build: next to the published DLL (SqlAugur/publish/appsettings.json)

  3. Confirm the tool call uses a configured server key (for example production)

  4. Confirm SQL connectivity and authentication in the connection string

Configuration

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

  1. Command-line arguments

  2. Environment variables — using __ as section delimiter (e.g., SqlAugur__Servers__production__ConnectionString=...)

  3. Current working directory — appsettings.json in the directory you run the command from

  4. User config directory — ~/.config/sqlaugur/appsettings.json on Linux, %APPDATA%\sqlaugur\appsettings.json on Windows

  5. Azure Key Vault — when AzureKeyVaultUri is set (see below)

  6. 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, sp_BlitzPlanCompare)

EnableDarlingData

false

Enable DarlingData diagnostic tools (sp_PressureDetector, sp_QuickieStore, sp_QuickieCache, 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 31 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_quickie_cache

Plan cache analysis — high-impact queries ranked by impact score over the dm_exec_*_stats DMVs (the plan-cache companion to sp_quickie_store).

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:

  1. AI calls list_toolsets — sees first_responder_kit is "available" (configured but not yet enabled)

  2. AI calls get_toolset_tools("first_responder_kit") — reviews the 7 tools and their parameters

  3. AI calls enable_toolset("first_responder_kit") — the 7 tools are now registered and usable

  4. 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.3.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
NameRequiredDescriptionDefault
serverNameYesName of the SQL Server to query (use list_servers to see available names)
databaseNameYesName of the database to query (use list_databases to see available databases)
tableNameYesName of the table to describe
schemaNameNoSchema 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
NameRequiredDescriptionDefault
serverNameYesServer name from list_servers
databaseNameYesDatabase name from list_databases
schemaNameNoOptional schema name filter
tableNameNoOptional table name filter
columnNameNoOptional 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
NameRequiredDescriptionDefault
serverNameYesServer name from list_servers
databaseNameYesDatabase name from list_databases
outputPathYesFile path for output (e.g. '/tmp/diagram.mmd')
includeSchemasNoOptional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
excludeSchemasNoOptional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
includeTablesNoOptional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
excludeTablesNoOptional comma-separated tables to exclude. Ignored if includeTables set.
maxTablesNoMax tables to include (1-200, default 50)
compactNotrue/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
NameRequiredDescriptionDefault
serverNameYesServer name from list_servers
databaseNameYesDatabase name from list_databases
objectNameYesObject name (e.g. 'usp_GetOrders')
schemaNameNoSchema 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
NameRequiredDescriptionDefault
serverNameYesServer name from list_servers
databaseNameYesDatabase name from list_databases
objectNameYesObject name (e.g. 'vw_ActiveProducts')
schemaNameNoSchema 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
NameRequiredDescriptionDefault
serverNameYesServer name from list_servers
databaseNameYesDatabase name from list_databases
outputPathYesFile path for output (e.g. '/tmp/diagram.puml')
includeSchemasNoOptional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
excludeSchemasNoOptional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
includeTablesNoOptional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
excludeTablesNoOptional comma-separated tables to exclude. Ignored if includeTables set.
maxTablesNoMax tables to include (1-200, default 50)
compactNotrue/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
NameRequiredDescriptionDefault
serverNameYesName of the SQL Server to query (use list_servers to see available names)
queryYesSQL SELECT query to get the execution plan for. Only SELECT and WITH (CTE) queries are permitted.
databaseNameYesName of the database to query (use list_databases to see available databases)
outputPathYesFile path for output (e.g. '/tmp/plan.sqlplan')
planTypeNoPlan 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
NameRequiredDescriptionDefault
serverNameYesServer name from list_servers
databaseNameYesDatabase name from list_databases
includeSchemasNoOptional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
excludeSchemasNoOptional comma-separated schemas to exclude (e.g. 'audit,staging'). Ignored if includeSchemas set.
includeTablesNoOptional comma-separated tables to include (e.g. 'Users,Orders'). Overrides excludeTables.
excludeTablesNoOptional comma-separated tables to exclude. Ignored if includeTables set.
maxTablesNoMax tables to include (1-200, default 50)
compactNotrue/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
NameRequiredDescriptionDefault
serverNameYesName 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
NameRequiredDescriptionDefault
serverNameYesServer name from list_servers
databaseNameYesDatabase name from list_databases
includeSchemasNoOptional comma-separated schemas to include (e.g. 'dbo,sales'). Overrides excludeSchemas.
excludeSchemasNoOptional comma-separated schemas to exclude (e.g. 'sys,INFORMATION_SCHEMA'). Ignored if includeSchemas set.
objectTypesNoOptional 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
NameRequiredDescriptionDefault

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
NameRequiredDescriptionDefault
serverNameYesName of the SQL Server to query (use list_servers to see available names)
queryYesSQL SELECT query to execute. Only SELECT and WITH (CTE) queries are permitted.
databaseNameYesName 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.

  1. 5 tool updatesv1.4.0
    • 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"
+]
  2. 12 tool updatesv1.3.1
    • 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

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Related MCP Servers

  • sql-explorer-mcp

    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.
    MIT

  • mcp-sqlserver-readonly

    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.
    MIT

  • MSSQL-MCP

    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.
    15
    MIT

Latest Blog Posts

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