shop

Overview Schema Source Related Servers Discussions Admin

describe_table

Inspect a SQLite table's columns, data types, primary keys, and foreign keys before building joins. Returns actual metadata to guide read-only queries.

Instructions

Describe columns, types, primary keys, and foreign keys for one table.

Use before writing joins. Returns actual SQLite metadata only — never fabricates fields such as country. Parameters: table (name from list_tables). Returns {table, columns: [{name, type, primary_key, ...}], foreign_keys}.

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": {
      "table": "<table>"
    },
    "name": "describe_table"
  }
}

Input Schema

Name	Required	Description	Default
`table`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 23, 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 of behavioral disclosure. It adds an important guarantee: 'Returns actual SQLite metadata only — never fabricates fields such as country', which communicates trustworthiness and avoids hallucinated results. It also describes the return shape. It does not explicitly state that the operation is read-only, but 'returns metadata' strongly conveys that.

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 compact and front-loaded: purpose first, then when to use it, then parameter provenance, then output shape. Every sentence earns its place, with no filler or repeated structural information beyond what is useful.

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 tool is simple (one string parameter, an output schema exists, no annotations), and the description gives enough to invoke it correctly: what it returns, where the parameter value comes from, and why to use it before joins. It could add explicit note about error behavior for invalid table names, but that is not essential for a straightforward describe/metadata tool.

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 provides only a type string and a title 'table', so the description adds crucial meaning: table is 'the name from list_tables'. This tells the agent where valid values come from, effectively linking describe_table to list_tables. That is exactly the kind of semantic enrichment the schema lacks.

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 uses a specific verb ('Describe') and precise resources (columns, types, primary keys, foreign keys) for 'one table', clearly distinguishing it from list_tables (listing) and execute_readonly_sql (querying). The phrase 'one table' prevents confusion with table-listing siblings, and the mention of metadata-only output further clarifies its exact scope.

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 explicitly says 'Use before writing joins', which gives a clear context and timing for using this tool. It also states that the table name should come from list_tables, effectively providing a prerequisite. However, it does not explicitly name alternatives or say when not to use this tool (e.g., when listing tables or running arbitrary SQL).

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

Deploy Server