Skip to main content
Glama
Sign In
abap-config-mcp

abap-config-mcp

by netweaver1970
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Version History

version_history
Read-onlyIdempotent

Lists stored revisions of an ABAP object with version ID, date, author and title so you can see who changed it and when; returns metadata only, not source.

Instructions

List the stored revisions of an ABAP object, one line per revision: version id, date, author and version title. Lists metadata only, not the source of each version. Use it to see who changed an object and when; use get_transport_for_object for its current transport. Read-only. Returns a no-history message for objects without revisions.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "version_history"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesADT URL of the object (e.g. /sap/bc/adt/programs/programs/ZREPORT)
connectionIdNoSAP system connection ID (default connection if omitted)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.16.2
    • changedInput schema / properties / connectionId / description
      Previous value: -"SAP system connection ID"New value: +"SAP system connection ID (default connection if omitted)"
    • changedInput schema / properties / url / description
      Previous value: -"ADT URL of the object"New value: +"ADT URL of the object (e.g. /sap/bc/adt/programs/programs/ZREPORT)"
  2. First observedv1.16.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered; the description adds real value on top by disclosing that only metadata is returned and that objects without revisions produce a specific no-history message. It stops short of stating result ordering, limits or whether an empty object is an error, which would have earned a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tightly packed sentences, front-loaded with the return shape, then the use case and alternative, then the caveat and edge case. No sentence is redundant and nothing is buried.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two parameters, no output schema and a simple read operation, the description supplies everything needed: what is listed, what is excluded, what the alternative is, and how empty results manifest. Nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so both url and connectionId are already documented in the schema; the description only implies the object identity via "of an ABAP object" and adds no format or defaulting detail. Baseline 3 applies when the schema carries the parameter burden.

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 specific verb and resource ("List the stored revisions of an ABAP object") and enumerates exactly what each line contains: version id, date, author and version title. It also draws a clear boundary against the sibling get_transport_for_object, so an agent can distinguish the two without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ("see who changed an object and when") and names the alternative with its selecting condition ("use get_transport_for_object for its current transport"). It also adds a when-not clause by warning that source content is not returned, pointing the agent elsewhere for code.

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