Request for Documentation on MCP Server Function Capabilities

[Summary]

The MCP Server function became available starting with CICS TS V6.3; however, the current documentation does not provide sufficient detail about the toolset exposed by the CICS MCP Server. While it is possible to build a CICS TS V6.3 environment, configure an MCP Server, and inspect available tools from the MCP Client, this approach requires standing up a full runtime environment. Without doing so, it is not possible to understand in advance the specific capabilities of the MCP Server or the tools it provides.
Additionally, tool availability differs between single-region deployments and CICSPlex environments, but the official documentation does not clearly describe these differences. This lack of visibility makes it difficult to design, plan, and develop AI agents that rely on the capabilities the MCP Server exposes—specifically, what information can be retrieved and what responses can be expected from each tool.
I would like to respectfully request comprehensive official documentation that describes the capabilities, parameters, and expected responses of the MCP tools exposed by the CICS MCP Server. While runtime introspection via tools/list is helpful, it does not adequately support teams who must design, review, and govern AI agents prior to provisioning or connecting to a live CICS environment.

[Why this documentation is necessary]

Architecture and design planning (pre‑deployment):
Designing agent logic, prompt strategies, guardrails, and testing frameworks requires knowing what tool categories exist, what each tool does, and the typical input/output patterns. Without this information, architectural decisions become speculative and may fail internal design reviews or security assessments.

Versioning and maintenance governance:
Tool capabilities may change based on release or PTF level, affecting agent behavior, regression risk, and required test coverage. To maintain stable and reliable agents, teams need clear documentation of tool availability and parameter/response contracts for each supported release/PTF.

Security and compliance reviews:
Even when tools are read‑only, security teams require documented scope of access, including resource classes exposed, metadata available, rate/size limits, and auditability. These requirements cannot be satisfied through runtime discovery alone.

Cross‑environment consistency:
In environments that span both single‑region and CICSPlex deployments, teams must understand expected differences in available tools and behaviors in order to plan fallback logic and ensure a consistent user experience. Stable reference documentation is essential for this planning.