DBMCP

list_tables

List tables and views in SQL Server schemas with row counts and metadata. Filter by schema, name pattern, or minimum rows; sort and paginate results for efficient schema exploration.

Instructions

List tables in specified schema(s) with row counts and metadata.

Efficiently retrieves table metadata using SQL Server DMVs. Supports filtering by schema, name pattern, and minimum row count. Supports pagination via offset parameter. Supports filtering by object type to include/exclude views.

Args: connection_id: Connection ID from connect_database schema_filter: List of schema names to include (empty = all schemas) name_pattern: Table name filter using SQL LIKE pattern (e.g., 'Customer%') min_row_count: Minimum row count threshold to filter tables sort_by: Sort criterion - 'name', 'row_count', or 'last_modified' (default: 'row_count') sort_order: Sort order - 'asc' or 'desc' (default: 'desc') limit: Maximum tables to return, 1-1000 (default: 100) offset: Number of results to skip for pagination (default: 0) object_type: Filter by type - 'table', 'view', or None for all (default: None) output_mode: 'summary' (names+row counts) or 'detailed' (includes columns) (default: 'summary') catalog: Optional Databricks catalog name. Overrides the connection's default catalog. Rejected on non-Databricks dialects (raises an error).

Returns: TOON-encoded string with table list and pagination metadata:

    status: "success" | "error"
    returned_count: int                // on success only
    total_count: int                   // on success only
    offset: int                        // on success only
    limit: int                         // on success only
    has_more: bool                     // on success only
    tables: list                       // on success only
        schema_name: string
        table_name: string
        table_type: "table" | "view"
        row_count: int
        has_primary_key: bool
        last_modified: ISO 8601 string | null
        access_denied: bool
        columns: list              // detailed mode only
    error_message: string          // on error only

Input Schema

TableJSON Schema

Name	Required	Default
`limit`	No
`offset`	No
`catalog`	No
`sort_by`	No	row_count
`sort_order`	No	desc
`object_type`	No
`output_mode`	No	summary
`name_pattern`	No
`connection_id`	Yes
`min_row_count`	No
`schema_filter`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 20, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and discloses substantial behavior: it uses SQL Server DMVs, supports filtering and pagination, includes an access_denied flag, and notes that catalog is rejected on non-Databricks dialects. It also details the return structure and error handling, covering expectations beyond the basic operation.

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 opens with a one-line summary, follows with a brief capability paragraph, and then uses a structured Args/Returns layout. Each sentence, including the detailed return block, earns its place given the tool's 11 parameters and complex output.

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

Completeness5/5

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

For a tool with 11 parameters, no annotations, and a complex return payload, the description covers all parameters, defaults, filters, pagination, output modes, error cases, and dialect-specific behavior. The only missing piece would be a note on how to establish a connection, but it correctly references connect_database.

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

Parameters5/5

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

Schema description coverage is 0%, but the Args section supplies per-parameter semantics: source of connection_id, empty-list behavior for schema_filter, SQL LIKE syntax for name_pattern, allowed values and defaults for sort_by/sort_order, range for limit, type choices for object_type, and mode semantics for output_mode. This fully compensates for the schema's lack of descriptions.

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 opening sentence states a specific action ('List tables'), a target resource ('tables in specified schema(s)'), and the delivered information ('row counts and metadata'). The supported filters and mention of views make it clear this is a metadata listing tool, distinct from siblings like list_schemas or get_table_schema.

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

Usage Guidelines3/5

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

The description communicates its purpose and prerequisite (connection_id from connect_database) but does not explicitly name any sibling tool or state conditions for when to choose an alternative. The mention of SQL Server DMVs gives context but no exclusions, so an agent must infer when to use this vs. other schema inspection tools.

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

Deploy Server