mcp-server-db2i

Profile Table

profile_table

Read-onlyIdempotent

Profile a DB2 for i table for ETL: get row counts, deleted rows, size, last change, and per-column distinct/null/low/high values from stats or exact scans.

Instructions

Profile a table for ETL work: row count, deleted rows, size, and last change from QSYS2.SYSTABLESTAT, plus per-column distinct count, null count, and low and high values. By default column numbers come from stored statistics in QSYS2.SYSCOLUMNSTAT (low and high are the second-lowest and second-highest values), and columns without collected statistics report source "none". Set compute to true to scan the table for exact numbers on up to 20 columns. Masked columns keep their counts and return no values.

Input Schema

Name	Required	Description
`table`	Yes	Table name
`schema`	No	Schema (library) that contains the table. Uses the system's default schema if not provided.
`columns`	No	Columns to profile. Defaults to every column (the first 20 when compute is true).
`compute`	No	Scan the table for exact counts, MIN, and MAX. Slower on large tables. Default false.

Output Schema

Name	Required	Description
`sql`	No
`data`	No
`mode`	No
`cause`	No	Why the statement failed. &1-style placeholders stand for values in error.
`count`	No
`error`	No
`table`	No
`schema`	No
`columns`	No
`sqlcode`	No	SQLCODE of the failed statement, such as -204
`success`	Yes
`recovery`	No	What to change before trying again
`sqlstate`	No	SQLSTATE of the failed statement
`truncated`	No
`table_stats`	No
`computed_rows`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv3.8.1Oct 17, 2026

addedOutput schema / properties / columns

Added value: +{
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "kind": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "kind"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

First observedv3.0.0Sep 28, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Annotations already establish the read-only, idempotent, non-destructive profile, and the description layers on real behavioral detail: statistics come from QSYS2.SYSTABLESTAT/SYSCOLUMNSTAT, low/high are the second-lowest and second-highest values rather than true extremes, columns without statistics report source 'none', and masked columns return counts with no values. These are exactly the non-obvious traits an agent would otherwise get wrong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with what the tool produces, then defaults, then the compute trade-off, then the masked-column edge case. Four dense sentences with no filler and no repetition of the title.

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?

An output schema exists, so return shape need not be explained, and annotations carry the safety profile. The description nonetheless covers defaults, the exactness trade-off, the column cap, and the masked-column and missing-statistics cases, leaving nothing an agent needs to call it correctly.

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 all four parameters are already documented in the schema, including the 20-column default for compute. The description mostly reinforces those defaults (default source, 20-column scan limit) rather than adding syntax or format meaning the schema lacks, so the baseline 3 applies.

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?

Names a specific verb and resource ('Profile a table') and enumerates exactly what is produced: row count, deleted rows, size, last change, plus per-column distinct count, null count, and low/high values. That output inventory makes it unmistakable against siblings like describe_table or list_tables, which return structure rather than statistics, even without naming them.

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

Usage Guidelines4/5

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

Gives a clear selection condition for the key parameter: use stored statistics by default, and set compute to true when exact numbers are needed, noting the up-to-20-column cap. It frames the tool around 'ETL work' but never names an alternative tool or states when this tool is the wrong choice versus describe_table.

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