DBMCP

get_table_schema

Retrieve detailed schema metadata for a specific table, including columns, data types, constraints, indexes, and foreign key relationships.

Instructions

Get detailed schema for a specific table.

Returns complete table metadata including columns, data types, constraints, indexes, and declared foreign key relationships.

Args: connection_id: Connection ID from connect_database table_name: Name of the table. May be dotted (e.g. 'schema.table' or 'catalog.schema.table') and is resolved against the dialect. schema_name: Schema name. Defaults to the dialect's default schema (e.g. 'dbo' on MSSQL) when omitted. include_indexes: Include index information (default: True) include_relationships: Include declared foreign keys (default: True) 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 schema details:

    status: "success" | "error"
    table: object                          // on success only
        table_name: string
        schema_name: string
        columns: list
            column_name: string
            ordinal_position: int
            data_type: string
            max_length: int | null
            is_nullable: bool
            default_value: string | null
            is_identity: bool
            is_computed: bool
            is_primary_key: bool
            is_foreign_key: bool
        indexes: list                      // if include_indexes=True
            index_name: string
            is_unique: bool
            is_primary_key: bool
            is_clustered: bool
            columns: list of string
            included_columns: list of string
        foreign_keys: list                 // if include_relationships=True
            constraint_name: string | null
            source_columns: list of string
            target_schema: string
            target_table: string
            target_columns: list of string
    error_message: string                  // on error only

Input Schema

TableJSON Schema

Name	Required	Description	Default
`catalog`	No
`table_name`	Yes
`schema_name`	No
`connection_id`	Yes
`include_indexes`	No
`include_relationships`	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.7/5.0

Behavior5/5

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

With no annotations, the description carries the full behavioral disclosure burden and satisfies it: it reveals that the result is a TOON-encoded string with success/error status, explains catalog rejection on non-Databricks dialects, documents default behaviors for schema_name and include flags, and specifies which fields appear conditionally. This goes far beyond what the input schema provides.

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

Conciseness4/5

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

The description is front-loaded with a one-sentence summary followed by a well-organized Args/Returns layout. The return schema block is lengthy, but it is justified by the output's complexity and the lack of a separately visible structured output schema. No filler or redundant wording is present.

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 definition covers all six parameters, required vs optional, defaults, error handling, return formatting, and dialect-specific behavior. An agent has all necessary information to call the tool and interpret the result without consulting additional sources.

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%, so the Args section must carry all parameter meaning, and it does. It explains dotted table_name resolution against the dialect, schema_name defaulting behavior, catalog override semantics, the non-Databricks rejection, and the boolean flag defaults. Every parameter gains material context beyond its bare schema definition.

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 statement: 'Get detailed schema for a specific table.' It enumerates the exact metadata returned (columns, data types, constraints, indexes, foreign keys), making the tool's purpose unambiguous and distinct from siblings like get_column_info 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.

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: whenever detailed table schema is needed. It does not explicitly name alternatives or exclusions, but the context is strong enough for an agent to route correctly. The catalog parameter's dialect restriction also supplies a concrete usage constraint.

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

Deploy Server