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

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

GetDdlVersions

List the version history of a CDS view (DDL source) by name, showing version IDs, authors, update timestamps, titles, and transport requests.

Instructions

[read-only] Lists the version history of the CDS view (DDL source) named by ddl_name: each version with its versionId, author, updatedAt, title, the transportRequest (and transportDescription) that produced it when available, and the opaque content_uri that names the version's source. Recordable: in batch mode a call is recorded under the next number and answers with empty content; its answer is read by number after the batch ends.

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": {
      "ddl_name": "<ddl_name>"
    },
    "name": "GetDdlVersions"
  }
}

Input Schema

NameRequiredDescriptionDefault
ddl_nameYesCDS view (DDL source) name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv8.5.0

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations supplied, the description carries the burden and does well: it flags the operation as [read-only], enumerates the returned record shape, and discloses the non-obvious batch-mode behavior (calls are recorded by number and answer with empty content, to be read afterward). It stops short of noting pagination limits, permissions, or behavior when ddl_name does not exist.

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?

A single dense sentence front-loads the verb, resource, and return fields, followed by a short batch-mode caveat. Every clause carries information, though the run-on return-field enumeration is slightly harder to scan than a short bulleted structure would be.

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?

There is no output schema, so the description must convey the return shape, and it does so field by field, plus it explains the batch recording semantics that would otherwise be surprising. Remaining gaps are minor: no mention of ordering, empty-history behavior, or error cases for an unknown ddl_name.

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% and the single parameter's schema description already says 'CDS view (DDL source) name.' The description restates essentially the same meaning ('the CDS view (DDL source) named by ddl_name') without adding format, case sensitivity, or naming-convention detail, so the baseline 3 applies.

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: lists the version history of the CDS view (DDL source) named by ddl_name, and enumerates the fields returned (versionId, author, updatedAt, title, transportRequest, content_uri). The mention that content_uri merely 'names the version's source' implicitly separates it from GetDdlVersionSource and GetDdlVersionDiff siblings, so an agent can identify it as the enumerator rather than the fetcher or differ.

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?

Usage is implied rather than stated: an agent can infer it should call this first to enumerate versions, then use the content_uri with a source tool. However, no sibling is named explicitly and there is no guidance on when to prefer GetObjectVersions (the generic variant) over this typed one, nor any prerequisite such as the object needing to exist.

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