bw-modeling-mcp

bw_write_datasource

Create an SAP BW/4HANA DataSource, configure field transfer flags, or change its delta process using operation-specific parameters.

Instructions

Create a DataSource, set its fields, change its delta process. The operation enum lists every operation with what it requires; bw_describe(tool: "bw_write_datasource", 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_write_datasource"
  }
}

Input Schema

Name	Required	Description
`fields`	No	Fields to change and their target transfer flag. [set_fields]
`operation`	Yes	Operation — one of: create: Create a DataSource (RSDS) on top of a remote entity from the server's field proposal, leaving it inactive. Requires datasource_name, source_system, application_component. \| set_fields: Set the transfer flag of one or more DataSource fields (fieldProperties@transfer) and/or the segment language field designation. Requires datasource_name, source_system. \| change_delta: Change the delta process of a DataSource (RSDS deltaProperties). Requires datasource_name, source_system, delta_process.
`transport`	No	Transport request (e.g. [set_fields]
`description`	No	DataSource description (default: the hana_entity value). [create]
`hana_entity`	No	Remote entity technical name (technicalName from bw_list_remote_entities), bound as the adapter externalObjec… [create]
`delta_process`	No	Target delta process code (e.g. [change_delta]
`source_system`	No	Defined per operation — bw_describe(tool: "bw_write_datasource", operation: "…") gives each definition.
`language_field`	No	g. [set_fields]
`datasource_name`	No	Defined per operation — bw_describe(tool: "bw_write_datasource", operation: "…") gives each definition.
`application_component`	No	Application component (APCO) to file the DataSource under (e.g. [create]

Schema Changelog

Changes observed during successful MCP inspections.

Addedv2.0.0Nov 12, 2026

TDQS

B3.2/5.0

Behavior2/5

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

No annotations exist, so the description carries the full behavioral burden, and it discloses little beyond the operation names. It does not mention that create leaves the DataSource inactive (only the schema enum does), nor permissions, reversibility, or side effects; it defers detail to bw_describe and the schema instead of describing effects.

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?

Two tight sentences, front-loaded with the three operations before the pointer to the enum and bw_describe. No wasted wording, though the second sentence is somewhat cryptic in isolation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 10 parameters, no annotations, and no output schema, the description is adequate for selecting the operation but thin on mutation risk and prerequisites. It reasonably delegates parameter detail to the rich schema and bw_describe, but leaves behavioral completeness partly unaddressed.

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 coverage is 100% and the schema already documents per-operation requirements and parameter meanings. The description adds the meta-guidance to call bw_describe for full definitions, but no new param semantics beyond the schema, so baseline 3 applies.

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 three specific operations (create, set_fields, change_delta) against a specific resource, a DataSource. This makes the tool distinguishable from sibling write tools like bw_write_adso or bw_write_infosource by resource, though it doesn't explicitly contrast with them.

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?

It gives routing guidance: consult the operation enum for requirements and call bw_describe for one operation's full parameter definition. However, it offers no explicit when-to-use-this vs another write tool, and no exclusions or prerequisites.

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