Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_get_planning_properties

Read the Planning Properties (TLOGO PLCR) of a plan-enabled SAP BW/4HANA InfoProvider to get key-date mode, characteristic limits, save strategy, and provider metadata.

Instructions

Read the Planning Properties (TLOGO PLCR) of a plan-enabled InfoProvider (real-time aDSO or CompositeProvider). Returns the provider name, underlying provider resource and media type, InfoArea, package, status, and the general planning settings: key-date mode, maximum number of characteristic combinations, and the save strategy (planning sequence and delta-read flag). The PLCR shares its technical name with the InfoProvider it belongs to.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNo"text" (default): readable summary. "raw": the unmodified XML.
plan_provider_nameYesTechnical name of the plan-enabled InfoProvider (e.g. "OBJECT_NAME"). The PLCR object shares this name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.8.1
    • addedInput schema / properties / format
      Added value: +{
+  "description": "\"text\" (default): readable summary. \"raw\": the unmodified XML.",
+  "enum": [
+    "text",
+    "raw"
+  ],
+  "type": "string"
+}
  2. Addedv0.9.1

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 burden of behavioral disclosure. It clearly establishes that this is a read (not a mutation) and enumerates what is returned, but says nothing about authorization prerequisites, provider-not-found behavior, or other caveats an agent might need for an aDSO/CompositeProvider read.

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?

Three sentences, front-loaded with the core action and then the return contents; no filler. The closing sentence about the shared technical name is mildly redundant with the schema description of plan_provider_name but still earns its place as context.

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 read-only, no-annotation tool with no output schema, the description supplies the full set of returned fields (name, resource, media type, InfoArea, package, status, and planning settings) so an agent knows what to expect. Only minor gaps remain, such as error behavior or permission requirements.

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 description coverage is already 100%, so the baseline is 3. The description adds value beyond the schema by defining what a valid provider is (plan-enabled, real-time aDSO or CompositeProvider) and reiterating why the name matters (the PLCR shares the InfoProvider's technical name), which clarifies the identifier parameter rather than merely repeating it.

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 (Read) and resource (Planning Properties / TLOGO PLCR) scoped to a precise provider type (plan-enabled real-time aDSO or CompositeProvider), which is enough to distinguish it from the planning_filter/sequence/function siblings. It stops short of naming any alternative tool explicitly, so it lands just under the top band.

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?

The description implies usage by stating the applicable provider types (a plan-enabled InfoProvider, i.e. real-time aDSO or CompositeProvider), which helps an agent decide when this tool is valid. However there is no explicit when-to-use vs when-not guidance and no routing to a sibling, so it remains implied rather than stated.

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

Deploy Server

Other Tools