mcp-server-db2i

Execute SQL Query

execute_query

Read-onlyIdempotent

Run read-only SQL SELECT queries against IBM Db2i to retrieve data securely. Only SELECT statements are allowed, and results are limited by default to prevent large result sets.

Instructions

Execute a read-only SQL SELECT query against the IBM Db2i database. Only SELECT statements are allowed for security. Results are limited by default to prevent large result sets. Pass chart only when the user asks for a chart or graph. Otherwise leave it out: the result opens as a table and the user can switch to a chart.

Input Schema

Name	Required	Description
`sql`	Yes	SQL SELECT query to execute
`chart`	No	How to chart the rows. Column names must match the result columns.
`limit`	No	Maximum number of rows to return (default: QUERY_DEFAULT_LIMIT, max: QUERY_MAX_LIMIT)
`params`	No	Query parameters for prepared statement

Output Schema

Name	Required	Description
`data`	No
`cause`	No	Why the statement failed. &1-style placeholders stand for values in error.
`chart`	No	The chart the result view draws
`error`	No
`columns`	No	Result columns in order, with the kind of value each holds
`sqlcode`	No	SQLCODE of the failed statement, such as -204
`success`	Yes
`recovery`	No	What to change before trying again
`rowCount`	No
`sqlstate`	No	SQLSTATE of the failed statement
`warnings`	No	Tell the user these, such as columns the driver rounded
`truncated`	No	True when the result stopped at limitApplied and more rows match
`chartError`	No	Why the chart argument was not used
`violations`	No
`limitApplied`	No
`skippedFilters`	No	Annotated tables whose row filter, such as leaving out deleted rows, the query does not use. See warnings

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv3.8.1Oct 17, 2026

addedInput schema / properties / chart

Added value: +{
+  "additionalProperties": false,
+  "description": "How to chart the rows. Column names must match the result columns.",
+  "properties": {
+    "horizontal": {
+      "description": "Horizontal bars, for long labels or rankings",
+      "type": "boolean"
+    },
+    "series": {
+      "description": "Column whose values become separate series, such as STATUS",
+      "maxLength": 128,
+      "minLength": 1,
+      "type": "string"
+    },
+    "stacked": {
+      "description": "Stack bar or area series",
+      "type": "boolean"
+    },
+    "target": {
+      "description": "Column with a target or budget, drawn as a line over the bars",
+      "maxLength": 128,
+      "minLength": 1,
+      "type": "string"
+    },
+    "title": {
+      "maxLength": 120,
+      "minLength": 1,
+      "type": "string"
+    },
+    "type": {
+      "description": "bar, line or area for categories or time; pie or doughnut for a share of six or fewer parts; scatter for two measures; pareto for a ranking with cumulative share; waterfall for a running total (first row is the start value, the rest are changes); histogram to bin one measure; kpi for a one-row result; table for no chart",
+      "enum": [
+        "bar",
+        "line",
+        "area",
+        "pie",
+        "doughnut",
+        "scatter",
+        "pareto",
+        "waterfall",
+        "histogram",
+        "kpi",
+        "table"
+      ],
+      "type": "string"
+    },
+    "x": {
+      "description": "Column for categories or time (the x axis)",
+      "maxLength": 128,
+      "minLength": 1,
+      "type": "string"
+    },
+    "y": {
+      "description": "Measure columns. Leave out to chart the first measure; name more only when the user asks to compare them",
+      "items": {
+        "maxLength": 128,
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 3,
+      "minItems": 1,
+      "type": "array"
+    }
+  },
+  "required": [
+    "type"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / chart

Added value: +{
+  "additionalProperties": false,
+  "description": "The chart the result view draws",
+  "properties": {
+    "horizontal": {
+      "description": "Horizontal bars, for long labels or rankings",
+      "type": "boolean"
+    },
+    "series": {
+      "description": "Column whose values become separate series, such as STATUS",
+      "maxLength": 128,
+      "minLength": 1,
+      "type": "string"
+    },
+    "stacked": {
+      "description": "Stack bar or area series",
+      "type": "boolean"
+    },
+    "target": {
+      "description": "Column with a target or budget, drawn as a line over the bars",
+      "maxLength": 128,
+      "minLength": 1,
+      "type": "string"
+    },
+    "title": {
+      "maxLength": 120,
+      "minLength": 1,
+      "type": "string"
+    },
+    "type": {
+      "description": "bar, line or area for categories or time; pie or doughnut for a share of six or fewer parts; scatter for two measures; pareto for a ranking with cumulative share; waterfall for a running total (first row is the start value, the rest are changes); histogram to bin one measure; kpi for a one-row result; table for no chart",
+      "enum": [
+        "bar",
+        "line",
+        "area",
+        "pie",
+        "doughnut",
+        "scatter",
+        "pareto",
+        "waterfall",
+        "histogram",
+        "kpi",
+        "table"
+      ],
+      "type": "string"
+    },
+    "x": {
+      "description": "Column for categories or time (the x axis)",
+      "maxLength": 128,
+      "minLength": 1,
+      "type": "string"
+    },
+    "y": {
+      "description": "Measure columns. Leave out to chart the first measure; name more only when the user asks to compare them",
+      "items": {
+        "maxLength": 128,
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 3,
+      "minItems": 1,
+      "type": "array"
+    }
+  },
+  "required": [
+    "type"
+  ],
+  "type": "object"
+}

addedOutput schema / properties / chartError

Added value: +{
+  "description": "Why the chart argument was not used",
+  "type": "string"
+}

addedOutput schema / properties / columns

Added value: +{
+  "description": "Result columns in order, with the kind of value each holds",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "kind": {
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "name",
+      "kind"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}

Changed2 schema fields changedv3.5.0Oct 1, 2026

addedOutput schema / properties / skippedFilters

Added value: +{
+  "description": "Annotated tables whose row filter, such as leaving out deleted rows, the query does not use. See warnings",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when the result stopped at limitApplied and more rows match",
+  "type": "boolean"
+}

First observedv3.0.0Sep 28, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered structurally. The description adds value beyond that by disclosing that only SELECT statements are permitted (security enforcement) and that results are capped by default — both operational constraints the annotations do not convey.

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?

Front-loaded with the core purpose, then the SELECT-only constraint, then the chart guidance — a sensible order. Every sentence earns its place, though the chart explanation runs slightly long relative to the rest.

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?

An output schema exists, so return-value explanation is not required, and the description correctly focuses on constraints and the chart parameter. It covers the required sql, the limit default behavior, and the nested chart object's conditional use, leaving only minor gaps around params/prepared statements.

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

Parameters4/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, and the description earns above that by explaining the chart parameter's conditional usage and the default table behavior when it is omitted. It adds no detail on params or limit beyond the schema, keeping it short of a 5.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (execute) and resource (read-only SQL SELECT against IBM Db2i), so the agent knows exactly what this does. It does not explicitly name or differentiate from the sibling validate_query, which is the closest alternative, so it stops short of a 5.

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

Usage Guidelines3/5

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

Gives one concrete when-to-use rule for the chart parameter (only when the user asks for a chart/graph), which is real guidance. However it offers no direction on when to use this versus validate_query, or on the SELECT-only constraint as a precondition, so usage context is only partially implied.

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