bw-modeling-mcp

bw_read

Read the definition of a single SAP BW/4HANA modeling object by type and technical name to inspect structures, mappings, queries, and planning artifacts.

Instructions

Read the definition of one BW object. type selects the object type, name is its technical name. The type enum lists every operation with what it requires; bw_describe(tool: "bw_read", type: "…") 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": {
      "type": "<type>",
      "name": "<name>"
    },
    "name": "bw_read"
  }
}

Input Schema

Name	Required	Description
`kind`	No	currency or unit; omit to try both. [conversion_type]
`name`	Yes	Technical name of the object (for a DataSource together with source_system).
`type`	Yes	Object type — one of: adso: Read an aDSO (Advanced DataStore Object) structure — fields, settings, version. \| iobj: Read an InfoObject definition (must already exist in the system). \| area: Read an InfoArea definition — name, label, parent area, object status. \| trcs: Read an InfoSource (TRCS) structure — fields, key fields, label, InfoArea, version status. \| trfn: Read a Transformation structure — source/target segments, mapping rules. \| dtpa: Read a DTP (Data Transfer Process) definition — source, target, transformation, extraction settings, and filter fields (selections and routines). \| query: Read a BW Query definition — variables, filter, layout (rows/columns/free characteristics), calculated and restricted measures, exceptions, and cell definition… \| hcpr: Read a CompositeProvider (HCPR) structure — general info, view node type (Union/Join), source providers (inputs) with mapping counts, fields with their field g… \| ckf: Read a global Calculated Key Figure (CKF) defined at CompositeProvider level. \| rkf: Read a global Restricted Key Figure (RKF) defined at CompositeProvider level. \| structure: Read a global Structure defined at CompositeProvider level. \| variable: Read a reusable BW Variable: reference characteristic, description, variable type, processing type, selection type, input type, input readiness, reusability, p… \| rsds: Read the full structure of a DataSource (RSDS) — metadata, all fields with types and properties, and adapter configuration. Requires source_system. \| lsys: Read the metadata of a single logical source system (LSYS) — type, description, connection details, and maintenance properties. \| dest: Read an Open Hub Destination (TLOGO DEST) definition — destination type, DB table, InfoArea, package, status, database properties (write mode, technical key, c… \| rspc: Read a Process Chain (RSPC) definition — header metadata, scheduling and monitoring settings, all steps (nodes) with type, variant, and last execution status,… \| process_variant: Read the detail configuration of a single Process Variant from a Process Chain step. Requires process_type. \| alvl: Read an Aggregation Level (TLOGO ALVL) definition — the planning-enabled view on top of an InfoProvider (aDSO or CompositeProvider) used for Integrated Plannin… \| plse: Read a Planning Function (TLOGO PLSE) definition — a planning operation (formula/FOX, copy, delete, repost, distribution, currency translation, custom exit, …)… \| plsq: Read a Planning Sequence (TLOGO PLSQ) definition — an ordered list of planning steps for Integrated Planning / embedded BPC. \| planning_filter: Read a planning filter — the selection a planning sequence step or an input template works on. \| planning_properties: Read the Planning Properties (TLOGO PLCR) of a plan-enabled InfoProvider (real-time aDSO or CompositeProvider). \| conversion_type: Read a currency translation type (TLOGO CTRT) or a unit conversion type (TLOGO UOMT): source and target (fixed, from the record or chosen when converting, from… \| hierarchy: Read the hierarchies of a characteristic. \| push_schema: Fetch the JSON schema for an aDSO write interface. \| afo_workbook: Fetch one Analysis for Office workbook stored in BW, as Analysis for Office opens it, without locking it. \| query_roles: Get all roles and folders where a specific BW query is currently published.
`format`	No	Defined per operation — bw_describe(tool: "bw_read", type: "…") gives each definition. [15 of 27 operations]
`version`	No	A = active (default where it exists), M = revised version. [hierarchy]
`overwrite`	No	Replace an existing file at save_path (default false). [afo_workbook]
`save_path`	No	Local file or directory to save the workbook to. [afo_workbook]
`process_type`	No	Process type technical name from the chain step (e.g. [process_variant]
`source_system`	No	Logical source system name (e.g. [rsds]
`hierarchy_name`	No	Hierarchy to read. [hierarchy]
`include_content`	No	Return the file as base64 (default false). [afo_workbook]
`include_variant_details`	No	If true (default), fetches variant configuration detail for each step automatically and includes it inline. [rspc]

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?

With no annotations, the description carries the full disclosure burden, and 'Read the definition' does establish the operation as non-mutating. It adds a useful pointer that the type enum documents each operation's requirements, but it says nothing about error cases (e.g. an InfoObject that must already exist), output shape, or the fact that the afo_workbook operation writes a file to save_path. Adequate but thin for a 27-variant polymorphic 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?

Three short sentences, front-loaded with the core action, then the field roles, then the escape hatch for deeper parameter detail. No filler or repetition.

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 12-parameter, 27-operation tool with no output schema, the description orients the agent correctly and delegates detail to two rich structured sources (the per-type enum and bw_describe). The main remaining gap is return-value framing, but the enum descriptions already sketch what each operation returns.

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% and the type enum already spells out each operation and its extra requirements, so the baseline is 3. The description adds only marginal meaning — clarifying that name is the 'technical name' and that type selects the object type — while the other ten parameters are left entirely to 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?

States a specific verb and resource ('Read the definition of one BW object') and immediately clarifies the two driving fields (type, name). It also implicitly separates itself from the similarly named bw_describe by assigning that tool the job of describing parameter definitions rather than objects. It stops short of explicitly contrasting with bw_find/bw_data, so a 4 rather than 5.

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?

Usage is only implied: you call it to inspect a single object's definition, and the description routes the agent to bw_describe when per-type parameter details are needed. There is no explicit when-not guidance (e.g. use bw_find to locate an object, bw_data to read its contents), leaving the choice between siblings to inference.

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