Retrieve tables and views from a GaussDB database, including types, estimated row counts, and comments. Filter by schema to focus exploration on specific objects.
列出 GaussDB 数据库中的表和视图清单（表名、类型、估算行数、注释）。可通过 schema 参数过滤到指定模式。
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | 限定模式名（schema），省略时扫描全部非系统模式 | |
| instance | No | 数据源名称（配置文件中 instance 的 name），省略时使用默认实例 | |
| include_system | No | 是否包含系统模式，默认 false |
Changes observed during successful MCP inspections.
v0.2.2Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure. It provides a useful detail: by default it excludes system schemas (but can include them via the include_system parameter). It does not describe output format or potential performance implications (e.g., full scan of all schemas), which could be more transparent for a read-only tool.
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?
The description is concise - a single sentence with an additional sentence on the schema parameter. It is front-loaded with the core purpose. It could be slightly more structured (e.g., bullets) but is appropriately sized for the content.
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?
Given that there is no output schema and the tool is relatively simple (listing tables/views), the description covers the essential: what it returns, the schema filter, and the default exclusion of system schemas. It lacks explicit mention that this is a read-only operation, but the 'list' verb implies that. It might also mention that the return can be large, but not critical.
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?
The schema description coverage is 100%, so all three parameters (schema, instance, include_system) are well described in the schema. The description adds value by mentioning the schema filter and the default behavior of scanning all non-system schemas, but it adds little beyond the schema for instance and include_system.
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?
States a specific verb ('列出' / list), a clear resource (tables and views in the GaussDB database), and the exact information returned (table name, type, estimated rows, comment). It is unambiguous and distinct from siblings like describe_table or execute_select, which are clearly different operations.
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?
The description mentions the schema parameter for filtering, implying a use case of narrowing the query scope. It does not explicitly state when not to use this tool or mention alternatives, but the context (listing inventory) is clear enough. A small gap: no mention that describe_table should be used for single-table details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.