coBWeb
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| BW_URL | No | Base URL of the BW system, e.g. https://bw.example.com:44300 | |
| BW_USER | No | Logon user (basic authentication) | |
| BW_CLIENT | No | Client | 001 |
| BW_PASSWORD | No | Logon password (basic authentication) | |
| BW_PLATFORM | No | auto (default) or bw4 | auto |
| COBWEB_TOOLS | No | Explicit tool list, overrides the profile | |
| COBWEB_TYPES | No | Allowed object types, e.g. AREA,IOBJ,ADSO | all |
| BW_COOKIE_FILE | No | Instead of user and password: cookies of a browser session (e.g. SAML) | |
| COBWEB_PROFILE | No | Tool set: modeling, analysis, operations or full | modeling |
| COBWEB_LOG_LEVEL | No | error, warn, info, debug (stderr) | info |
| COBWEB_ALLOW_DATA | No | Read business data (bw_data) | false |
| COBWEB_AUDIT_FILE | No | File for the audit log (one JSON line per written object) | |
| COBWEB_ALLOW_WRITES | No | Create, change, delete, activate, transports, unlock | false |
| COBWEB_DENY_ACTIONS | No | Single actions to refuse, e.g. bw_write.delete,bw_run.delete_request | |
| COBWEB_ALLOW_EXECUTE | No | Runtime actions (bw_run) | false |
| COBWEB_ALLOWED_PACKAGES | No | Packages writes may go to; patterns with *, e.g. $*,Z* | $TMP |
| COBWEB_MAX_RESULT_CHARS | No | Upper bound of every tool result | 20000 |
| COBWEB_ALLOWED_INFOAREAS | No | InfoAreas objects may be created in or changed | * |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| bw_searchA | 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 |
| bw_readA | 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. |
| bw_contextA | 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. |
| bw_describeA | 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. |
| bw_transportB | List the changeable transport requests (own, modifiable by default). Use it before bw_write when an object lives outside $TMP. |
| bw_systemA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.