Teradata MCP Server

Official

by Teradata

Overview Schema Source Related Servers Discussions(1)Admin

Python

Remote

Dba Resusagesummary

dba_resusageSummary

Read-onlyIdempotent

Report system-wide CPU, IO, and memory consumption across time periods, applications, workloads, or complexity classes to reveal resource usage trends and bottlenecks.

Instructions

Report system-wide resource consumption (CPU, IO, memory) broken down by time period, application, workload type, or complexity class. Use when the user asks for system-level resource breakdowns, workload profiles, or consumption trends over a date range — not tied to a specific database. For per-database or per-user impact within a named database, use dba_tableUsageImpact instead.

Arguments: user_name - User name to filter by. Leave empty for all users. LogDate - Log date to filter by in YYYY-MM-DD format. Leave empty for all dates. dayOfWeek - Day of week to filter by (1=Sunday, 2=Monday, ..., 7=Saturday). Leave empty for all days. hourOfDay - Hour of day to filter by (0-23). Leave empty for all hours. workloadType - Workload type to filter by (e.g., 'Batch', 'Interactive'). Leave empty for all workload types. workloadComplexity - Workload complexity to filter by (e.g., 'Simple', 'Medium', 'Complex'). Leave empty for all complexity levels. AppID - Application ID to filter by. Leave empty for all applications. no_days - Number of days to look back from today (e.g., 7, 30, 90). persist - If True, materializes result as a volatile table and returns table name

Input Schema

TableJSON Schema

Name	Required	Description
`AppID`	No	Application ID to filter by. Leave empty for all applications.
`LogDate`	No	Log date to filter by in YYYY-MM-DD format. Leave empty for all dates.
`no_days`	No	Number of days to look back from today (e.g., 7, 30, 90).
`persist`	No	If True, materializes result as a volatile table and returns table name
`dayOfWeek`	No	Day of week to filter by (1=Sunday, 2=Monday, ..., 7=Saturday). Leave empty for all days.
`hourOfDay`	No	Hour of day to filter by (0-23). Leave empty for all hours.
`user_name`	No	User name to filter by. Leave empty for all users.
`workloadType`	No	Workload type to filter by (e.g., 'Batch', 'Interactive'). Leave empty for all workload types.
`workloadComplexity`	No	Workload complexity to filter by (e.g., 'Simple', 'Medium', 'Complex'). Leave empty for all complexity levels.

Schema Changelog

Changes observed during successful MCP inspections.

Changed33 schema fields changedv0.2.1Apr 30, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / AppID

Added value: +{
+  "default": "",
+  "description": "Application ID to filter by. Leave empty for all applications.",
+  "type": "string"
+}

removedInput schema / properties / AppId

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Appid"
-}

addedInput schema / properties / LogDate

Added value: +{
+  "default": "",
+  "description": "Log date to filter by in YYYY-MM-DD format. Leave empty for all dates.",
+  "type": "string"
+}

removedInput schema / properties / date

Removed value: -{
-  "anyOf": [
-    {
-      "type": "string"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Date"
-}

removedInput schema / properties / dayOfWeek / anyOf

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

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

addedInput schema / properties / dayOfWeek / description

Added value: +"Day of week to filter by (1=Sunday, 2=Monday, ..., 7=Saturday). Leave empty for all days."

removedInput schema / properties / dayOfWeek / title
```
Removed value: -"Dayofweek"
```
addedInput schema / properties / dayOfWeek / type
```
Added value: +"string"
```

removedInput schema / properties / dimensions

Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Dimensions"
-}

removedInput schema / properties / hourOfDay / anyOf

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

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

addedInput schema / properties / hourOfDay / description

Added value: +"Hour of day to filter by (0-23). Leave empty for all hours."

removedInput schema / properties / hourOfDay / title
```
Removed value: -"Hourofday"
```
addedInput schema / properties / hourOfDay / type
```
Added value: +"string"
```

addedInput schema / properties / no_days

Added value: +{
+  "default": 7,
+  "description": "Number of days to look back from today (e.g., 7, 30, 90).",
+  "type": "integer"
+}

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 / user_name / anyOf

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

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

addedInput schema / properties / user_name / description

Added value: +"User name to filter by. Leave empty for all users."

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

removedInput schema / properties / workloadComplexity / anyOf

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

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

addedInput schema / properties / workloadComplexity / description

Added value: +"Workload complexity to filter by (e.g., 'Simple', 'Medium', 'Complex'). Leave empty for all complexity levels."

removedInput schema / properties / workloadComplexity / title
```
Removed value: -"Workloadcomplexity"
```
addedInput schema / properties / workloadComplexity / type
```
Added value: +"string"
```

removedInput schema / properties / workloadType / anyOf

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

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

addedInput schema / properties / workloadType / description

Added value: +"Workload type to filter by (e.g., 'Batch', 'Interactive'). Leave empty for all workload types."

removedInput schema / properties / workloadType / title
```
Removed value: -"Workloadtype"
```
addedInput schema / properties / workloadType / type
```
Added value: +"string"
```

Changed4 schema fields changedv1.0.0Jan 2, 2026

addedInput schema / properties / AppId

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Appid"
+}

addedInput schema / properties / workloadComplexity

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Workloadcomplexity"
+}

addedInput schema / properties / workloadType

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Workloadtype"
+}

removedInput schema / title

Removed value: -"handle_dba_resusageSummaryArguments"

First observedAug 18, 2025

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context: it reports system-wide resource consumption, supports multiple breakdown dimensions, and the persist parameter's side effect (materializing a volatile table and returning its name) is disclosed. No contradiction with annotations.

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 description is well-structured: a clear opening sentence, explicit usage guidance, and a compact parameter list. It is slightly longer than necessary because it repeats parameter descriptions already present in the schema, but the front-loaded purpose and usage guidance make it efficient and scannable.

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?

For a read-only reporting tool with 9 optional parameters and no output schema, the description covers the core purpose, usage context, and the one side-effecting parameter (persist). It does not describe the return format or result shape, but since there is no output schema and the tool is a report, a brief note on what the result looks like would be helpful. Still, the essential information for selecting and invoking the tool is present.

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 9 parameters. The description repeats the parameter list but adds no new meaning beyond what the schema provides. Baseline 3 is appropriate because the schema carries the heavy lifting; the description does not need to compensate.

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 states a specific verb ('Report') and resource ('system-wide resource consumption') and enumerates the breakdown dimensions (time period, application, workload type, complexity class). It also explicitly distinguishes itself from dba_tableUsageImpact by noting it is not tied to a specific database, which differentiates it from the closest sibling.

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 for system-level resource breakdowns, workload profiles, or consumption trends over a date range — not tied to a specific database.' It also names the alternative tool (dba_tableUsageImpact) and the condition that selects it (per-database or per-user impact within a named database). This is clear 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

Dba Resusagesummary

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools