Teradata MCP Server

Official

by Teradata

Overview Schema Source Related Servers Discussions(1)Admin

Python

Remote

Dba Tablespace

dba_tableSpace

Read-onlyIdempotent

Rank tables by disk space usage in a Teradata database to identify which tables consume the most storage. Specify a database name to get size-ranked results.

Instructions

Show table-level disk space usage within a specific Teradata database, ranked by size. Use when the user asks which tables are largest or consuming the most storage within a named database. NEVER call this tool with an empty database_name — if the user's message does not explicitly name a database, ask which database they want before calling. For space allocated to a whole database, use dba_databaseSpace. For total system-wide storage, use dba_systemSpace.

Arguments: database_name - Database name. Required — do not pass empty string. table_name - Table name filter. Leave empty for all tables. top_n - Limit results to top N largest tables by space. Set to 0 for no limit (default: 0). exclude_system - Exclude system databases and tables. Set to 'Y' to exclude, 'N' to include all (default: 'N'). persist - If True, materializes result as a volatile table and returns table name

Input Schema

TableJSON Schema

Name	Required	Description	Default
`top_n`	No	Limit results to top N largest tables by space. Set to 0 for no limit (default: 0).
`persist`	No	If True, materializes result as a volatile table and returns table name
`table_name`	No	Table name filter. Leave empty for all tables.
`database_name`	Yes	Database name. Required — do not pass empty string.
`exclude_system`	No	Exclude system databases and tables. Set to 'Y' to exclude, 'N' to include all (default: 'N').	N

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv1.0.1Jul 4, 2026

removedInput schema / properties / database_name / default
```
Removed value: -""
```

changedInput schema / properties / database_name / description

Previous value: -"Database name filter. Leave empty for all databases."New value: +"Database name. Required — do not pass empty string."

addedInput schema / required
```
Added value: +[
+  "database_name"
+]
```

Changed14 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"
-  }
-]

changedInput schema / properties / database_name / default
```
Previous value: -nullNew value: +""
```

addedInput schema / properties / database_name / description

Added value: +"Database name filter. Leave empty for all databases."

removedInput schema / properties / database_name / title
```
Removed value: -"Database Name"
```
addedInput schema / properties / database_name / type
```
Added value: +"string"
```

addedInput schema / properties / exclude_system

Added value: +{
+  "default": "N",
+  "description": "Exclude system databases and tables. Set to 'Y' to exclude, 'N' to include all (default: 'N').",
+  "type": "string"
+}

addedInput schema / properties / persist

Added value: +{
+  "default": false,
+  "description": "If True, materializes result as a volatile table and returns table name",
+  "type": "boolean"
+}

removedInput schema / properties / table_name / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

changedInput schema / properties / table_name / default
```
Previous value: -nullNew value: +""
```

addedInput schema / properties / table_name / description

Added value: +"Table name filter. Leave empty for all tables."

removedInput schema / properties / table_name / title
```
Removed value: -"Table Name"
```
addedInput schema / properties / table_name / type
```
Added value: +"string"
```

addedInput schema / properties / top_n

Added value: +{
+  "default": 0,
+  "description": "Limit results to top N largest tables by space. Set to 0 for no limit (default: 0).",
+  "type": "integer"
+}

Changed4 schema fields changedv1.0.0Jan 2, 2026
- addedInput schema / properties / database_name / default
```
Added value: +null
```
- addedInput schema / properties / table_name / default
```
Added value: +null
```
- removedInput schema / required
```
Removed value: -[
-  "database_name",
-  "table_name"
-]
```
- removedInput schema / title
```
Removed value: -"handle_dba_tableSpaceArguments"
```
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, lowering the burden on the description. The description adds useful behavioral context: results are ranked by size, persist materializes a volatile table and returns its name, and empty database_name is an invalid call. No contradiction with annotations is present.

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 main description is front-loaded with purpose, usage trigger, and exclusion guidance before the arguments list. The argument list is somewhat redundant with the schema, but it is clearly formatted and does not undermine readability.

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?

For a tool with five parameters, no output schema, and several related siblings, the description is fully sufficient. It covers what the tool does, when to use it, how to avoid invalid calls, which siblings to route to, and the meaning of every parameter including the persist behavior.

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 fully documents every parameter. The description essentially repeats the same parameter information rather than adding new meaning beyond the schema, which lands it at the baseline score.

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 specific verb and resource: 'Show table-level disk space usage within a specific Teradata database, ranked by size.' It also explicitly distinguishes itself from sibling tools dba_databaseSpace and dba_systemSpace by scope, so an agent can select it accurately.

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?

Gives direct trigger conditions: 'Use when the user asks which tables are largest or consuming the most storage within a named database.' It explicitly warns against calling with an empty database_name, instructs the agent to ask for a database if unnamed, and names alternatives for database-level and system-level space.

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

Deploy Server

Dba Tablespace

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools