Skip to main content
Glama
lingcSun

mcp-bw-adt-api

by lingcSun

bw_adso_create

Create an empty ADSO shell for SAP BW/4HANA by providing name, description, and info area. Add fields later via dedicated tool.

Instructions

Create an empty ADSO shell (fields are added afterwards via bw_adso_add_field). Required: name, description, infoArea.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
infoAreaYes
readOnlyNo
templateNo
outputPathNoIf provided, the full result is written to this path (under the workdir) and the tool returns only a small summary envelope { ok, outputPath, bytes, summary }. Objects/arrays are written as JSON; ONLY the bw_*_get_xml family writes the raw XML string as plain text (that file is directly reusable as xmlPath in a later save call). Other *_get tools (e.g. bw_dtp_get, bw_trfn_get) write the PARSED XML-to-JSON tree, not raw XML — use the matching bw_*_get_xml tool when you need the raw XML string. Use outputPath for large responses (XML, table data, logs, dataflow graphs). When set, tools skip inline pagination/projection so the file contains the complete payload.
descriptionYes
responsibleNoDefault = current user.
activateDataNo
autoActivateNoDefault false.
masterSystemNoDefault BPD.
masterLanguageNoDefault EN.
writeChangelogNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

B3.3/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, permission requirements, validation behavior, or what happens on conflicts. For a state-changing creation tool, this is a significant gap.

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?

A single sentence that directly states the purpose and the required fields. No filler, front-loads the key information, and efficiently communicates the core action and the next step.

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

Completeness2/5

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

For a creation tool with 12 parameters, a nested template object, and no output schema, this description is too sparse. It omits return value details, activation behavior (though schema has defaults), preconditions, and how it fits with the broader tool family beyond the field-add step. The minimal hint about the follow-up tool is helpful but leaves critical context unaddressed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 42%, so many parameters (template, readOnly, activateData, writeChangelog) lack inline descriptions. The description merely lists the required fields without adding meaning beyond the schema's required array. It does not explain what name, description, or infoArea represent or how they are used, failing to compensate for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description names a specific verb ('Create') and resource ('empty ADSO shell'), and explicitly says fields are added later via bw_adso_add_field, which distinguishes it from other ADSO tools like bw_adso_details or bw_adso_get_xml. It clearly identifies this as the creation step in a multi-step process.

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?

Provides a usage hint by naming the follow-up tool (bw_adso_add_field) and indicating that fields are added after creation. However, it does not explicitly state when to use this vs. other creation tools (e.g., bw_area_create, bw_trfn_create) or any exclusions. The context is implied rather than explicit.

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