mcp-server-db2i

Execute SQL Query

execute_query

Read-onlyIdempotent

Run read-only SQL SELECT queries against IBM Db2i to fetch data safely, with row limits 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.

Input Schema

TableJSON Schema

Name	Required	Description
`sql`	Yes	SQL SELECT query to execute
`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

TableJSON Schema

Name	Required	Description
`data`	No
`cause`	No	Why the statement failed. &1-style placeholders stand for values in error.
`error`	No
`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
`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.

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

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered structurally. The description adds two useful behavioral facts beyond the annotations: the SELECT-only security restriction and that result sets are capped by default. It does not disclose the actual default limit value, failure behavior, or timeout characteristics.

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?

Three short sentences, front-loaded with the core action and immediately followed by the key constraint. Every sentence carries information, though the final sentence is slightly redundant with the limit parameter already described in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/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. However, for a query-execution tool surrounded by validate_query and schema-introspection siblings, the description omits error-handling expectations and any guidance on validating queries first, leaving minor gaps for correct invocation in a workflow.

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 sql, limit, and params are already documented in the schema, which sets the baseline at 3. The description adds only marginal meaning for 'limit' by noting results are limited by default, but it does not explain parameter binding syntax for 'params' or the practical impact of the default cap.

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?

The description states a specific verb and resource ('Execute a read-only SQL SELECT query against the IBM Db2i database'), making the operation instantly recognizable. It does not, however, explicitly distinguish itself from the sibling validate_query, which an agent might reasonably consider for the same SQL text.

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?

It implies usage through the constraint 'Only SELECT statements are allowed for security,' which tells the agent this is for querying rather than DDL/DML. There is no explicit when-to-use clause and no mention of when to prefer validate_query, list_tables, or search_tables instead.

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