Skip to main content
Glama
lingcSun

mcp-bw-adt-api

by lingcSun

bw_adso_add_field

Add a field to an SAP BW ADSO, with optional activation. Handles XML internally, accepts field properties like name, type, length, and scale. Returns save/activation status.

Instructions

Atomic edit: add a local 'field'-type field to an ADSO and save (activate optional via autoActivate, default true). success reflects save/activate outcome; activated only means activation was attempted. Internally reads current XML, inserts the field, and saves — no large XML handling by the caller.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
nameYesField technical name.
labelNo
scaleNo
lengthNo
dataTypeNo
dimensionNo
precisionNo
transportNo
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.
autoActivateNo
semanticTypeNo
createTransportNo
transportDescriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A4.1/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses autoActivate defaulting to true, distinguishes 'success' from 'activated', explains the internal read/insert/save flow, and notes the caller avoids large XML handling. This is unusually transparent for a mutating 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?

The description is compact and front-loaded with the most decision-relevant fact ('Atomic edit'). Every sentence adds value: operation, activation semantics, and internal mechanism. There is no filler or repetition of schema content.

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 tool with 14 parameters, no annotations, and no output schema, this description leaves too much unresolved: most parameter meanings, the exact response shape beyond the success/activated distinction, and any explicit guidance about which sibling to use instead. An agent would likely need external documentation or trial and error.

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 description coverage is only 14%, yet the description adds meaningful parameter context only for autoActivate and the general notion of 'field'. The remaining 12 parameters such as label, scale, length, dataType, precision, transport, and semanticType are undocumented in both the schema and description, so the description does not compensate for the low coverage.

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?

The description names a specific operation and resource: 'add a local 'field'-type field to an ADSO and save'. The qualifier 'local field-type' and the atomic edit framing clearly separate this from broader ADSO creation, deletion, or XML retrieval siblings.

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?

The 'Atomic edit' and 'no large XML handling by the caller' phrasing give clear context for when this tool is appropriate: small, focused field additions without manual XML plumbing. It does not explicitly name alternatives or state when not to use it, so it stops short of full routing guidance.

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