Skip to main content
Glama
Teradata

Teradata MCP Server

Official
by Teradata
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
Python
Remote

Dba Tablesqllist

dba_tableSqlList
Read-onlyIdempotent

Find which SQL queries have been executed against a specific Teradata table. Provide a table name and lookback period to retrieve the SQL statements run against it.

Instructions

Retrieve SQL statements that have been executed against a specific named table. Use when the user asks what queries have run against a particular table. ONLY call when the user has explicitly named a specific table — if no table name is in the message, ask for clarification. Do NOT use for SQL history by user — use dba_userSqlList when the user asks what queries a specific person has been running.

Arguments: table_name - Table name to search for no_days - Number of days to look back persist - If True, materializes result as a volatile table and returns table name

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
no_daysNoNumber of days to look back
persistNoIf True, materializes result as a volatile table and returns table name
table_nameYesTable name to search for

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv0.2.1
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / no_days / anyOf
      Removed value: -[
-  {
-    "type": "integer"
-  },
-  {
-    "type": "null"
-  }
-]
    • addedInput schema / properties / no_days / description
      Added value: +"Number of days to look back"
    • removedInput schema / properties / no_days / title
      Removed value: -"No Days"
    • addedInput schema / properties / no_days / type
      Added value: +"integer"
    • addedInput schema / properties / persist
      Added value: +{
+  "default": false,
+  "description": "If True, materializes result as a volatile table and returns table name",
+  "type": "boolean"
+}
    • addedInput schema / properties / table_name / description
      Added value: +"Table name to search for"
    • removedInput schema / properties / table_name / title
      Removed value: -"Table Name"
  2. Changed1 schema field changedv1.0.0
    • removedInput schema / title
      Removed value: -"handle_dba_tableSqlListArguments"
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already provide readOnlyHint and idempotentHint, and the description adds meaningful behavioral context beyond those: the requirement for an explicit table name, and the persist parameter's effect of materializing a volatile table and returning a table name. It does not contradict the annotations, as the volatile table appears to be ephemeral rather than a persistent write.

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 core guidance is front-loaded in the first two sentences and the exclusion is stated immediately. The Arguments section is somewhat redundant with the input schema, but it is brief and does not obscure the tool's purpose. Overall, every important behavioral rule earns its place.

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?

Given there is no output schema, the description reasonably covers what the tool does, when to use it, when not to use it, and the key parameter behaviors including persist. It does not detail the exact return shape of the SQL statement list, but the tool name and core description make that reasonably inferable. This is complete enough for reliable invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description repeats the parameter descriptions almost verbatim without adding extra semantic depth, such as value formats, edge cases, or more concrete examples. A baseline 3 is appropriate because the description does not meaningfully surpass the schema.

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 opens with a specific verb and resource: 'Retrieve SQL statements that have been executed against a specific named table.' It also explicitly distinguishes itself from dba_userSqlList by stating this is not for user-based SQL history, making the tool's scope unambiguous.

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

Usage Guidelines5/5

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

The description gives explicit when-to-use guidance: 'Use when the user asks what queries have run against a particular table.' It also provides a clear exclusion with an alternative: 'Do NOT use for SQL history by user — use dba_userSqlList.' The strict condition about requiring an explicit table name, and asking for clarification otherwise, is exceptionally clear.

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

Deploy Server

Other Tools