bw-modeling-mcp

bw_monitor

Monitor SAP BW/4HANA loads, process chain runs, remodeling requests, and query statistics to inspect status, timings, and execution details.

Instructions

Monitor loads and runs: requests, process chain runs and their steps, remodeling requests, query statistics. The operation enum lists every operation with what it requires; bw_describe(tool: "bw_monitor", operation: "…") gives the complete parameter definition of one.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "operation": "<operation>"
    },
    "name": "bw_monitor"
  }
}

Input Schema

Name	Required	Description
`to`	No	End of the window (default now). [query_statistics]
`top`	No	Defined per operation — bw_describe(tool: "bw_monitor", operation: "…") gives each definition. [requests, remodeling_requests]
`from`	No	Start of the window, ISO date or timestamp (UTC unless an offset is given). [query_statistics]
`hours`	No	Window length when from is not given (default 24). [query_statistics]
`limit`	No	Defined per operation — bw_describe(tool: "bw_monitor", operation: "…") gives each definition. [chain_runs, chain_last_status]
`format`	No	Defined per operation — bw_describe(tool: "bw_monitor", operation: "…") gives each definition. [request, remodeling_request]
`log_id`	No	Run log ID from bw_list_process_chain_runs or bw_list_process_chain_last_status (logId field). [chain_run_detail]
`status`	No	Defined per operation — bw_describe(tool: "bw_monitor", operation: "…") gives each definition. [4 of 8 operations]
`target`	No	Target InfoProvider technical name (e.g. [requests]
`date_to`	No	Optional upper bound for run start date (ISO format). [chain_runs]
`slowest`	No	How many of the slowest executions to break down (default 3, at most 10, 0 for none). [query_statistics]
`storage`	No	Defined per operation — bw_describe(tool: "bw_monitor", operation: "…") gives each definition. [requests, request]
`chain_id`	No	Process chain technical name (e.g. [chain_run_detail]
`provider`	No	InfoProvider queried directly, as bw_query_data with is_provider does (e.g. [query_statistics]
`step_uid`	No	One navigation step, as shown in an earlier answer. [query_statistics]
`date_from`	No	Optional lower bound for run start date (ISO format, e.g. [chain_runs]
`operation`	Yes	Operation — one of: requests: List the recent load requests of an InfoProvider from the runtime request monitor, with decoded request status, record counts and timestamps. Requires target. \| request: Full status analysis of one load request in a single call, bundling the request header, DTP information (including start, finish and duration), the process ste… Requires request_tsn. \| chain_runs: List execution runs of one or all process chains from the process chain monitoring log. \| chain_run_detail: Read the execution detail of one process chain run — all process steps with type, variant, status, timestamps, and parent/child relationships (predecessor grap… Requires chain_id, log_id. \| chain_last_status: Read the latest execution status and scheduling state for every process chain in the system — one row per chain. \| remodeling_requests: List remodeling requests from the remodeling monitor, with decoded status, last run and creator. \| remodeling_request: Full status of one remodeling request: header, the five processing steps (CHECK, SAVE, CONVERT, ACTIVATE, CLEANUP) with their individual status, and the applic… Requires info_provider, remodeling_rule. \| query_statistics: Read the BW query statistics (RSDDSTAT) of any frontend, as RSRT statistics and ST03 show them, without SAP GUI.
`chain_name`	No	Optional process chain technical name to restrict to runs of a single chain (e.g. [chain_runs]
`query_name`	No	Query whose executions to read (e.g. [query_statistics]
`include_log`	No	Include the application log messages (default true). [remodeling_request]
`request_tsn`	No	Internal request TSN from bw_list_requests output. [request]
`target_type`	No	Target object type (default "ADSO"). [requests]
`created_from`	No	g.000Z"). [requests]
`info_provider`	No	Defined per operation — bw_describe(tool: "bw_monitor", operation: "…") gives each definition. [remodeling_requests, remodeling_request]
`last_start_to`	No	Optional upper bound for last run start date (ISO format). [chain_last_status]
`request_number`	No	Optional request GUID from bw_list_remodeling_requests output. [remodeling_request]
`last_start_from`	No	Optional lower bound for last run start date (ISO format, e.g. [chain_last_status]
`remodeling_rule`	No	Remodeling rule ID, from bw_list_remodeling_requests output. [remodeling_request]
`include_warnings`	No	Also show long text, variables and program location for warnings, not only for errors (default false). [chain_run_detail]

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 12, 2026

TDQS

A3.6/5.0

Behavior3/5

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

No annotations are supplied, so the description carries the full burden. 'Monitor' reasonably conveys a read-only surface, and the enum entries disclose per-operation requirements and return content (decoded status, record counts, timestamps). Beyond that, nothing is said about permissions, side effects, result size, or pagination, which is a real gap for a 29-parameter tool.

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?

Two sentences with no waste, front-loading the scope of monitoring domains and following with the discovery path. Every sentence earns its place and nothing is redundant with the structured fields.

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?

For a multiplexed tool with eight operations and no output schema, the description supplies the domain overview and routes the agent to the enum and bw_describe for per-operation detail, which is the right division of labor. What is missing is any statement of the tool's read-only safety profile or result-size expectations, which matter when no annotations exist.

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 baseline is 3. The description adds a discovery strategy (consult the enum, then bw_describe) rather than explaining individual parameters, which is acceptable given that every parameter is already annotated with its applicable operation in the schema.

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 names a specific verb (monitor) and enumerates the four resource domains it covers: load requests, process chain runs and steps, remodeling requests, and query statistics. An agent can tell this is a read-side monitoring surface rather than a write tool. It stops short of naming sibling alternatives (bw_read, bw_query_data) in the description itself, so differentiation relies on the enum 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?

There is clear procedural guidance: pick an operation from the enum, then call bw_describe for the full parameter definition of that operation. That is useful workflow instruction. However, there is no stated condition for choosing bw_monitor over bw_read or bw_query_data, so the when-to-use guidance against alternatives is only implied by the domain list.

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