Retrieve the full structure of a table or view, including columns, types, nullability, defaults, primary keys, constraints, indexes, and partition lists, with view definitions when applicable.
查看表/视图的完整结构：列清单（类型/可空/默认值/注释）、主键与约束、全部索引及其定义；视图返回视图定义 SQL，分区表返回分区清单。
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | 表名或视图名（必填） | |
| schema | No | 模式名，省略时自动在非系统模式中查找（歧义时报错） | |
| instance | No | 数据源名称（配置文件中 instance 的 name），省略时使用默认实例 |
Changes observed during successful MCP inspections.
v0.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing output categories and special-case behavior: views return definition SQL and partitioned tables return a partition list. However, it does not explicitly state read-only semantics, error behavior for missing tables, or permission requirements, which would make it fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the core action and then lists all value-adding details without filler. Every clause earns its place, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a metadata inspection tool, the description covers the essential return categories and even anticipates special cases (views and partitioned tables). Since there is no output schema, the description partially compensates by describing content, but it omits error/ambiguity behavior and access considerations, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description itself adds little beyond what the schema already documents. The mention of table/view names roughly maps to the table parameter, but there is no additional semantic depth for schema resolution or instance selection beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (查看/inspect) and names the exact resource: the full structure of a table or view. It enumerates what is returned—columns with metadata, primary keys and constraints, indexes, view definition SQL, and partition lists—making its purpose unmistakable and clearly distinct from siblings like execute_select (row data) and list_tables (only table names).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given for when to use this tool versus alternatives. The intended use case is implied by the content, but the description never states exclusions or points to siblings such as execute_select for data retrieval or list_tables for name discovery, nor does it mention when the optional schema or instance parameters matter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.