Supports planning modernization of legacy Classic ASP applications to Angular architectures by providing comprehensive schema analysis and stored procedure business logic extraction from SQL Server databases.
Supports planning modernization of legacy Classic ASP applications to .NET architectures by providing comprehensive schema analysis and stored procedure business logic extraction from SQL Server databases.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MSSQL MCP Server Show me all tables in the dbo schema"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
📦 Install: npm install && npm run build
⚙️ Configure: Set up individual environment variables (see configuration below)
🔗 Connect: Tools automatically use your configured connections
🔍 Explore: Use natural language to query and explore your databases conversationally
📄 Extract: Get complete stored procedure SQL code for business logic analysis
🏗️ Modernize: Use comprehensive schema tools to plan application modernization. This comprehensive Model Context Protocol (MCP) server for Microsoft SQL Server database analysis and modernization provides extensive capabilities for exploring and transforming your database schema. For complete configuration details, file locations, and troubleshooting, see the Configuration Guide.
With multiple connections configured, you can switch between databases naturally: This comprehensive server provides extensive tools for analyzing Classic ASP applications, exploring database schemas, and planning modernization to .NET/Angular architectures.
Built using the tedious library for pure JavaScript SQL Server connectivity with support for Windows Authentication (NTLM).
🆕 Latest Update: Enhanced stored procedure tools now provide complete SQL source code access for comprehensive business logic analysis and modernization planning.
Related MCP server: SQL Server MCP
NTLM Pass-Through Authentication Requirement: When connecting to SQL Server using Windows Authentication (Integrated Security=SSPI), the MSSQL MCP server must provide explicit domain credentials because:
No Interactive Session: MCP servers run as background processes without access to the current user's Windows session
NTLM Protocol: Windows Authentication requires explicit username, password, and domain to establish the NTLM handshake
Security Context: The tedious library needs these credentials to impersonate the domain user for database access
Cross-Process Authentication: Unlike applications running in the user's context, MCP servers need explicit credential delegation
Environment variables are the secure, standard way to provide these credentials without hard-coding them in configuration files.
🔌 test_connection - Test database connectivity and get server information
📋 list_connections - List all available named database connections
📚 list_databases - List all available databases on the SQL Server instance
📊 list_tables - List all tables in a specific schema (default: dbo)
📝 describe_table - Get detailed schema information including columns, data types, and constraints
🎯 sample_data - Retrieve sample data from a table (default: 10 rows, max: 100)
💻 execute_query - Execute custom SELECT queries (disabled by default; set MSSQL_ENABLE_EXECUTE_QUERY=true to enable)
🔗 get_relationships - Get foreign key relationships between tables
📋 list_stored_procedures - List and analyze stored procedures with parameters and definitions
🔍 describe_stored_procedure - Get procedure parameters and definition
📋 list_views - Analyze views, their definitions, and dependencies
🔍 describe_view - Get view definition and dependencies
⚡ list_triggers - Identify triggers and their business logic
🔍 describe_trigger - Extract trigger logic and events
🔧 list_functions - List user-defined functions by type (scalar, table-valued, etc.)
📊 list_indexes - Comprehensive index usage statistics and recommendations
🎯 find_missing_indexes - Identify potentially missing indexes based on query patterns
📈 analyze_table_stats - Analyze table sizes, row counts, and space usage
💾 analyze_database_size - Complete database storage analysis
🔍 analyze_index_usage - Identify unused and underutilized indexes
📋 list_constraints - List all constraints (check, unique, foreign key, etc.)
✅ analyze_check_constraints - Extract business rules from check constraints
🔧 list_default_constraints - Analyze default value patterns
📝 list_user_defined_types - Catalog custom data types
🧮 find_computed_columns - Identify calculated fields and business logic
📈 analyze_data_distribution - Analyze data patterns and quality
🔍 find_lookup_tables - Automatically identify reference/lookup tables
❓ analyze_null_patterns - Find columns with high null percentages
🔍 detect_audit_columns - Identify audit columns and tracking patterns
📄 get_stored_procedure_definition - Get complete SQL source code of a single stored procedure
📚 get_multiple_stored_procedure_definitions - Get SQL definitions for multiple procedures at once
📦 get_all_stored_procedure_definitions - Get complete SQL definitions for all procedures in a schema
🔍 search_stored_procedures_by_content - Search procedures by text patterns in their SQL definitions
All tools accept an optional connectionName parameter to switch between different databases conversationally.
🎯 Individual Environment Variables: Cleanest configuration approach - no JSON strings needed
🔄 Multi-Database Support: Switch between different databases conversationally
🔐 Windows Authentication Support: Full NTLM authentication with domain credentials
🏗️ Deep Schema Analysis: Comprehensive database object exploration including stored procedures, views, triggers
📄 Complete SQL Code Access: Extract full source code from stored procedures for analysis and modernization
⚡ Performance Tools: Index analysis, missing index detection, table statistics
🔒 Business Logic Extraction: Extract business rules from constraints, computed columns, and database objects
📊 Data Pattern Analysis: Identify lookup tables, audit columns, and data quality patterns
🔍 Legacy System Analysis: Specialized tools for Classic ASP to modern stack migration planning
📊 Data Sampling: Safe data retrieval with configurable limits
🛡️ Read-Only Security: Built-in query validation and safety restrictions
🔄 Connection Pooling: Efficient connection reuse using tedious
🎛️ Multiple Config Formats: Support for various configuration approaches
npm install
npm run buildNote: The .env file is for local testing/development only. For production use, configure your MCP client directly with environment variables.
Copy the example environment file:
cp .env.example .envUpdate .env with your credentials:
# Windows Authentication credentials for NTLM
MSSQL_USERNAME=your-domain-username
MSSQL_PASSWORD=your-secure-password
MSSQL_DOMAIN=your-domain
# Default connection string for your database
MSSQL_CONNECTION_STRING=Data Source=your-server; Initial Catalog=your-database; Integrated Security=SSPI; TrustServerCertificate=False;Security Note: The .env file is automatically ignored by Git to prevent committing credentials.
The cleanest, most professional approach using individual environment variables (no JSON strings required):
{
"servers": {
"mssql-mcp": {
"type": "stdio",
"command": "npx",
"args": ["mssql-mcp-server"],
"env": {
// Windows credentials (individual variables - cleanest)
"WINDOWS_USERNAME": "your-domain-username",
"WINDOWS_PASSWORD": "your-secure-password",
"WINDOWS_DOMAIN": "YOUR-DOMAIN",
// Optional default connection
"MSSQL_CONNECTION_STRING": "Data Source=main-server; Initial Catalog=MainDB; Integrated Security=SSPI; TrustServerCertificate=False;",
// Multiple database connections (individual variables)
"CONNECTION_CRM": "Data Source=crm-server; Initial Catalog=CRM_Database; Integrated Security=SSPI; TrustServerCertificate=False;",
"CONNECTION_ERP": "Data Source=erp-server; Initial Catalog=ERP_System; Integrated Security=SSPI; TrustServerCertificate=False;",
"CONNECTION_ANALYTICS": "Data Source=analytics-server; Initial Catalog=DataWarehouse; Integrated Security=SSPI; TrustServerCertificate=False;",
"CONNECTION_HR": "Data Source=hr-server; Initial Catalog=HumanResources; Integrated Security=SSPI; TrustServerCertificate=False;"
}
}
}
}When using CONNECTION_* variables, connection names are automatically generated:
Environment Variable | Connection Name (for tools) |
|
|
|
|
|
|
|
|
Usage in conversational queries:
"Show me tables in the CRM database" → uses crm connection
"What's in the analytics warehouse?" → uses analytics connection
"Query the HR system for employee data" → uses hr_system connection
The server supports multiple configuration approaches for backward compatibility:
JSON String Variables: windows_credentials, connections
Legacy Variables: MSSQL_WINDOWS_CREDENTIALS, MSSQL_CONNECTIONS
Individual Legacy: MSSQL_USERNAME, MSSQL_PASSWORD, MSSQL_DOMAIN
For complete configuration details, file locations, and troubleshooting, see the Configuration Guide.
Location: %APPDATA%\Claude\claude_desktop_config.json (Windows)
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Linux: ~/.config/claude/claude_desktop_config.json
Scope: Available in ALL Claude Desktop conversations
Use Case: Personal development setup, local databases
Note: Claude Desktop only supports global configuration (no project-level config)
Location: User Settings JSON
Windows: %APPDATA%\Code\User\settings.json
macOS: ~/Library/Application Support/Code/User/settings.json
Linux: ~/.config/Code/User/settings.json
Access: Ctrl+Shift+P → "Preferences: Open User Settings (JSON)"
Scope: ALL VS Code workspaces
Use Case: Consistent development environment across all projects
Location: .vscode/settings.json in workspace root
Scope: Specific workspace only
Use Case: Workspace-specific database connections
Location: .vscode/mcp.json in project root
Scope: Specific project/repository only
Use Case: Project-specific databases, team collaboration, version control
Location: %APPDATA%\Cursor\User\settings.json (Windows)
macOS: ~/Library/Application Support/Cursor/User/settings.json
Linux: ~/.config/Cursor/User/settings.json
Scope: ALL Cursor workspaces
Location: .vscode/settings.json or .vscode/mcp.json in project root
Scope: Specific workspace/project (Cursor uses VS Code format)
Location: Windows System Environment Variables
Use Case: System-wide credentials and connections
Note: VS Professional doesn't have native MCP support yet
Location: .vs/mcp.json or similar (extension-dependent)
Status: Depends on MCP extension implementation
Override Order (highest to lowest priority):
Project/Repository Level: .vscode/mcp.json
Workspace Level: .vscode/settings.json
User/Global Level: User/settings.json or Claude config
System Level: Windows Environment Variables
Example: If you have WINDOWS_USERNAME set both globally and in a project config, the project value will be used for that specific project.
Global credentials: Set Windows authentication in system environment variables
Global default connection: Configure in Claude Desktop global config or VS Code user settings
Project connections: Use .vscode/mcp.json for project-specific databases
Shared setup: Document configuration in project README
Version control: Include .vscode/mcp.json in repository for team consistency
Security: Never commit actual passwords - use environment variable references
Personal projects: Global configuration in Claude Desktop or VS Code user settings
Team projects: Project-level .vscode/mcp.json with environment variable references
Enterprise: Combination of system environment variables + project-specific configs
🔐 Windows Authentication (Recommended):
Data Source=ServerName; Initial Catalog=DatabaseName; Integrated Security=SSPI; TrustServerCertificate=False;🔑 SQL Server Authentication:
Server=localhost,1433;Database=AdventureWorks;User Id=sa;Password=YourPassword123!;Encrypt=true;TrustServerCertificate=false;☁️ Azure SQL Database:
Server=your-server.database.windows.net;Database=your-database;User Id=your-username;Password=your-password;Encrypt=true;🏷️ Named Instance:
Server=localhost\\SQLEXPRESS;Database=TestDB;Integrated Security=true;TrustServerCertificate=false;🎯 Individual Variables (Recommended - Cleanest):
WINDOWS_USERNAME: Windows domain username
WINDOWS_PASSWORD: Windows domain password
WINDOWS_DOMAIN: Windows domain name
CONNECTION_*: Individual connection strings (e.g., CONNECTION_CRM, CONNECTION_ANALYTICS)
MSSQL_CONNECTION_STRING: Optional default connection string
Connection Mapping: CONNECTION_CRM → crm, CONNECTION_HR_SYSTEM → hr_system
💡 Technical Note: Windows Authentication Requirements
The Windows credentials (WINDOWS_USERNAME, WINDOWS_PASSWORD, WINDOWS_DOMAIN) are required for Windows Authentication because:
MCP Service Context: The server runs as a background process without access to your Windows session
NTLM Authentication: SQL Server Windows Authentication requires explicit credentials for the NTLM handshake
Credential Delegation: The tedious library must authenticate as your domain user to access SQL Server
Security Protocol: This is how NTLM works for service-to-service authentication - credentials must be explicitly provided
This isn't a configuration preference - it's a technical requirement of Windows Authentication in service contexts.
🔄 Alternative Approaches (Backward Compatible):
JSON String Variables: windows_credentials, connections
Legacy Variables: MSSQL_WINDOWS_CREDENTIALS, MSSQL_CONNECTIONS
Individual Legacy: MSSQL_USERNAME, MSSQL_PASSWORD, MSSQL_DOMAIN
💡 Why Individual Variables?
🚀 Cleanest: No JSON strings to escape or parse
📋 Clearest: Each setting immediately visible
🔧 Standard: Industry-standard environment variable approach
✅ Error-free: No JSON syntax issues possible
🔄 Compatible: All existing configurations continue to work
With multiple connections configured, you can switch between databases naturally in conversation:
User: "What database connections do I have available?"
Assistant: I'll list all your configured database connections...
[Shows: crm, erp, analytics, hr, etc.]
User: "Show me the customer tables in the CRM system"
Assistant: I'll explore the CRM database for customer-related tables...
[Uses connectionName: "crm"]
User: "Now check the analytics warehouse for sales data"
Assistant: Switching to the analytics database to look for sales data...
[Uses connectionName: "analytics"]
User: "Compare employee counts between HR system and ERP"
Assistant: I'll check both databases for employee information...
[Uses connectionName: "hr", then connectionName: "erp"]Read-Only Access: Only SELECT statements allowed
Query Validation: Automatic blocking of dangerous operations
Result Limiting: Automatic TOP clauses to prevent large data dumps
Connection Validation: Secure credential handling
Schema-Level Security: Respects database permissions
User: "What tables are in my database?"
Assistant: [Lists all tables with descriptions]
User: "Describe the customers table"
Assistant: [Shows column details, data types, constraints]
User: "Show me a sample of customer data"
Assistant: [Returns first 10 rows safely]User: "List my available connections"
Assistant: [Shows all configured database connections]
User: "Switch to the analytics database and show me the sales tables"
Assistant: [Connects to analytics DB and lists sales-related tables]
User: "Query both CRM and ERP systems for customer overlap"
Assistant: [Queries both systems and compares results]This MCP server provides specialized tools for analyzing Classic ASP applications and planning modernization:
// 1. Analyze stored procedures containing business logic
await mcp.call("list_stored_procedures", {
schema: "MyApp",
includeSystemObjects: false,
});
// 2. Extract business rules from database constraints
await mcp.call("analyze_check_constraints", {
schema: "MyApp",
});
// 3. Identify lookup tables and reference data
await mcp.call("find_lookup_tables", {
schema: "MyApp",
});
// 4. Analyze performance bottlenecks
await mcp.call("find_missing_indexes", {
schema: "MyApp",
});// Extract detailed stored procedure logic
await mcp.call("describe_stored_procedure", {
procedureName: "CalculateOrderTotal",
schema: "MyApp",
includeDefinition: true,
});
// Get complete SQL source code for analysis
await mcp.call("get_stored_procedure_definition", {
procedureName: "ProcessOrder",
schema: "MyApp",
formatOutput: true,
});
// Bulk extract all stored procedures for modernization
await mcp.call("get_all_stored_procedure_definitions", {
schema: "MyApp",
maxResults: 50,
});
// Search for procedures using specific tables or business logic
await mcp.call("search_stored_procedures_by_content", {
searchText: "Customer",
schema: "MyApp",
includeDefinitions: true,
});
// Find computed columns with business rules
await mcp.call("find_computed_columns", {
schema: "MyApp",
});
// Analyze data validation rules
await mcp.call("analyze_check_constraints", {
schema: "MyApp",
});// Identify audit trails and tracking patterns
await mcp.call("detect_audit_columns", {
schema: "MyApp",
});
// Analyze data patterns for normalization
await mcp.call("analyze_data_distribution", {
tableName: "Orders",
schema: "MyApp",
});
// Plan index strategy for new application
await mcp.call("analyze_index_usage", {
schema: "MyApp",
});User: "I need to understand the business logic in my legacy application database"
Assistant: I'll analyze your database for business logic patterns...
[Uses list_stored_procedures, analyze_check_constraints, find_computed_columns]
User: "What stored procedures handle order processing?"
Assistant: Let me search for order-related procedures...
[Uses search_stored_procedures_by_content with "order", then get_stored_procedure_definition for detailed analysis]
User: "Show me the complete SQL code for the CalculateOrderTotal procedure"
Assistant: I'll retrieve the full stored procedure definition...
[Uses get_stored_procedure_definition with formatOutput: true]
User: "Get all stored procedure code for the sales schema for modernization"
Assistant: I'll extract all stored procedure definitions from the sales schema...
[Uses get_all_stored_procedure_definitions with schema: "sales"]User: "Find performance issues in my database"
Assistant: I'll analyze indexes and table performance...
[Uses find_missing_indexes, analyze_table_stats, analyze_index_usage]
User: "Which tables are growing too fast?"
Assistant: Let me check table sizes and growth patterns...
[Uses analyze_table_stats, analyze_database_size]User: "Compare customer data between our CRM and ERP systems"
Assistant: I'll analyze customer tables in both systems...
[Switches between connectionName: "crm" and connectionName: "erp"]
User: "Find data quality issues across all our databases"
Assistant: Let me check data patterns across your systems...
[Uses analyze_null_patterns, analyze_data_distribution across multiple connections]# Development mode
npm run dev
# Build for production
npm run build
# Run tests
npm testMIT License - see LICENSE file for details.
Contributions welcome! Please read CONTRIBUTING.md for guidelines.
Configuration Guide - Complete setup and configuration details
Tools Reference - Comprehensive tool documentation
Stored Procedures Guide - Enhanced stored procedure tools documentation
Extract and analyze business rules from check constraints
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | No | Filter by specific table name | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states the purpose but does not disclose any behavioral traits such as read-only nature, permissions required, output format, or handling of large datasets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, front-loaded with the action. It is efficient but could be more concise by removing 'and analyze' if the analysis is implicit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 optional params, no output schema), the description is insufficient. It does not explain the return format or any behavioral details, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Extract and analyze) and resource (business rules from check constraints). It distinguishes from siblings like list_constraints by specifying analysis of business rules, but could be more explicit about the analysis aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It lacks any context about scenarios, prerequisites, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comprehensive database size information including data and log file sizes
| Name | Required | Description | Default |
|---|---|---|---|
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it returns size information but lacks details on exactly what is returned, whether it has side effects (likely none), or any required permissions. With no annotations, the burden is higher, but the description is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. However, it could be slightly more structured or expanded to include key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple structure (one optional parameter, no output schema), the description is adequate but not comprehensive. It explains the general output but not the exact return format or additional context an agent might need.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one optional parameter (connectionName) with a clear description. The tool description adds no further meaning about the parameter, but since schema coverage is 100%, the baseline is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving comprehensive database size information, specifically data and log file sizes. It distinguishes from sibling analyze_* tools that focus on other aspects like constraints or index usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get data distribution patterns for columns to understand data quality and patterns
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | Yes | Name of the table to analyze | |
| columnName | No | Specific column to analyze (analyzes all if not provided) | |
| sampleSize | No | Sample size for analysis (default: 1000) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavior like read-only nature or output format. It only says 'get' without specifying if it modifies data or what exactly is returned (e.g., histograms, statistics).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. It is efficient but lacks any additional structure like examples or context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description fails to explain what 'distribution patterns' entails or how parameters like sampleSize affect results. Incomplete for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds no extra meaning beyond the generic 'data distribution patterns' phrase. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets data distribution patterns for columns to understand data quality and patterns, using a specific verb and resource. It distinguishes from sibling tools like analyze_null_patterns or analyze_table_stats, though it could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus other analysis tools, nor any exclusions. The context of use is only implied, leaving the agent without direction on alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show detailed index usage statistics to identify unused or underutilized indexes
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | No | Filter by specific table name | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| showUnusedOnly | No | Show only unused indexes (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the tool shows statistics but does not disclose behavioral traits such as read-only nature, performance impact, or data freshness. The description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters and no output schema, the description is somewhat minimal. It does not explain the output format or how to interpret the statistics, leaving some gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the input schema already describes all four parameters. The description does not add additional meaning beyond what is in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool shows detailed index usage statistics to identify unused or underutilized indexes, using specific verb 'Show' and resource. It effectively distinguishes from siblings like list_indexes and find_missing_indexes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for analyzing index usage but provides no explicit guidance on when to use this tool versus alternatives like list_indexes or find_missing_indexes, nor any exclusions or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find columns with high null percentages and analyze null patterns
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| minNullPercentage | No | Minimum null percentage to include (default: 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'find' and 'analyze' but does not specify what the analysis entails, what the output format is, or if there are side effects (likely read-only). The description lacks details on permissions 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence. It is concise but could benefit from a bit more detail without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 optional parameters and no output schema or annotations. The description does not explain what the tool returns (e.g., a list of columns with null percentages, patterns), nor does it provide usage context. More completeness is needed for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so each parameter is documented. The description adds no additional meaning beyond the schema; it only reiterates the tool's purpose. Baseline for full coverage is 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds columns with high null percentages and analyzes null patterns. It distinguishes itself from sibling tools like analyze_check_constraints or analyze_data_distribution by focusing specifically on null values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Given many similar analyze_* siblings, the description should indicate when null pattern analysis is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get table row counts, size information, and last update statistics
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | No | Filter by specific table name | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only lists what information is returned. It does not disclose whether the tool is read-only, requires permissions, or has performance implications. Behavior beyond the return type is opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff, direct to the point. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description should explain return values in more detail. It lists three types of information but lacks specifics (e.g., file sizes, row counts per table, last update timestamp format). Also missing edge-case handling (empty tables, permissions).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents each parameter. The description adds no extra meaning beyond the raw names, such as constraints or default behavior. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves table row counts, size information, and last update statistics. The verb 'Get' and the resource 'table statistics' are specific. However, it does not clarify whether it returns stats for a single table or all tables when tableName is omitted, which creates slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus sibling tools like analyze_data_distribution or describe_table. No exclusions or prerequisites mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific stored procedure including parameters and definition
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| procedureName | Yes | Name of the stored procedure to describe | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeDefinition | No | Include the procedure definition/body (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the operation is read-only, requires permissions, or has rate limits. The agent has no insight into side effects or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be slightly expanded to include usage or output details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not mention what fields or structure the output contains, and there is no output schema. Given the tool's complexity and lack of annotations, this is insufficient for an agent to understand what 'detailed information' includes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters, so the description adds no additional meaning. It re-iterates 'including parameters and definition' but does not provide syntax or constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about a stored procedure, including parameters and definition. However, it does not distinguish itself from sibling tools like 'get_stored_procedure_definition', which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There are no guidelines on when to use this tool versus alternatives. For example, it does not indicate that 'describe_stored_procedure' is suitable for full details, while 'get_stored_procedure_definition' might be used for only the body.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed schema information for a specific table including columns, data types, and constraints
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | Yes | Name of the table to describe | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly states the tool returns detailed schema information (columns, data types, constraints), which adequately conveys its read-only nature and scope. However, it does not mention authentication needs, rate limits, or output structure, which are minor omissions for a simple tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the action and result. It is front-loaded with key information and contains no unnecessary words, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 100% schema coverage and no output schema, the description provides essential context. It explains the tool's purpose and output content, though it could be improved by briefly noting the return format (e.g., list of column objects). The sibling context is relevant but the description alone is sufficient for an agent to select the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 3 parameters have descriptions in the schema (100% coverage), so baseline is 3. The description adds value by explaining what the tool returns (columns, data types, constraints), helping the agent understand the output beyond parameter details. This additional context justifies a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and clearly identifies the resource as 'detailed schema information for a specific table'. It lists the included aspects (columns, data types, constraints), making it distinct from sibling tools like list_tables (which only lists names) or describe_view.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing schema details but does not provide explicit guidance on when to use this tool over alternatives (e.g., get_relationships, list_constraints). No when-not or exclusion criteria are mentioned, relying on the agent to infer from the tool name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific trigger including its definition and events
| Name | Required | Description | Default |
|---|---|---|---|
| triggerName | Yes | Name of the trigger to describe | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeDefinition | No | Include the trigger definition (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It implies a read operation ('Get detailed information') but does not disclose side effects, permissions, or other behavioral traits beyond the basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. It front-loads the purpose and key outputs. Could slightly benefit from more structure but remains concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 3 parameters and no output schema, the description sufficiently covers what the tool does and what it returns. It could mention the response format but is generally complete for a describe tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value. It mentions 'definition and events' which relates to the includeDefinition parameter, but does not explain connectionName or triggerName beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Get detailed information about a specific trigger including its definition and events'. The verb 'Get' and resource 'trigger' are specific, but it does not differentiate from sibling describe tools for other objects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and context of sibling describe tools. No explicit guidance on when to use this versus alternatives like describe_table or describe_view is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific view including its definition and dependencies
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| viewName | Yes | Name of the view to describe | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeDefinition | No | Include the view definition (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description bears full responsibility for behavioral disclosure. It mentions 'definition and dependencies' but fails to specify the exact output structure, potential side effects, or authorization requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single 15-word sentence that efficiently communicates the core purpose. It is not front-loaded with structured details, but it is appropriately succinct for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description leaves significant gaps for an agent: the exact structure of the returned detail, how dependencies are represented, and behavior of optional parameters are omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all parameters are documented in the schema. The description adds minimal value beyond restating 'definition and dependencies', which aligns with the includeDefinition parameter. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns 'detailed information about a specific view' including 'definition and dependencies'. It effectively conveys the resource and action, distinguishing it from sibling tools like describe_table which target tables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as describe_table or describe_stored_procedure. It lacks any 'when to use' or 'when not to use' context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify common audit trail patterns (created/modified dates, user tracking)
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the tool is read-only, requires specific permissions, or any side effects. The behavior beyond pattern identification is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that communicates the core purpose without extraneous words. It lacks structure but is appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema and the description does not explain what the tool returns (e.g., a list of columns, a report). Given that the tool likely produces output, the agent lacks necessary context for invoking and using the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters (schema and connectionName). The description adds no extra meaning beyond what is already in the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'Identify' and resource 'common audit trail patterns' with examples like 'created/modified dates, user tracking'. It distinguishes the tool from siblings that focus on other database analysis tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other analysis tools in the sibling list. The description does not mention prerequisites or context for effective use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a custom SQL SELECT query with automatic limit (top 20 rows). Disabled unless MSSQL_ENABLE_EXECUTE_QUERY=true.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | SQL SELECT query to execute | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the automatic limit and configuration requirement but omits behavioral details such as return format, error handling, or safety precautions, which are critical for a potentially risky operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no extraneous information. The first sentence captures the core purpose, the second adds an essential precondition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate but incomplete. It lacks details on result format and potential risks, which are important for a tool that executes arbitrary SQL queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds automatic limit context for the query parameter but does not significantly enhance understanding beyond the schema descriptions for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes a custom SQL SELECT query with an automatic limit. It is distinct from sibling tools which are analytical or metadata retrieval tools, not query execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a precondition (MSSQL_ENABLE_EXECUTE_QUERY=true) but lacks explicit guidance on when to use this tool versus alternatives or when not to use it (e.g., heavy queries). It only implies usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List computed columns and their formulas to understand derived business logic
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | No | Filter by specific table name | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It states 'list' implying read-only, but does not explicitly confirm no side effects, required permissions, or output format. Key behavioral traits like whether it queries the database or returns cached results are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant words. It directly states the action and purpose, fitting within the context of sibling tools. However, it could be slightly more structured with separation of usage hints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description hints at return values (columns and formulas) but lacks specifics like data types or pagination. The tool has 3 optional parameters, and the description does not address how outputs are organized. It is minimally adequate but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptions in the schema (100% coverage), so the description's contribution is minimal. It adds no extra meaning beyond the schema, such as explaining the role of connectionName or clarifying the default schema behavior. Baseline 3 is appropriate as the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly targets resource 'computed columns' with purpose 'to understand derived business logic'. It effectively distinguishes from sibling tools like list_tables or list_indexes by focusing on computed columns, though it does not explicitly differentiate from similar schema analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as analyze_table_stats or describe_table. There is no mention of prerequisites, limitations, or when not to use it. The usage context is only implied by the purpose statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify reference/lookup tables automatically based on table patterns
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| maxRows | No | Maximum rows to consider as lookup table (default: 1000) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It vaguely mentions 'based on table patterns' without explaining criteria, whether results are returned as a list, or if any mutations occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the tool's purpose. However, it could be slightly expanded to include key behavioral notes without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, no output schema, and no annotations, the description is too minimal. It fails to explain the output format, algorithm details, or how the tool operates, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not clarify how parameters like 'maxRows' or 'schema' affect the pattern detection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Identify' and clearly states the resource 'reference/lookup tables', distinguishing it from sibling tools like 'analyze_data_distribution' or 'list_tables'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for automatically identifying lookup tables, but it provides no explicit guidance on when to use it over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Identify potentially missing indexes based on query execution patterns
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| minImpact | No | Minimum impact score to include (default: 1000) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description lacks behavioral details. Since no annotations are present, the description should disclose whether the tool performs any destructive actions, requires specific permissions, or has side effects. It only mentions 'query execution patterns' without explaining what that entails. For a tool that likely reads data, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and easy to parse. It avoids redundancy, but could be slightly expanded to include usage context without becoming verbose. It is appropriately front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should clarify what the tool returns (e.g., a list of missing indexes with impact scores). It does not. Additionally, with three optional parameters, it does not provide typical usage examples or default behavior, leaving the agent uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what is in the input schema definitions. It does not explain how 'minImpact' is calculated or how 'schema' qualifies the search. Thus, no added value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: identifying potentially missing indexes. It uses a specific verb 'identify' and resource 'missing indexes', and it is distinct from sibling tools like 'list_indexes' or 'analyze_index_usage'. However, it could be more precise about the methodology (e.g., 'based on query execution patterns' is generic).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus its siblings. For example, there is no mention of prerequisites, recommended scenarios, or how this differs from 'analyze_index_usage'. The agent is left without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete SQL definitions for all stored procedures in a schema
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| maxResults | No | Maximum number of procedures to return (default: 50, max: 100) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeSystemProcedures | No | Include system stored procedures (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states it retrieves definitions, but fails to mention whether it requires permissions, is read-only, or has any side effects. The agent lacks awareness of the tool's safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 10 words, front-loading the key action and resource. Every word is necessary, and there is no redundancy or wasted information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is minimal. It does not explain return format, pagination, or parameter behavior (e.g., default schema, maxResults). Adequate but leaves gaps for a tool with 4 parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented. The description adds no additional meaning beyond what the schema provides. It mentions 'in a schema' but the schema parameter already covers that. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'complete SQL definitions for all stored procedures', and the scope 'in a schema'. It effectively distinguishes from sibling tools like 'get_stored_procedure_definition' (single) and 'get_multiple_stored_procedure_definitions' (multiple, but not all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving all procedure definitions, but it does not provide explicit guidance on when to use this tool over alternatives like 'get_multiple_stored_procedure_definitions' or 'get_stored_procedure_definition'. No when-not-to-use or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get complete SQL definitions for multiple stored procedures at once
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| procedureNames | Yes | Array of stored procedure names to get definitions for | |
| includeMetadata | No | Include metadata like creation date, modification date (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It only states 'complete SQL definitions' without disclosing potential behavioral traits such as performance considerations, size limits on the array, error handling, or whether it returns multiple definitions as a batch or sequentially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the key action and resource, with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters, no output schema, and no annotations, the description is too minimal. It lacks context on how to handle the returned definitions, potential limits on procedure count, and prerequisites (e.g., connection must be valid).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no additional 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description clearly state it retrieves complete SQL definitions for multiple stored procedures at once, distinguishing it from siblings like 'get_stored_procedure_definition' (single) and 'get_all_stored_procedure_definitions' (all).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch retrieval ('at once') but does not explicitly state when to use this over alternatives like 'get_stored_procedure_definition' for single procedures or 'get_all_stored_procedure_definitions' for all procedures. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get foreign key relationships between tables in the database
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description implies a read-only operation via the verb 'Get'. No contradictory or missing behavioral disclosure is apparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that efficiently conveys the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should clarify the structure of returned data (e.g., table names, columns). It does not, leaving ambiguity about the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves foreign key relationships, which is a specific resource. However, it does not explicitly differentiate from sibling tools like list_constraints or describe_table, which may also provide foreign key info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of exclusion criteria or recommended contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the complete SQL query/definition of a stored procedure - this is the actual source code
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| formatOutput | No | Format the SQL output for better readability (default: true) | |
| procedureName | Yes | Name of the stored procedure to get definition for | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states that it retrieves source code. Missing details on whether the operation is read-only, required permissions, error behavior on missing procedures, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is clear and front-loaded. Could be slightly more structured by separating purpose and behavior, but it is appropriately concise without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description explains the return value (SQL source code). All parameters are documented in the schema. However, missing context about connectionName usage, default schema behavior, and whether formatOutput affects only syntax style or content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for all 4 parameters, so the schema itself documents them well. The description does not add extra meaning beyond stating it returns source code, not referencing any parameter specifics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'stored procedure definition', and explicitly clarifies it is 'the actual source code'. This differentiates it from sibling tools like 'describe_stored_procedure' which likely return metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings such as 'get_all_stored_procedure_definitions' or 'describe_stored_procedure'. Does not mention prerequisites, when not to use, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all available named database connections configured in the server
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states that it lists connections without mentioning auth requirements, rate limits, side effects, or whether the listing is scoped to the current user. For a read operation, minimal transparency is provided beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of 8 words. It is front-loaded with the action and resource, containing no fluff or repetition. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (no params, no output schema), the description covers the essential purpose but lacks details on what the list contains (e.g., connection names, types, status). For a list tool, some context about the output would enhance usability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty schema). Per guidelines, baseline for 0 parameters is 4. The description does not need to add parameter info but provides concise purpose that aligns with the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'list' and resource 'database connections', clearly distinguishing it from sibling list tools like list_databases and list_tables. It adds clarity by specifying 'named database connections configured in the server', avoiding any ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like test_connection or other list tools. The description does not mention any prerequisites, exclusions, or context-dependent usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all constraints (check, unique, foreign key, etc.) across tables in the database
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| constraintType | No | Filter by constraint type (default: ALL) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should disclose behavioral traits such as read-only nature, authorization needs, or rate limits. The description only states what it lists, with no mention of side effects or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core functionality without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 3 parameters and no output schema, the description does not explain the return format, filter behavior, or edge cases like when no constraints exist. This leaves important gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are fully described in the schema (100% coverage), so the description does not need to add much. The description mentions constraint types, which aligns with the enum, but adds no extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list constraints) and provides examples of constraint types, making the purpose evident. However, it does not explicitly differentiate from the sibling tool 'list_default_constraints', which lists a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives like 'list_default_constraints' or 'analyze_check_constraints'. The agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all databases available on the SQL Server instance
| Name | Required | Description | Default |
|---|---|---|---|
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'list all databases' but does not mention that it is a read-only operation, any authentication needs, or potential errors like invalid connection names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. Every part is relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description is somewhat complete but lacks context on connection prerequisites and behavioral details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described. The description adds nothing beyond the schema's parameter description, so it meets the baseline but provides no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list' and the resource 'databases available on the SQL Server instance'. It distinguishes itself from sibling tools like 'list_tables' and 'list_views'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It lacks context on prerequisites, such as needing a valid connection, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all default value constraints and their definitions
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | No | Filter by specific table name | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, side effects, or permissions. The verb 'list' implicitly suggests a safe read operation, but this is not stated explicitly, resulting in low transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently states the tool's purpose without redundancy. It is front-loaded with the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with fully described parameters, the description provides sufficient context. It mentions 'their definitions' hinting at output content. However, it could explicitly note that schema and tableName are optional filters, but this is not essential given the schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are described in the input schema (100% coverage). The description adds no additional meaning beyond the schema's existing parameter descriptions, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all default value constraints and their definitions' clearly specifies the verb 'List' and the resource 'default value constraints'. It is distinct from sibling tool 'list_constraints' which likely covers all constraint types, making this specific to defaults.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to view default constraints but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, relying on context from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all user-defined functions (scalar, table-valued, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| functionType | No | Filter by function type (default: ALL) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates a read-only listing operation but does not disclose additional behavioral details beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with no wasted words; single sentence that is front-loaded and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with full schema coverage, the description is sufficient, though it lacks details on output format or potential errors.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents parameters; the description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List', the resource 'user-defined functions', and specifies types like 'scalar, table-valued, etc.', distinguishing it from sibling list_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives; usage is implied by the list category but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all indexes on tables with usage statistics and detailed information
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | No | Filter by specific table name | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeUsageStats | No | Include index usage statistics (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It states listing indexes with usage stats but does not confirm read-only nature, required permissions, or potential side effects. This is insufficient for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence (12 words) that is front-loaded with the core purpose. It wastes no words, though it could benefit from more structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is too minimal. It lacks details on return format, default behaviors (e.g., includeUsageStats default), and how parameters interact, making it incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 4 parameters with 100% coverage via schema descriptions. The tool description adds no additional parameter details beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'List' and the resource 'indexes on tables' with additional context 'usage statistics and detailed information'. It is specific but does not distinguish from sibling tools like 'analyze_index_usage' or 'find_missing_indexes'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all stored procedures, functions, and their basic information
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeSystemObjects | No | Include system stored procedures (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the tool lists basic information but does not mention default behavior for parameters (e.g., whether system objects are included by default) or performance implications. The tool is read-only, but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource, no redundant words. Efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description could elaborate on what 'basic information' includes (e.g., name, schema, type, creation date). It also does not mention whether the results are paginated or limited. However, it is adequate for a simple listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 3 parameters have descriptions). The tool description does not add additional meaning beyond the schema; it only summarizes the overall function. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List all stored procedures, functions, and their basic information' clearly states the tool's action (List), resource (stored procedures and functions), and scope (basic info). It distinguishes from siblings like 'describe_stored_procedure' which gives detailed metadata, and 'get_all_stored_procedure_definitions' which returns full definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like 'describe_stored_procedure' or 'get_multiple_stored_procedure_definitions'. The description does not mention when to choose this tool over similar list tools such as 'list_functions' or 'list_triggers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in the connected database
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must bear full burden. It merely restates the action without disclosing behavioral traits such as whether system tables are included, performance implications, or reliance on an active connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence with no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and full schema coverage, the description is minimally complete. However, it could specify the output format (e.g., list of table names) to enhance clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description does not add meaning beyond the schema; parameters are adequately described in the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('tables'), clearly indicating the action. It distinguishes from sibling tools like describe_table, analyze_table_stats, etc., which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. siblings. The description implies it for listing tables, but lacks context like 'use this to get an overview of available tables before performing other operations.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all triggers in the database with their associated tables
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| tableName | No | Filter by specific table name | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden but only states basic functionality. It does not disclose required permissions, performance impact, or whether it returns only enabled triggers. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. It is front-loaded with the main action. Could be slightly expanded for structure but is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description is adequate. However, it does not mention the output format (list of trigger names with tables) or any edge cases (e.g., no triggers found). Given low complexity, it meets minimum completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so the schema already documents parameters. The description adds no additional semantics beyond the schema, which is acceptable. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists triggers and their associated tables, using a specific verb+resource. It distinguishes from siblings like 'describe_trigger' but could be more explicit about scope across schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'describe_trigger' or other listing tools. The context signals show many sibling tools with similar names, but the description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all user-defined data types and their definitions
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry the full burden. It only states the action, omitting any side effects, authentication needs, or data volume implications. For a read operation, it's minimally informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 7 words, which is extremely concise and front-loaded with the action. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could elaborate on return format, but for a straightforward listing with optional parameters, it provides the essential purpose. Lack of output details slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for both parameters. The tool description does not add extra meaning beyond what the schema already provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'user-defined data types and their definitions', which is specific and distinguishes it from sibling tools like list_tables or list_views.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives; usage is implied by the tool name and context, but no when-not-to-use or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all views in the database with their basic information
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeSystemViews | No | Include system views (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits (e.g., read-only nature, permissions). It only states the action without any behavioral context, leaving the agent uninformed about side effects or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately conveys the tool's purpose. It is front-loaded and contains no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 optional parameters and no output schema, the description is adequate but lacks details on return values (what constitutes 'basic information') and defaults. It is sufficient for a simple listing but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all views in the database with basic information, distinguishing it from siblings like list_tables or list_functions by the object type. However, it does not specify what 'basic information' includes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as describe_view or other listing tools. The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve sample data from a table (top 10 rows by default)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of rows to return (default: 10, max: 100) | |
| schema | No | Schema name (default: dbo) | |
| tableName | Yes | Name of the table to sample | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses default and maximum row limits, but does not specify how rows are selected (e.g., random, first rows, ordering). This leaves some ambiguity about the sampling method.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous information. Every word is essential and contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple sampling tool, the description covers the essential purpose, default behavior, and parameter context. It does not explain return format, but no output schema is provided, so omitting this is acceptable. Minor gap: no mention of row ordering or performance considerations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema adequately documents all parameters. The description adds minimal value beyond restating the default limit. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'retrieve sample data' and the resource 'a table', with explicit scope 'top 10 rows by default'. This distinguishes it from sibling tools like analyze, describe, or list which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage (retrieving a quick sample), but does not explicitly state when not to use it or mention alternative tools like execute_query. However, the uniqueness of the function is evident from the name and sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for stored procedures containing specific text or patterns in their SQL definition
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name (default: dbo) | |
| searchText | Yes | Text or pattern to search for in procedure definitions | |
| caseSensitive | No | Case sensitive search (default: false) | |
| connectionName | No | Named connection to use (e.g., 'production', 'staging') | |
| includeDefinitions | No | Include full procedure definitions in results (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it searches for text/patterns, but does not disclose important details: the search scope (all schemas?), search method (LIKE, full-text?), performance implications, or side effects. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the core purpose without verbosity. However, it is so brief that it sacrifices completeness (e.g., no explanation of results). It earns its place but could be slightly more informative without being wordy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, and no annotations. The description does not explain what the tool returns (e.g., list of procedure names, with or without definitions). Given the complexity of a search tool, this omission makes the description incomplete for an agent to properly utilize the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, meaning each parameter is documented in the schema. The description adds no additional semantic value beyond the schema; it does not clarify formats, defaults, or relationships between parameters. Thus, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Search' and the resource 'stored procedures', specifying it searches for text or patterns in SQL definitions. This distinguishes it from sibling tools like 'list_stored_procedures' (which lists names) and 'get_stored_procedure_definition' (which retrieves full definition by name), making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when not to use it, prerequisites, or comparison with siblings like 'get_all_stored_procedure_definitions' or 'describe_stored_procedure'. The usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test the database connection and return basic server information
| Name | Required | Description | Default |
|---|---|---|---|
| connectionName | No | Named connection to use (e.g., 'production', 'staging') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions returning 'basic server information' but does not specify what that includes (e.g., version, latency) or confirm it's a safe read-only operation. The agent is left guessing about side effects and return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be slightly improved by structuring to separate purpose and return information. It is still appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema, no annotations), the description is minimally adequate. It states the basic operation and return, but lacks specifics on what 'basic server information' entails. It is complete enough for a simple test tool but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter described in schema). The description adds no extra meaning to the parameter 'connectionName' beyond what the schema provides. Baseline 3 is appropriate since the schema already documents the parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'test' clearly indicates the action, and 'database connection' specifies the resource. The description uniquely identifies the tool's function among siblings, which are all about schema/query analysis rather than connectivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., existing connection), when not to use it, or contrast with tools like 'list_connections' or 'execute_query'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.3.0analyze_check_constraintsanalyze_data_distributionanalyze_database_sizeanalyze_index_usageanalyze_null_patternsanalyze_table_statsdescribe_stored_proceduredescribe_tabledescribe_triggerdescribe_viewdetect_audit_columnsexecute_queryfind_computed_columnsfind_lookup_tablesfind_missing_indexesget_all_stored_procedure_definitionsget_multiple_stored_procedure_definitionsget_relationshipsget_stored_procedure_definitionlist_connectionslist_constraintslist_databaseslist_default_constraintslist_functionslist_indexeslist_stored_procedureslist_tableslist_triggerslist_user_defined_typeslist_viewssample_datasearch_stored_procedures_by_contenttest_connectionScored across 33 tools
Tools are generally distinct in purpose, but there are many analysis and listing tools (e.g., analyze_table_stats vs. describe_table vs. list_tables) that could cause confusion if descriptions are skimmed. However, each tool has a clear focus, so ambiguity is low.
All tools follow a consistent verb_noun pattern using snake_case (e.g., list_tables, analyze_index_usage, describe_table). No mixed conventions or irregular names.
33 tools is on the high side, but each serves a distinct purpose for database analysis and exploration. The scope is broad but justified; tools like analyze_* and list_* cover different aspects.
The toolset is heavily skewed toward read-only analysis (schema inspection, statistics, sample data). Missing DDL operations (create, alter, drop) and write operations, which are essential for full database management. Execution of arbitrary queries is disabled by default.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Ask questions in plain language, get answers from your business database. No SQL required.
Ask data questions in natural language. Get SQL, insights, and charts from your databases.
Ask business questions in plain English. Get instant answers from your database, no SQL needed.
Query Allen-Bradley and Siemens PLC projects, live tag values, and analyses in plain English.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/vicagbasi/mssql-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
