SQL Query Tools MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose: connection testing, schema overview, database info, table details, data sampling, and read-only query execution. The descriptions clarify any potential overlap between schema and table descriptions.
Naming Consistency5/5
All tool names follow a consistent db_ prefix with snake_case verbs/nouns, such as test_connection, describe_schema, list_databases, describe_table, sample_data, and run_readonly. The naming pattern is uniform and predictable.
Tool Count5/5
With 6 tools, the set is well-scoped for a SQL query server. Each tool covers a necessary step in the query workflow without redundancy or unnecessary additions.
Completeness4/5
The toolset covers the core read-only query workflow: connect, understand schema, sample data, and execute queries. Minor gaps like lack of multiple database listing or more advanced metadata are acceptable for the stated purpose.
Average 4.2/5 across 6 of 6 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It indicates the tool returns information and the qualifier 'currently connected' adds context about requiring an active connection. However, it does not explicitly state that the operation is read-only or describe potential error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the function and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool, the description provides basic information. However, it lacks detail about the 'status' return value and does not clarify the relationship to sibling tools like db_test_connection, leaving some ambiguity about its exact purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description adds no parameter-specific meaning. Per the guidelines, a zero-parameter tool receives a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the currently connected database name and status, which is specific and action-oriented. However, it does not explicitly distinguish itself from sibling tools like db_test_connection, which may also return status information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'currently connected' implies the tool is useful for checking the active database context, but there is no explicit guidance on when to use it versus alternatives. No exclusions or comparisons with sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it returns exactly 5 rows and works on tables/views, but doesn't mention whether rows are randomly selected, deterministic, or if any side effects exist. Basic behavior is clear, but additional traits (e.g., row ordering, limits for small tables) are unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no redundant words. It front-loads the primary function ('Returns 5 sample rows') followed by practical usage guidance. Every word contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool without an output schema, the description is nearly complete: it defines the output (5 rows), the target (table/view), and the use case. It could optionally specify response format or ordering, but the essentials are well covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for the 'table' parameter with a description and example. The tool description adds no new parameter-specific meaning beyond restating 'table or view', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Returns 5 sample rows from a table or view.' It uses a specific verb and resource, and distinguishes itself from siblings like db_describe_table (schema) and db_run_readonly (general queries) by focusing on sample data exploration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use this to understand the actual data format, values and patterns before writing a more specific query.' This implies when to use it (exploratory phase) and suggests alternatives (later specific queries). It doesn't explicitly name sibling tools or state when not to use, but the guidance is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It reveals that results are cached to avoid repeated database calls, a useful trait. However, it does not explicitly confirm read-only behavior, mention any permissions required, or describe potential side effects (though likely none). It adds some context but not comprehensive coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: what it returns, when to use it, and a note about caching. It is front-loaded with the core purpose and contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, parameterless tool. The description conveys the return value ('tables and views with column count'), usage context ('use this first'), and a behavioral nuance (caching). Given the lack of output schema and no parameters, this is complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the input schema is empty. Per the rubric, 0 params earns a baseline of 4. The description appropriately avoids inventing parameter details and focuses on behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Returns all available tables and views with their column count.' This clearly differentiates it from siblings like db_list_databases (databases only) and db_describe_table (a single table), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use this first to understand what data is available before writing queries' gives explicit when-to-use context. It implies this tool precedes query-writing tools but does not explicitly name alternatives or exclusions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It transparently states the output ('Returns full column details') and the tool's name implies a read-only operation. It does not explicitly mention side effects or error conditions, but for a metadata descriptor, this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence states the function and returned fields; the second sentence explains the typical use case. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single simple parameter, no output schema, and a clear return type. The description fully covers what the tool does and when to use it. Nothing important is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already defines the 'table' parameter with an example. The description adds little beyond stating 'specific table or view,' which does not significantly improve on the schema. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns full column details (name, data type, nullable) for a specific table or view. It distinguishes itself from siblings like db_describe_schema (whole schema) and db_sample_data (data preview) by focusing on column metadata for one table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Use this when you need to know exact column names before writing a query.' This tells the agent a concrete scenario, though it does not explicitly name alternatives or exclusions. Still, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. It discloses two important behaviors: write operations are blocked, and TOP is automatically injected if no row limit is present. These are critical side effects that the agent would not otherwise know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with each adding value: the core action, behavioral constraint, and usage guidance. It is front-loaded and free of waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential facets for a generic query tool: functionality, constraints, side effects, and schema discovery fallback. Given there is no output schema, the absence of a return-value description is a minor gap, but the provided details are sufficiently complete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the query parameter (100% coverage). The description adds meaning by constraining the accepted query to read-only SELECTs and explaining the automatic TOP injection, which affects how the query parameter is interpreted and executed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb+resource: 'Executes a SELECT query on SQL Server.' It also distinguishes itself from sibling tools by explicitly limiting to read-only SELECT commands, making it unique among schema exploration and test tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit advice to use db_describe_schema and db_describe_table first when unsure about names, and clarifies that write operations are blocked. It does not compare directly to db_sample_data, but the read-only SELECT context implies when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of transparency. It states the action ('Tests the connection') and the outcome ('returns basic server information'), adequately conveying a safe, read-only operation. It could explicitly mention that no data is modified, but the nature of a connection test strongly implies this, earning a 4.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary verb and resource, and every word adds value. There is no fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential aspects: what it does and when to use it. It also positions it among sibling tools, making it contextually complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is trivially 100%. Per the rubric, the baseline for 0 parameters is 4. The description adds no parameter-specific information, but none is needed since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Tests the connection to SQL Server and returns basic server information.' This is a specific verb-resource pair that distinguishes it from siblings like db_describe_schema and db_list_databases. The additional phrase 'Use this first' further differentiates its role as a prerequisite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: 'Use this first to verify the server is reachable before running other tools.' This gives clear when-to-use guidance and implies it should be the first tool executed, setting it apart from alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-sqlserver-readonly MCP server](https://glama.ai/mcp/servers/negrip/mcp-sqlserver-readonly/badges/card.svg)](https://glama.ai/mcp/servers/negrip/mcp-sqlserver-readonly)

Score Badge

Copy to your README.md:

[![mcp-sqlserver-readonly MCP server](https://glama.ai/mcp/servers/negrip/mcp-sqlserver-readonly/badges/score.svg)](https://glama.ai/mcp/servers/negrip/mcp-sqlserver-readonly)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/negrip/mcp-sqlserver-readonly'

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