Provides tools for modeling and operating SAP BW/4HANA through the BW Modeling Tools REST interface, including object search/read/write/activation, data queries, process monitoring and runtime actions, transports, and safety-scoped administration.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@coBWeb create an ADSO for sales orders and activate it"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server for modeling in SAP BW/4HANA. coBWeb talks to the REST interface of the BW
Modeling Tools (/sap/bw/modeling/…) and gives a language model eleven intent-based tools:
search, read, write, activate, data, monitoring, runtime actions and transports. It does not
offer one tool per object type and operation.
The design goal is a small, stable tool list that costs few input tokens on every step, and writes that finish a task in few calls:
Few tools, small schemas. The whole catalog has 11 tools and about 16,200 characters
(roughly 4,600 tokens). The default profile modeling has 8 tools and about 10,600 characters.
One call per change. bw_write takes several objects at once (InfoObjects, a DataStore
object, a CompositeProvider, a transformation and its DTP), orders them by dependency, locks,
saves, activates and unlocks. The model never handles lock handles or sessions.
Declarative specs. An object is described by a spec; the same spec again reports
unchanged. bw_describe returns the spec format of a type.
Compact answers. Reads return a summary first; detail and part give more on request.
Errors say what to change.
Safe by default. Without flags the server only reads. Writes, data access and runtime actions are switched on separately and limited to packages and InfoAreas you allow.
Tool | Purpose |
| find objects by name or description; list an InfoArea |
| read one object: summary, full or raw; |
| data flow and where-used of an object in one answer |
| the spec format |
| create, update, delete several objects and activate them in one call; |
| check or activate inactive objects |
| query data (rows, columns, filters, variables, hierarchy nodes), DataSource preview, characteristic values |
| process chain runs, load requests, remodeling requests, query statistics |
| run a DTP, start a process chain, activate or delete requests, remodeling, push data into an ADSO |
| changeable transport requests, transport tasks, package assignment, moving objects between InfoAreas |
| system profile and active safety settings; release a lock after an aborted change |
Parameters and examples: docs/TOOLS.md.
Related MCP server: bw-modeling-mcp
Code | Object | Read | Write |
| InfoArea | ✔ | create, update, delete |
| InfoObject (characteristics, key figures, attributes, compounding, hierarchies) | ✔ | create, update, delete |
| DataStore object (advanced) incl. fields without InfoObject, keys, settings, planning | ✔ | create, update, delete |
| CompositeProvider (union, join), mappings, field groups | ✔ | create, update, delete |
| InfoSource | ✔ | create, update, delete |
| Transformation: rules, lookups, start, end and expert routines, runtime | ✔ | create, update, delete |
| Data transfer process: mode, filters, filter routines, semantic groups | ✔ | create, update, delete |
| DataSource: fields, delta | ✔ | create, update, delete |
| Source system and its entities | ✔ | – |
| Process chain: steps, decisions, scheduling; settings of each process variant | ✔ | create, update, delete |
| Query: layout, filter, members, characteristics, settings, cells, roles | ✔ | create, update, delete |
| Query components | ✔ | create, update, delete |
| Aggregation level, planning filter, planning function, planning sequence | ✔ | create, update, delete |
| Hierarchy of a characteristic ( | ✔ | create, update, delete |
| Open Hub destination | ✔ | delete |
| Roles and the queries published in them | ✔ | via the query ( |
coBWeb is developed and tested on SAP BW/4HANA 2.0 and later. The platform is detected at start; classic BW 7.5 on HANA is recognized but not supported.
Requirements: Node.js 22 or later; a BW/4HANA system with the BW Modeling Tools services active and a user with modeling authorization.
git clone https://github.com/oliverluette/coBWeb-mcp.git
cd coBWeb-mcp
npm install
npm run buildAll settings are environment variables of the server process.
Connection:
Variable | Meaning |
| base URL of the BW system, e.g. |
| logon (basic authentication) |
| client, default |
| instead of user and password: cookies of a browser session (e.g. SAML) |
|
|
Tools and safety (all optional; without flags the server is read-only):
Variable | Default | Meaning |
|
| tool set: |
| – | explicit tool list, overrides the profile |
| all | allowed object types, e.g. |
|
| create, change, delete, activate, transports, unlock |
|
| read business data ( |
|
| runtime actions ( |
|
| packages writes may go to; patterns with |
|
| InfoAreas objects may be created in or changed |
| – | single actions to refuse, e.g. |
|
| upper bound of every tool result |
| – | file for the audit log (one JSON line per written object) |
|
|
|
Profiles:
Profile | Tools |
| search, read, context, describe, write, activate, transport, system |
| search, read, context, data |
| search, read, monitor, run, system |
| all eleven |
Tools that a profile or the flags leave out are not offered at all, so the model never sees
them. bw_system(action="profile") shows the active settings.
In claude_desktop_config.json:
{
"mcpServers": {
"cobweb": {
"command": "node",
"args": ["/path/to/coBWeb-mcp/dist/transport/stdio.js"],
"env": {
"BW_URL": "https://…",
"BW_USER": "…",
"BW_PASSWORD": "…",
"BW_CLIENT": "001",
"COBWEB_PROFILE": "modeling",
"COBWEB_ALLOW_WRITES": "true"
}
}
}
}Restart Claude Desktop after a change.
claude mcp add cobweb --env BW_URL=https://… --env BW_USER=… --env BW_PASSWORD=… --env BW_CLIENT=001 \
-- node /path/to/coBWeb-mcp/dist/transport/stdio.jsAny host that starts stdio servers works: command node, argument
dist/transport/stdio.js, and the environment variables above.
Command | Purpose |
| compile TypeScript to |
| type check without output |
| print the tool list a profile offers (JSON) |
| development launcher: runs the server as a child and restarts it before the next tool call when |
For development, point the host's args at scripts/dev-reload.mjs instead of
dist/transport/stdio.js; a new build then takes effect without restarting the host. A changed
tool list is announced with notifications/tools/list_changed; hosts that do not read it again
need a restart for that.
How the server is built: docs/ARCHITECTURE.md.
coBWeb started as a fork of bw-modeling-mcp
(MIT License). It keeps that project's BW client and its write, reporting and runtime paths
for the BW REST services (src/legacy/, parts of src/bw/), changed where needed; the tool
design, object adapters, write engine and policy are new. The details are in NOTICE.
Show how a BW object is connected: relation="dataflow" lists sources and targets with the transformations and DTPs between them; "where_used" lists objects that reference it (impact before a change). Use it instead of reading many objects one by one. depth controls how many hops are followed.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| type | Yes | ||
| depth | No | ||
| relation | No | dataflow | |
| direction | No | both | |
| source_system | No | Only for RSDS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuine value beyond that by disclosing what each relation actually returns (transformations and DTPs between objects) and framing where_used as change-impact analysis, which matters given there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Compact and front-loaded: the core capability comes first, then the two mode definitions, then the routing advice, then the depth note. Every clause adds information and nothing is repeated from the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter traversal tool with no output schema, the description covers purpose, both relation modes, return content and hop depth, which is close to sufficient. The omission of direction semantics is the main gap, but annotations cover the safety side and no return values need explaining beyond what is stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at only 17%, the description is expected to carry more, and it does explain relation's two enum values and that depth controls hop count. However, direction (up/down/both) and source_system are left entirely to the bare schema, and depth's 1-5 bounds are not reinforced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (show how a BW object is connected) and precisely delineates the two modes: relation="dataflow" returns sources/targets plus the transformations and DTPs, while "where_used" returns referencing objects. An agent can tell this apart from plain object reading without inspecting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it instead of reading many objects one by one" explicitly routes the agent away from iterative reads (bw_read), and "impact before a change" gives the decision context for where_used. It does not state any when-not conditions or name the sibling tools directly, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the spec format bw_write expects for one object type and action: allowed fields, data types, defaults, rules and a minimal example. Call it once per type before the first bw_write of that type; the result does not change during a session.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | AREA InfoArea, IOBJ InfoObject (characteristic, key figure), ADSO DataStore object, HCPR CompositeProvider, TRCS InfoSource, TRFN transformation, DTPA data transfer process (DTP), RSDS DataSource, RSPC process chain, QUERY query, VARIABLE query variable, CKF calculated key figure, RKF restricted key figure, STRUCTURE query structure, ALVL aggregation level, FILTER planning filter, PLSE planning function, PLSQ planning sequence, HIER hierarchy, DEST Open Hub destination | |
| action | No | create |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-open-world and non-destructive; the description adds session-stable caching semantics and the shape of the returned spec, which the annotations do not convey. It stops short of stating anything about cost, auth, or size of the returned spec.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the return value and followed by the call-frequency rule. No filler or restatement of the name or title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must describe the return value, and it does so concretely (fields, types, defaults, rules, example). Combined with the per-type/per-action scoping rule, an agent has everything needed to call it correctly and at the right time.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50%: the type enum is richly documented in the schema, while action (create/update) has no schema description. The description only notes that the spec varies by action, without explaining what differs between a create spec and an update spec, so it does not fully compensate for the gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Return) and a specific resource (the spec format bw_write expects for one object type and action), then enumerates what the payload contains: allowed fields, data types, defaults, rules, minimal example. This is clearly distinguishable from the read/search/system siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger ('Call it once per type before the first bw_write of that type') and an explicit anti-pattern ('the result does not change during a session', i.e. do not re-fetch). Both when-to-use and when-not-to-use are covered without inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the definition of one BW object. detail="summary" (default) returns a compact, model-friendly overview (fields, keys, settings, status); "full" adds every property; "raw" returns the backend XML/JSON and should only be used for debugging. Use part to read only one section of a large object, e.g. fields, keys, rules, steps, layout.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Technical name. | |
| part | No | Optional section filter, e.g. fields, keys, rules, routines, steps, layout, filter. | |
| type | Yes | ||
| detail | No | summary | |
| source_system | No | Only for RSDS. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine behavioral detail beyond that: what each detail level actually returns (compact overview vs every property vs backend XML/JSON) and the cost implication of raw. It stops short of noting size/performance characteristics for full on large objects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core action, then detail levels, then part. Every clause conveys actionable information with no restatement of the title or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description covers what each detail level returns, which is the main thing an agent needs. Gaps are modest: interaction between part and detail, and any guidance on object type values, but neither blocks correct invocation for a 5-param read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 60% schema coverage, the description carries real weight and does: it defines all three detail values and explains part as a section filter with concrete examples (fields, keys, rules, steps, layout). The large type enum (AREA, IOBJ, ADSO, ...) is left unexplained in both schema and description, and source_system is only tagged 'Only for RSDS' in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Read the definition of one BW object.' Clear enough that an agent knows exactly what it retrieves. However, it does not distinguish itself from siblings like bw_describe or bw_context, which an agent could reasonably confuse with reading an object's definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives useful in-tool guidance — raw 'should only be used for debugging' and 'use part to read only one section of a large object' — including an explicit when-not for raw. But it never says when to pick bw_read over bw_describe, bw_context, or bw_search, so tool-level routing is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find BW objects by technical name or description, or list the contents of an InfoArea. Use it when you do not know the exact name or want to check that a name is free. Wildcard * is allowed. Returns type, name, description and active state, at most limit hits plus a total count.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | Name or text pattern, e.g. ZSALES* or *revenue*. Omit to list info_area. | |
| types | No | Restrict to these object types. | |
| info_area | No | List the objects in this InfoArea (one level). | |
| source_system | No | Only DataSources of this source system. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, non-destructive, closed-world. The description adds real value beyond them: wildcard support, the returned fields (type, name, description, active state), and the truncation contract of `limit` hits plus a total count. No auth or scoping caveats, but little is left unclear for a safe read.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: capability first, when-to-use second, output/pagination contract last. Every sentence carries distinct information with no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly spells out returned fields and the total-count/limit behavior, which is the main thing an agent needs. The gap is coverage of the type filter and source_system scoping, which affect what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 80%, so the schema largely documents itself. The description reinforces `query` (name or description, wildcard) and `limit`/total-count semantics, but says nothing about `types` or `source_system`, leaving the agent dependent on schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verbs and resources: find BW objects by name/description, or list InfoArea contents. Clear what it does, but it never distinguishes itself from siblings like bw_read or bw_describe, which an agent could easily confuse with a retrieval tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Use it when you do not know the exact name or want to check that a name is free" gives concrete selection criteria. It stops short of naming the alternative tool (e.g. bw_read for exact-name lookup), so routing depends on the agent inferring sibling behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
System information: release, platform (BW/4HANA or classic), enabled object types and the active safety settings. Call it only when a call fails for a system reason, not as a first step.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | profile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, closed-world, and non-destructive, so the safety profile is fully covered structurally. The description adds that it reveals enabled object types and safety settings, which is useful context, but says nothing about output format, cost, or what a failure response looks like. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler. The content payload is front-loaded and the usage restriction follows immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a small read-only diagnostic tool with a one-value parameter and full annotation coverage, the description covers what it returns and when to reach for it. No output schema exists, so the enumerated return fields do the necessary work; only failure-mode details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter, an 'action' enum with a single allowed value 'profile' and a default, so calling it is self-evident from the schema. Schema description coverage is 0% and the description never mentions the action parameter, but a single-value enum needs little explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and enumerates exactly what it returns: release, platform (BW/4HANA or classic), enabled object types, and active safety settings. An agent can tell this apart from siblings like bw_describe or bw_read, which operate on individual objects rather than system-wide configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly gives both a when and a when-not: call it only when a call fails for a system reason, not as a first step. The only gap is that it does not name a concrete sibling alternative for the first-step case, but the exclusion is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the changeable transport requests (own, modifiable by default). Use it before bw_write when an object lives outside $TMP.
| Name | Required | Description | Default |
|---|---|---|---|
| user | No | create_task: task owner. | |
| action | Yes | ||
| objects | No | ||
| package | No | ||
| all_users | No | list: requests of every user. | |
| info_area | No | move: target InfoArea. | |
| transport | No | ||
| with_objects | No | list: the objects of each task. | |
| include_released | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a read-only, idempotent, non-destructive operation, so the description does not need to repeat safety details. The description adds useful scope about 'own, modifiable by default' and the precondition outside $TMP, but it does not explain return behavior, pagination, or how the listed requests differ by user/package.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with the main operation front-loaded and the usage condition following immediately. There is no filler or redundant repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, 44% schema description coverage, and no output schema, the description is too thin. It does not clarify the required action value, the meaning of several optional parameters, or the confusing schema where only 'list' is allowed but other fields reference create_task/move semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 44% across 9 parameters, and the description itself adds no parameter-level guidance. It does not clarify action, package, transport, objects, include_released, or the apparent mismatch between the lone 'list' action and schema fields described for create_task/move.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: list changeable transport requests, with scope noted as own/modifiable by default. It distinguishes the purpose reasonably well, though it does not explicitly differentiate from sibling tools such as bw_search or bw_system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear usage condition: use it before bw_write when an object lives outside $TMP. That is explicit timing and context, but it does not state when not to use the tool or name alternatives beyond bw_write.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0bw_contextbw_describebw_readbw_searchbw_systembw_transportScored across 6 tools
The six tools have mostly distinct roles: search finds names, read returns object definitions, context shows relationships, describe returns write-spec metadata, transport lists transport requests, and system reports environment details. The main ambiguity is that bw_describe and bw_transport both reference a missing bw_write, so an agent may wonder how their outputs are actually meant to be used.
All tools use a consistent bw_ prefix and lowercase snake_case, which is predictable and readable. The suffix convention mixes nouns (bw_system, bw_transport, bw_context) with verbs (bw_search, bw_read, bw_describe), though this is a minor deviation rather than a serious inconsistency.
Six tools is a reasonable, well-scoped count for a BW metadata and inspection server. However, the set feels slightly thin for a domain whose own tool descriptions assume an available write operation.
The surface is read-heavy and severe gaps exist: bw_write is repeatedly referenced but absent, and there are no create, update, delete, or transport-release operations. This will cause dead ends for any agent trying to follow the documented workflow of inspecting then modifying BW objects.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
Any REST/SOAP/GraphQL/OData/SQL API as MCP tools for Claude & ChatGPT. 561 connectors: SAP, ERP.
Schema modeling in JSON, JSON-LD, and other formats with CoreModels platform.
Query, browse, and automate OmegaAI workspaces from any MCP client. Streamable HTTP with OAuth 2.0.
