Skip to main content
Glama
dnic-dev

bw-modeling-mcp

by dnic-dev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

bw_get_planning_function

Read a planning function (TLOGO PLSE) definition for SAP BW/4HANA Integrated Planning/BPC, returning its type, aggregation level, parameter tree, FOX code, and characteristic roles.

Instructions

Read a Planning Function (TLOGO PLSE) definition — a planning operation (formula/FOX, copy, delete, repost, distribution, currency translation, custom exit, …) tied to an aggregation level for Integrated Planning / embedded BPC. Returns name, description, function type (planningServiceType), aggregation level, documentation, status, InfoArea, package, the characteristic usage list (role of each characteristic in the function), and the full parameter tree with nested structure and values. For FORMULA functions the FOX code surfaces as the value of the FLINE parameter. The block characteristics — every characteristic that is not to be changed — are listed separately: the function runs once per combination of their values, so records that differ in one of them never meet in the same call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formatNo"text" (default): readable summary. "raw": the unmodified XML.
planning_function_nameYesTechnical name of the Planning Function (e.g. "OBJECT_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.7/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the full behavioral burden. It does add real context — the returned field set, the fact that FOX code surfaces as the FLINE parameter value, and the execution semantics of block characteristics (function runs once per combination, records differing in them never meet) — but it never explicitly confirms the operation is read-only/side-effect-free, which an unannotated tool should state.

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?

Purpose is front-loaded in the first clause, and with no output schema the long return-field enumeration largely earns its place. Still, it is a single dense paragraph with stacked em-dash clauses, and the block-characteristics explanation could be tightened.

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 low-complexity read tool with no output schema, the description is thorough about the return payload, which is exactly what is needed. The one gap is that it omits the format=raw option that changes the response shape to unmodified XML.

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%, with both parameters fully documented in the schema (including the text/raw enum), so baseline is 3. The description adds nothing about parameters — it never mentions the format switch or the raw XML option — and its FLINE reference concerns the response, not input.

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?

States a precise verb+resource ('Read a Planning Function (TLOGO PLSE) definition') and immediately scopes it as a planning operation tied to an aggregation level for Integrated Planning / embedded BPC, which separates it from siblings like bw_get_planning_filter, bw_get_planning_sequence and bw_get_aggregation_level.

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 conveys what a planning function is and some internal semantics, so usage is implied, but it never says when to choose this over bw_get_planning_filter, bw_get_planning_sequence, bw_get_planning_properties or bw_update_planning_function, nor any prerequisites.

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