bw-modeling-mcp

bw_data

Filter characteristic values, preview DataSource rows, push records into an aDSO write interface, selectively delete aDSO data, or save Analysis for Office workbooks in SAP BW/4HANA.

Instructions

Work with data rather than definitions: filter values, DataSource preview, push into a write-interface aDSO, selective deletion, save an Analysis for Office workbook. The operation enum lists every operation with what it requires; bw_describe(tool: "bw_data", 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_data"
  }
}

Input Schema

Name	Required	Description
`mode`	No	Push mode. [push]
`name`	No	Technical name to save under (e.g. [save_afo_workbook]
`role`	No	Role whose menu the workbook is added to (e.g. [save_afo_workbook]
`folder`	No	Folder path inside the role menu, separated by "/" (e.g. [save_afo_workbook]
`records`	No	Defined per operation — bw_describe(tool: "bw_data", operation: "…") gives each definition. [preview_datasource, push]
`job_name`	No	Name of the background job (default: BW-generated). [delete_selective]
`max_rows`	No	Maximum number of values to return (default 201). [filter_values]
`simulate`	No	Only count the matching records, delete nothing (default true). [delete_selective]
`adso_name`	No	Defined per operation — bw_describe(tool: "bw_data", operation: "…") gives each definition. [push, delete_selective]
`file_path`	No	Local .xlsx/.xlsm file to save. [save_afo_workbook]
`operation`	Yes	Operation — one of: filter_values: Look up valid characteristic values for use in query filters or variable inputs. Requires characteristic_name, search_string. \| preview_datasource: Fetch a live data preview / sample rows from a DataSource (RSDS) — reads the first N rows directly from the source system and returns them as a formatted table… Requires datasource_name, source_system. \| push: Push data records directly into an aDSO inbound table via the SAP BW/4HANA write interface. Requires adso_name, records. \| delete_selective: Selectively delete records from an aDSO by conditions on its characteristics, or simulate the deletion to count the matching records. Requires adso_name, conditions. \| save_afo_workbook: Save an Analysis for Office workbook to BW, as Analysis for Office does, and optionally place it in a role menu. Requires name.
`overwrite`	No	Replace an existing workbook of the same name (default false). [save_afo_workbook]
`conditions`	No	At least one condition. [delete_selective]
`description`	No	Workbook text, at most 60 characters. [save_afo_workbook]
`info_provider`	No	Optional. [filter_values]
`search_string`	No	Wildcard search pattern. [filter_values]
`source_system`	No	Logical source system name (e.g. [preview_datasource]
`content_base64`	No	The workbook as base64, instead of file_path. [save_afo_workbook]
`force_deletion`	No	Force the deletion where BW otherwise refuses it (default false). [delete_selective]
`datasource_name`	No	DataSource name (e.g. [preview_datasource]
`propagate_deletion`	No	The cockpit option "Propagate deletion" (default false). [delete_selective]
`characteristic_name`	No	InfoObject technical name to get values for (e.g. [filter_values]

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 12, 2026

TDQS

A3.9/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden, and it does not itself disclose the safety profile of this mixed read/write tool: push, delete_selective, and save_afo_workbook are mutations, yet irreversibility, required authorizations, and side effects on existing data are not stated. It does route the agent to the operation enum, where details such as 'reads the first N rows directly from the source system' and simulate-delete behavior live, which is meaningful delegation. The gap is that destructive-operation risk is never surfaced in the description proper.

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, both load-bearing: the first establishes the data-vs-definitions scope and enumerates operations; the second establishes the lookup protocol for parameters. The operation list is front-loaded and nothing is padded or repeated.

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 five-operation, 22-parameter dispatcher, the definition correctly avoids restating the schema and instead states the two things an agent cannot derive from structured fields alone: how the operations are scoped and where to get per-operation parameter definitions. No output schema exists, and return behavior is only hinted inside the enum ('returns them as a formatted table'), so response shape for push, delete_selective, and save_afo_workbook remains undisclosed.

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 coverage is 100%, so the baseline is 3, but the description adds genuinely useful structure by telling the agent that parameter meaning is operation-scoped and pointing to bw_describe for per-operation definitions. That clarifies why 22 parameters with cross-operation applicability (e.g. records and adso_name meaning different things per operation) cannot be read as a flat union. It does not add syntax or format detail beyond that pointer.

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 broad domain ('work with data rather than definitions') and then enumerates the five concrete operations: filter values, DataSource preview, aDSO push, selective deletion, and AFO workbook save. The 'rather than definitions' framing distinguishes it from definition-oriented siblings like bw_describe. It stops short of distinguishing bw_data's push from the several bw_write_* siblings, which is the main sibling overlap left unresolved.

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?

It gives a clear routing rule: the operation enum carries per-operation requirements, and bw_describe(tool: "bw_data", operation: "…") provides the full parameter definition for the chosen operation. That 'consult describe before calling' instruction is concrete and actionable. There are no explicit when-not conditions or comparisons against bw_write_adso or bw_query_data, so an agent must infer any overlap.

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