mcp-server-db2i

Search IBM i Services

search_ibmi_services

Read-onlyIdempotent

Search IBM i SQL services in QSYS2.SERVICES_INFO to find views, functions, and procedures by keyword, category, or example. Use before writing SQL to avoid guessing names and parameters.

Instructions

Find IBM i SQL services (views, table functions, procedures, and more in QSYS2 and SYSTOOLS) in the catalog QSYS2.SERVICES_INFO, with the release that added each one and an example query. Call it before writing SQL that uses an IBM i service, instead of guessing names and parameters. With no query and no category, it lists the categories with a count each. This tool only reads the catalog. Running an example with execute_query still needs the IBM i authority the service documents and, when QUERY_ALLOWED_SCHEMAS is set, the service's schema in that list. Table functions must be qualified, as in TABLE(QSYS2.ACTIVE_JOB_INFO(DETAILED_INFO => 'NONE')), with plain values as arguments.

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Maximum services to return. Capped by QUERY_MAX_LIMIT.
`query`	No	Keywords, all of which must appear in the service name or category (case-insensitive). Example: "journal entries"
`category`	No	Exact category, such as JOURNAL, SECURITY, or WORK MANAGEMENT. Call with no arguments to list them.
`include_example`	No	Include the example query for each service. Default true.
`search_examples`	No	Also match keywords against the example queries. Default false.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`data`	No
`count`	No
`error`	No
`success`	Yes
`truncated`	No
`categories`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv3.0.0Sep 28, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint true and destructiveHint false, but the description adds that the tool only reads the catalog and explains downstream authority and schema constraints when running returned examples via execute_query. It also notes that table functions must be qualified, which is useful behavioral context beyond the 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 front-loads the core purpose, then layers in usage guidance, fallback behavior, and caveats. It is dense and mostly earns its sentences, though the downstream execute_query and qualification details make it longer than strictly necessary for a search tool.

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 the description need not explain return values. It covers the catalog source, the included metadata, the zero-argument behavior, and relevant caveats for using the returned examples, making it complete for an agent to call the tool 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 the input schema already documents all five parameters in detail. The description adds only a small amount of parameter-interaction context, such as what happens with no query and no category, which does not materially exceed the schema baseline.

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: 'Find IBM i SQL services (views, table functions, procedures, and more...)' in the named catalog QSYS2.SERVICES_INFO. It also clarifies the context of use before writing SQL that uses an IBM i service, which helps distinguish it from generic query or metadata tools.

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 clear when-to-use guidance: call it before writing SQL that uses an IBM i service instead of guessing names and parameters. It also describes the no-argument fallback behavior. It does not name alternative sibling tools for related metadata searches, so it stops short of full when-not/alternatives coverage.

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