Teradata MCP Server

Official

by Teradata

Overview Schema Source Related Servers Discussions(1)Admin

Python

Remote

Base Tableddl

base_tableDDL

Read-onlyIdempotent

Retrieve the CREATE TABLE DDL for a Teradata table to view its full schema, including column types, constraints, primary indexes, and keys. Requires both table and database names.

Instructions

Return the CREATE TABLE DDL statement for a Teradata table, showing its full schema definition including column types, constraints, primary indexes, and keys. Use when the user wants the CREATE statement, the table definition, or needs to see how the table was built. If the user has not specified both a table name AND a database name, ask for clarification before calling — do not guess or use an empty database name. To save DDL to a file on disk, use base_saveDDL instead. For just column names and types, use base_columnDescription instead.

Arguments: table_name - Table name database_name - Database name persist - If True, materializes result as a volatile table and returns table name

Input Schema

TableJSON Schema

Name	Required	Description
`persist`	No	If True, materializes result as a volatile table and returns table name
`table_name`	Yes	Table name
`database_name`	Yes	Database name

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv1.0.1Jul 4, 2026
- removedInput schema / properties / database_name / default
```
Removed value: -""
```
- changedInput schema / required
```
Previous value: -[
-  "table_name"
-]New value: +[
+  "table_name",
+  "database_name"
+]
```
Changed10 schema fields changedv0.2.1Apr 30, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- removedInput schema / properties / database_name / anyOf
```
Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]
```
- addedInput schema / properties / database_name / default
```
Added value: +""
```
- addedInput schema / properties / database_name / description
```
Added value: +"Database name"
```
- removedInput schema / properties / database_name / title
```
Removed value: -"Database Name"
```
- addedInput schema / properties / database_name / type
```
Added value: +"string"
```
- 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"
```
- removedInput schema / properties / table_name / title
```
Removed value: -"Table Name"
```
- changedInput schema / required
```
Previous value: -[
-  "database_name",
-  "table_name"
-]New value: +[
+  "table_name"
+]
```
Changed3 schema fields changedv1.0.0Jan 2, 2026
- addedInput schema / properties / database_name / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]
```
- removedInput schema / properties / database_name / type
```
Removed value: -"string"
```
- removedInput schema / title
```
Removed value: -"handle_base_tableDDLArguments"
```
First observedAug 18, 2025

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds useful behavior beyond that: the optional persist flag materializes the result as a volatile table and returns the table name, and it clarifies the required input combination. It does not detail missing-table or permission errors, but with annotations in place this is adequate and does not contradict them.

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?

Purpose and usage guidance are front-loaded, and the displacement to siblings is compressed into short, direct sentences. The argument list duplicates the input schema, which costs a point, but the overall structure is scannable and free of filler.

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?

Even without an output schema, the description explains what is returned (the DDL text with column types, constraints, primary indexes, and keys) and what persist does. It also covers the required input combination and routes alternative needs to the correct sibling tools. No critical information needed to select and call the tool is missing.

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 baseline is 3. The description's argument list repeats the same one-line meanings already in the schema and adds little semantic detail. The most valuable parameter-related guidance, 'ask for clarification rather than guess or use empty database name', appears in the prose rather than as deeper parameter semantics.

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?

States a direct action ('Return') and a specific artifact ('CREATE TABLE DDL statement for a Teradata table'), and enumerates what the DDL includes. It also distinguishes itself from siblings by naming base_saveDDL and base_columnDescription, so an agent knows exactly what this tool does and does not do.

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?

Explicitly provides the trigger condition ('Use when the user wants the CREATE statement...'), a mandatory precondition (ask if both table and database names are not specified rather than guessing), and named alternatives with their conditions ('To save DDL to a file... base_saveDDL', 'For just column names and types... base_columnDescription'). This is excellent routing guidance.

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

Deploy Server

Base Tableddl

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools