Elekto MCP for SQL Server

Official

Overview Schema Source Related Servers Discussions Admin

Database overview

get_database_overview

Read-onlyIdempotent

Summarize a SQL Server database's name, server, login, object counts, and size in MB before exploring it; flags incomplete visibility when permissions hide objects.

Instructions

Summarizes one database: real name, server and instance, connected login, counts of tables, views, procedures, functions and schemas, and allocated size in MB. Use it after list_databases to size up a database before exploring it; for the same figures per schema use get_schema_summary. Counts cover only what the login can see: 'visibility.complete' is false when SQL Server hides objects, and check_permissions then says which GRANT is missing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "database": "<database>"
    },
    "name": "get_database_overview"
  }
}

Input Schema

Name	Required	Description	Default
`database`	Yes	Name of the database as registered in the configuration.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 4, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description goes well beyond them: counts are scoped to what the login can see, the 'visibility.complete' flag is explained as false when SQL Server hides objects, and check_permissions is named as the follow-up for missing GRANTs. This is real behavioral disclosure an agent cannot get from the schema.

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?

Three tight sentences, front-loaded with what is returned, then usage, then a caveat about visibility. Every clause carries information; nothing is redundant with the name or title.

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?

With no output schema, the description compensates by enumerating the returned figures and even naming the 'visibility.complete' field, and it explains the degraded-visibility case plus the remediation path. Nothing needed to call or interpret this tool is missing.

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 single parameter is fully documented as 'Name of the database as registered in the configuration.' The description doesn't add format or lookup detail for the parameter itself, so the baseline of 3 applies — the schema does the heavy lifting.

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?

Specific verb ('Summarizes one database') plus an explicit enumeration of what the summary contains (real name, server/instance, login, object counts, allocated MB). This is clearly distinguishable from siblings like get_schema_summary and list_databases.

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

Usage Guidelines5/5

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

States the workflow position explicitly ('after list_databases to size up a database before exploring it') and names the alternative for a different granularity ('for the same figures per schema use get_schema_summary'). When-to-use and the sibling selector are both spelled out.

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