Skip to main content
Glama
Sign In
mssql-mcp

mssql-mcp

by is-jvelez
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

list_views

Retrieves database views from SQL Server, with optional filtering by schema and name pattern to locate specific views for analysis and exploration.

Instructions

Lista las vistas de la base de datos.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_views"
  }
}

Input Schema

NameRequiredDescriptionDefault
schemaNo
namePatternNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.1/5.0
Behavior2/5

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

With no annotations provided at all, the description carries the full burden of behavioral disclosure. It provides no information about whether this is a read-only operation, whether schema filtering is supported despite the schema parameter existing, what the returned view definitions contain, or if it follows the same behavior as sibling listing tools.

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

Conciseness3/5

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

The single-sentence description is concise and front-loaded in Spanish. There is no wasted text, but it errs on the side of under-specification rather than appropriate conciseness.

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

Completeness2/5

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

For a tool with 2 undocumented parameters, no annotations, no output schema, and multiple closely-related sibling tools, this description is inadequate. It does not explain return format, filtering behavior, parameter semantics, or relationship to sibling tools like list_tables.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate for the two undocumented parameters (schema, namePattern). It fails to do so — neither parameter is mentioned in the description. The agent is left guessing what these parameters mean and how they filter results.

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

Purpose2/5

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

The description 'Lista las vistas de la base de datos' (Lists the views of the database) states the verb and resource with reasonable clarity. However, it does not distinguish itself from sibling tools like list_tables or list_triggers which follow the same 'list X' pattern, and there's no mention of scope or filtering capabilities.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. The siblings list includes list_tables, list_triggers, and list_stored_procedures which are directly comparable 'listing' tools; the description gives no exclusions or context on which scenario calls for views specifically. No mention of optional filtering via schema or namePattern.

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

Deploy Server

Other Tools