abap-adt-doZimple
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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 | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| sap_systemsC | Estado de la configuración de sistemas SAP. |
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 1 tool
With only a single tool there is no possibility of overlap or misselection, so ambiguity between tools is zero. However, the tool's own purpose ('Estado de la configuración de sistemas SAP') is vague and does not clearly state what action it performs or returns.
The single name 'sap_systems' uses a clean snake_case convention, but it is a bare noun phrase with no verb, so no predictable verb_noun pattern exists to evaluate. With one tool, consistency is neither violated nor demonstrated.
A single tool is far too thin for a server named 'abap-adt-doZimple', which implies ABAP ADT development operations such as reading, editing, activating, and transporting objects. One config-status tool cannot cover that scope.
The surface is severely incomplete: an ABAP/ADT server would need tools for object retrieval, source editing, activation, transports, and system listing, yet only one status-report tool is exposed. Agents would hit immediate dead ends for any real development workflow.