Click on "Install 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., "@RCP-1 show me the ABAP code for program ZMYPROG"
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.
RCP-1 — Enterprise-ready MCP server for SAP ABAP systems. Secure by default, deployable to BTP or on-premise, and hardened with large unit/integration/E2E test coverage.
RCP-1 connects AI assistants (Claude, GitHub Copilot, Copilot Studio, and any MCP client) to SAP systems via the ADT REST API. It ships as an npm package and Docker image.
Built for organizations that need AI-assisted SAP development with guardrails — RCP-1 provides what's needed to run in production:
Safe by default — read-only, no free SQL, no table preview, no transport writes, no Git writes. Enable each capability with explicit SAP_ALLOW_* flags
Action deny list — block specific tool actions with SAP_DENY_ACTIONS (for example SAPWrite.delete), without exposing low-level operation codes to admins
Package restrictions — limit AI write operations (create, update, delete) to specific packages with wildcards (--allowed-packages "Z*,$TMP"). Read operations are not restricted by package — use SAP's native authorization for read-level access control
Data access control (off by default) — SAPRead(type=TABLE_CONTENTS) and SAPQuery are gated behind explicit env vars (SAP_ALLOW_DATA_PREVIEW=true, SAP_ALLOW_FREE_SQL=true). These capabilities can expose application data or run ad-hoc SQL, so they are intentionally separated from the default development-tooling surface. They can be enabled for governed use cases, but should be reviewed against the current SAP API Policy, your SAP agreement, and internal data-governance rules
Transport safety — transport reads are available for review, while transport mutations require both --allow-writes and --allow-transport-writes. Update/delete operations auto-use the lock correction number when no explicit transport is provided
Git workflow safety — Git operations are disabled by default. Enable explicitly with --allow-git-writes / SAP_ALLOW_GIT_WRITES=true
API-key profiles — multi-key HTTP deployments can assign viewer, viewer-data, viewer-sql, developer, developer-data, developer-sql, or admin per key
Writes restricted to $TMP when enabled — only local/throwaway objects; writing to transportable packages requires explicit --allowed-packages
HTTP security headers (helmet) on by default — HSTS, CSP, X-Frame-Options, CORP, X-Content-Type-Options. COOP is deliberately not set so popup-based OAuth flows (Copilot Studio) keep working. No flag to disable.
Opt-in CORS for browser MCP clients — RCP1_ALLOWED_ORIGINS (comma-separated, exact match). Off by default; native MCP clients don't need it
Layered rate limiting — three layers out of the box: per-IP OAuth and shared MCP HTTP edge limits (Layer 1; MCP inherits the historical derived cap unless RCP1_MCP_HTTP_RATE_LIMIT overrides it), per-user MCP quota (Layer 2, off by default — multi-user deployments opt in via RCP1_RATE_LIMIT=60), and a server-wide SAP-bound semaphore (Layer 3, default 10, on). Honors Retry-After on 429/503 from SAP / BTP gateways. See the Rate Limiting Guide
Supply-chain security — Dependabot (npm + GitHub Actions + Docker, weekly + same-day security advisories), npm audit --audit-level=high PR gate, GitHub Dependency Review on every PR, CodeQL SAST, Trivy container scanning (gating on release, advisory on dev), all third-party GitHub Actions pinned to commit SHA, SECURITY.md policy with severity-tiered SLAs. Image and npm package both ship with provenance attestations, and the release workflow publishes a best-effort CycloneDX SBOM for the production npm dependency graph. See the security guide §13
API key — simple Bearer token for internal deployments
OIDC / JWT — Entra ID, Keycloak, or any OpenID Connect provider
OAuth 2.0 — local browser-based login for BTP ABAP Environment service-key development
XSUAA — SAP BTP native auth with automatic token proxy for MCP clients
Per-user SAP identity — BTP Destination Service forwards the MCP user to SAP: Cloud Connector principal propagation for on-premise SAP, or OAuth2UserTokenExchange for BTP ABAP Environment
Deploy RCP-1 as a Cloud Foundry app on SAP BTP with full platform integration:
Destination Service — connect to SAP systems via managed destinations
Experimental multi-target mode — the default-off, mutation-free BTP mode discovers
destinations marked rcp1.enabled=true and exposes pinned SID/client plus aggregate endpoints
(setup,
administration)
Cloud Connector — reach on-premise systems through the connectivity proxy
Per-user destinations — user identity forwarded end-to-end via X.509 certificates for on-premise SAP, or exchanged for an ABAP bearer token for BTP ABAP Environment
XSUAA OAuth proxy — MCP clients authenticate via standard OAuth, RCP-1 handles the BTP token exchange
Audit logging — structured events to stderr, file, or BTP Audit Log Service
12 intent-based tools instead of 200+ individual tools — keeps tool selection simple, with the schema payload guarded by CI budgets and a hyperfocused 1-tool mode for tight context windows
Method-level read/edit — read or update a single class method, not the whole source (up to 20x fewer tokens)
Context-first understanding — SAPContext(action="deps") is the first call for "what does this object do?": it returns the object's Knowledge Transfer Document (SKTD/KTD) when available plus public API contracts of dependencies in one call (7-30x compression)
Server-validated source caching — every SAP object read is cached in memory (stdio) or SQLite (http-streamable). Repeated reads use If-None-Match/ETag conditional GET, so unchanged objects return from cache after SAP confirms 304 Not Modified.
Dependency graph caching — SAPContext dep resolution keyed by source hash; unchanged objects skip all ADT calls on subsequent runs.
KTD-aware context — Knowledge Transfer Documents are cached as source entries and composed into SAPContext(action="deps") separately from the dependency graph, so cached dependency context can still include revalidated documentation.
Live where-used — SAPContext(action="usages") and CDS impact analysis query SAP's current repository index with the caller's identity; no startup repository scan is required.
Active/inactive source views — SAPRead accepts version="active" | "inactive" | "auto" and warns when the active source has an unactivated draft.
Write invalidation — when SAPWrite or SAPActivate mutates an object, both active and inactive source cache entries are dropped; next read revalidates or fetches fresh source.
See docs/caching.md for full documentation.
3,474 unit tests (104 unit test files, mocked HTTP)
262-test default integration profile against live SAP systems, with explicit skip reasons when credentials or fixtures are missing
141-test default E2E profile that executes real MCP tool calls against a running RCP-1 server and live SAP system
Manual slow SAP profiles keep broad where-used, RAP full-stack, and recursive CTS release coverage out of the PR path (test:integration:slow, test:e2e:slow, GitHub SAP Slow Tests workflow)
CRUD lifecycle and BTP smoke lanes included (test:integration:crud, test:integration:btp:smoke)
CI matrix on Node 22 and 24; live SAP integration + E2E run on internal PRs and manual dispatch, with SAP jobs gated off for docs/chore PRs and external forks
Reliability telemetry + coverage published as informational CI signals (non-blocking)
The 12 tools are designed from real LLM interaction feedback:
Tool | What it does |
SAPRead | Read exact ABAP source, method bodies, grep matches, table data, CDS views, access controls ( |
SAPSearch | Object search + full-text source code search across the system |
SAPWrite | Create/update/delete ABAP source and DDIC metadata with automatic lock/unlock (PROG, CLAS, INTF, FUNC, FUGR, INCL, DDLS, DCLS, DDLX, BDEF, SRVD, SRVB, SKTD/KTD, TABL, DOMA, DTEL, MSAG; availability adapts for BTP). Class updates can target local includes ( |
SAPActivate | Activate ABAP objects — single or batch (essential for RAP stacks), with guarded retry for the S/4HANA ED064 batch quirk. Publish/unpublish OData service bindings (SRVB) |
SAPNavigate | Go-to-definition, find references, code completion |
SAPQuery | Execute ABAP SQL with table-not-found suggestions and automatic chunking for simple long literal |
SAPTransport | CTS transport management (list/get/create/release/delete/reassign/release-recursive), transport layer/target lookup, package transport requirement checks, and reverse lookup history ( |
SAPGit | Git-based ABAP workflows across gCTS and abapGit (list/clone/pull/push/commit/branch/unlink) with backend auto-selection and safety gating ( |
SAPContext | Context-first object understanding ( |
SAPLint | Local ABAP lint (system/release-aware presets, auto-fix, pre-write validation) + ADT PrettyPrint (server-side formatting) |
SAPDiagnose | Syntax check, ABAP Unit tests, ATC code quality, CDS test-case suggestions, active/inactive object-state comparison, generic ADT quickfix proposals/application deltas, gateway/system message diagnostics, short dumps, profiler traces, and the on-prem authorization trace ( |
SAPManage | Feature probing, cache statistics, package lifecycle/change-package operations, and FLP catalog/group/tile helpers |
Tool definitions automatically adapt to the target system (BTP vs on-premise), removing unavailable types and adjusting descriptions so the LLM never attempts unsupported operations.
RCP-1 probes the SAP system at startup and adapts its behavior:
Detects HANA, gCTS, abapGit, RAP/CDS, AMDP, UI5, and transport availability
Auto-detects BTP vs on-premise systems
Maps SAP_BASIS release to the correct ABAP language version
Each feature can be forced on/off or left on auto-detect
In shared-credential mode (technical user), runs a startup auth preflight once and blocks SAP tool calls with a clear error on 401/403 to avoid repeated failed logins and potential user lockout
Related MCP server: dassian-adt
SAP's current SAP API Policy is v.4.2026a. It allows published/documented APIs for the purposes described in SAP documentation, while restricting unsupported internal APIs, misuse, unmanaged autonomous AI call patterns, and large-scale extraction outside endorsed paths. RCP-1 is designed as a governed development-tooling proxy around ADT behavior, not as a bulk data-extraction product.
For typical internal developer workflows, RCP-1 should be treated as generally usable when it stays close to documented/discoverable ADT behavior, runs with real user identity, respects SAP authorization, and keeps audit and rate controls in place. Customers should still review their exact landscape, SAP agreement, and AI governance rules, especially when the MCP client can plan or execute sequences of tool calls.
Concretely, RCP-1 is positioned as a custom developer utility for internal development automation: code checks, build/activate, transport management, AI-assisted ABAP authoring, and Git workflows.
Two RCP-1 capabilities can expose business data or execute ad-hoc SQL. Both are off by default and require explicit opt-in env vars, so the operator makes a deliberate decision before they are reachable:
Capability | Env var | Default | Policy note |
Named table content preview ( |
|
| Can expose application-table data; keep off unless the use case is approved. |
Freestyle ABAP SQL ( |
|
| Executes ad-hoc ABAP SQL; keep off unless the use case is approved. |
With both flags at their defaults, RCP-1's data/sql rows are unreachable. Turning either flag on is a valid operational choice for approved scenarios, but it should be deliberate: check the current SAP API Policy, the customer's SAP agreement, SAP authorizations, and internal data-protection rules before enabling it on a productive system.
Beyond the policy, the public signals for ADT remain consistent: SAP publishes an ADT SDK, a guide for creating and consuming RESTful APIs in ADT, and has described the ABAP language server direction as an "ADT SDK 2.0".
RCP-1's strategy is to stay close to documented and discoverable ADT behavior, probe system capabilities before exposing tools, keep conservative security defaults (writes off, data preview off, free SQL off, package allowlist $TMP), and continuously review SAP's guidance as it evolves. This README is not a compliance decision for any specific customer landscape, but the default posture is intended to support normal governed development use rather than block it.
Install in Claude — pick your surface (full guide: Install in Claude):
Claude Desktop — download the latest rcp-1-*.mcpb from Releases and double-click it (or Settings → Extensions). Claude prompts for your SAP connection. (The .mcpb is attached to releases automatically; if the newest one doesn't have it yet, see Install in Claude.)
Claude Code — one install for the MCP server and all SAP skills:
/plugin marketplace add dhruvmahendrapatel/abap-mcp-rcp-v1
/plugin install rcp-1@rcp-1Any MCP client / manual — run it directly:
npx rcp-1@latest --url https://your-sap-host:44300 --user YOUR_USERTrying it out on your laptop? → Quickstart
Full local dev setup (Docker, cookie extractor, client configs)? → Local Development
Deploying for a team / BTP? → Deployment
Full documentation is available at github.com/dhruvmahendrapatel/abap-mcp-rcp-v1.
Guide | Description |
5-minute npx + Claude Desktop setup | |
Desktop | |
Full local dev — all install methods, MCP client configs, SSO cookie extractor | |
Multi-user deployment — Docker, BTP Cloud Foundry, BTP ABAP | |
Choose the BTP topology and follow the correct deployment, auth, destination, and operations guides | |
MTA deployment, topology decision, role handoffs, and safe acceptance | |
Changes, roles, secrets, scaling, upgrades, rollback, and customer handover | |
Experimental read-only BTP multi-target deployment, destinations, roles, and client configuration | |
Every flag and env var, one table | |
Update procedures per install method | |
Layer A / Layer B auth internals, coexistence matrix | |
Complete reference for all 12 tools | |
Add your own | |
System architecture with diagrams | |
Agent workflow patterns and best practices | |
Reusable RCP-1 agent skills, including GitHub Copilot in Eclipse and VS Code ADT setup |
npm ci && npm run build && npm testSee CLAUDE.md for codebase structure, testing commands, and contribution guidelines.
Project | Author | Contribution |
oisee | Original Go MCP server — RCP-1's starting point | |
Marcello Urbani | TypeScript ADT library, definitive API reference | |
Mario Andreschak | First MCP server for ABAP ADT | |
Lars Hvam | ABAP parser/linter (used via @abaplint/core) |
MIT
Primary tool for understanding ABAP/CDS objects before specs, reviews, explanations, or changes — use instead of SAPRead when the user asks what an object does. Returns intent first (the object KTD when available) then compressed dependency contracts. Use SAPRead after SAPContext for exact source/method bodies/grep/drafts.
Decision rule — pick the action from the user's question:
"What breaks if I change ?" / "Who consumes <I_*>?" / "Blast radius" → action="impact" (DDLS only).
"Which includes/appends extend ?" → action="structure", type="TABL".
"What does do?" / "Explain" / "deps before editing" → action="deps" (default).
"Find all callers of " → action="usages" (live SAP where-used lookup).
impact (CDS blast-radius): upstream AST deps + downstream where-used, classified into RAP buckets (projectionViews, bdefs, serviceDefinitions, serviceBindings, accessControls, metadataExtensions, abapConsumers, documentation, tables, other) + sibling-consistency hints. Use this instead of text-scanning DDDDLSRC/ACMDCLSRC with SAPQuery (it filters the noise). Optional includeIndirect, siblingCheck, siblingMaxCandidates. deps (default): target KTD + the public API contracts of its dependencies (not full source) — one compact response vs N SAPRead calls (7-30x fewer tokens); SAP standard objects filtered out. For CDS, includes dependency DDL/field catalogs for cl_cds_test_environment. structure (TABL only): the DDIC include/append tree.
Use SAPContext BEFORE editing existing objects. For non-CDS reverse-lookup use SAPNavigate(references); for CDS prefer impact. Full detail: docs_page SAPContext.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Object name (e.g., ZCL_ORDER) | |
| type | No | Object type. Optional for action="impact" (defaults to DDLS) or action="usages"; required otherwise. | |
| depth | No | Dependency depth: 1 = direct deps only (default), 2 = deps of deps, 3 = maximum. Higher depth = more context but more SAP calls. | |
| group | No | Required for FUNC type. The function group containing the function module. | |
| action | No | Action: "impact" = CDS blast-radius analysis (DDLS only). USE THIS for any question like "what breaks if I change <view>", "who consumes <I_*>", "impact analysis on <CDS>", "downstream of <view>". Returns upstream AST dependencies + downstream where-used classified into RAP buckets (projectionViews, bdefs, serviceDefinitions, serviceBindings, accessControls, metadataExtensions, abapConsumers, documentation, tables, other), plus additive sibling-consistency diagnostics (consistencyHints + siblingExtensionAnalysis) when related DDLS siblings show asymmetric DDLX coverage. ALWAYS prefer over SAPQuery against DDDDLSRC/ACMDCLSRC/DDLXSRC_SRC/SRVDSRC_SRC (those text-scans produce noise this classifier filters out). Non-DDLS input returns a guardrail error. "deps" (default, can be omitted) = object understanding / forward dependency context — "what does <object> do?" or "what does <object> depend on?". Returns the object KTD when available plus public API contracts of dependencies. "usages" = live SAP where-used lookup. Provide "type" when known; without it, the name must resolve uniquely. Prefer "impact" for CDS. "structure" = TABL includes/appends. | |
| source | No | Optional: provide source directly instead of fetching from SAP. Saves one round-trip if you already have the source from SAPRead. | |
| maxDeps | No | Max dependencies to resolve (default 20). Lower = faster + fewer tokens. | |
| includeKtd | No | deps: When true/default, prepend the object Knowledge Transfer Document (KTD/SKTD) when one exists. Set false to skip the KTD lookup. | |
| maxResults | No | usages: max entries (default 100); impact: max per downstream bucket (default 50). Max 1000. "usageCount"/"summary" stay true totals, not page sizes. | |
| siblingCheck | No | impact: Enable sibling metadata-extension consistency analysis. Default true. | |
| includeIndirect | No | impact: Include indirect (transitive) downstream where-used entries. Default false. | |
| siblingMaxCandidates | No | impact: Maximum sibling DDLS candidates to compare. Default 4; hard cap 10. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by detailing behavioral traits like returning compressed contracts, filtering SAP standard objects, and providing impact analysis buckets. No contradictions.
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 well-structured with a heading, bullet points, and a footer. While dense, it is front-loaded with purpose and decision rules. Every sentence adds value, though it could be slightly more concise.
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?
Given the complexity (12 parameters, 4 actions), the description thoroughly covers all aspects including each action's return type (impact buckets, deps contracts) and parameter usage. It references a docs page for full detail, ensuring completeness.
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 100%, providing baseline semantics. The description adds significant context for each action's parameters and their use cases (e.g., 'impact: CDS blast-radius' with detailed bucket classification), surpassing the schema's descriptions.
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 clearly states it's the primary tool for understanding ABAP/CDS objects, with specific verbs like 'returns intent' and 'use instead of SAPRead'. It differentiates from siblings by providing distinct actions (impact, deps, structure, usages) and explicitly contrasts with SAPRead.
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?
The description gives explicit decision rules for picking actions based on user questions (e.g., 'What breaks if I change <CDS>?' → impact). It also advises when to use alternatives (e.g., 'For non-CDS reverse-lookup use SAPNavigate') and when to use before editing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run diagnostics on ABAP objects and analyze runtime errors. Actions:
"syntax": syntax-check (name+type; optional version; optional source = pre-write dry-run, nothing written).
"unittest": run ABAP Unit tests (name+type).
"atc": run ATC checks (name+type; optional variant). "atc_variants": list variants + the system default (variant = name filter; read-only).
"cds_testcases": SAP-suggested ABAP Unit test cases for a CDS entity (name; read-only; SAP_BASIS 8.16+).
"object_state": compare active vs inactive source versions (name+type; CLAS compares all includes). Returns ETags/hashes/divergence flags.
"quickfix": get quick-fix proposals at a position (name+type+source+line; optional column, sourceUri).
"apply_quickfix": apply one proposal, return text deltas, no write (name+type+source+line+proposalUri+proposalUserContent; pass proposalUserContent through exactly).
"dumps": list/read ST22 short dumps (no id = list; id = read; includeFullText, sections).
"traces": list/analyze profiler traces (id+analysis: hitlist=hot spots, statements=call tree, dbAccesses=DB stats).
"trace_start": arm a profiler trace for the NEXT matching execution, then reproduce and read via "traces" (write scope; defaults: next HTTP request, SQL on).
"trace_requests": list armed trace requests. "trace_cancel": cancel one by id (write scope).
"system_messages": list SM02 messages. "gateway_errors": list /IWFND/ERROR_LOG (on-prem; detailUrl or id+errorType for detail).
"odata_perf": diagnose why an OData call is slow (url = host-relative path); returns the sap-statistics timing split (DB/ABAP/framework/auth). Read-only; needs allowDataPreview.
"authorization_trace": read the on-prem STUSERTRACE auth trace (SUAUTHVALTRC); needs SAP_ALLOW_DATA_PREVIEW.
"cds_sql": show the native SQL a CDS view compiles to (name; read-only).
"sql_trace_state" / "set_sql_trace_state" (sqlOn; needs SAP_ALLOW_WRITES) / "sql_trace_directory": ST05 SQL-trace control. Quickfix workflow: syntax/ATC → quickfix → apply_quickfix → write via SAPWrite. Full action reference: docs_page SAPDiagnose.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Dump or trace ID (for dumps/traces actions); also the trace-request id to cancel (for trace_cancel). Omit to list, provide to get details. | |
| to | No | Optional upper time boundary for feed-based diagnostics actions (system_messages/gateway_errors). | |
| url | No | For odata_perf: the host-relative OData path to probe, from the Fiori app's Network tab (e.g. "/sap/opu/odata4/sap/.../Entity?$filter=…"). Must be a path on the connected system — absolute URLs are rejected. | |
| from | No | Optional lower time boundary for feed-based diagnostics actions (system_messages/gateway_errors). | |
| line | No | Source line number for quickfix evaluation (required for quickfix/apply_quickfix). | |
| name | No | Object name (for syntax/unittest/atc/object_state); the CDS entity / DDLS source name for cds_testcases and cds_sql | |
| type | No | Object type (PROG, CLAS, etc.) (for syntax/unittest/atc/object_state) | |
| user | No | SAP-user filter for dumps, feeds, or authorization_trace. | |
| sqlOn | No | For action="set_sql_trace_state": true to arm the ST05 SQL trace, false to disarm. Combine with user to filter the trace to one SAP user. | |
| action | Yes | Diagnostic action | |
| column | No | Source column number for quickfix evaluation (default 0 for quickfix actions). | |
| source | No | Current source code (required for quickfix/apply_quickfix). | |
| variant | No | atc: check variant; atc_variants: name filter (*=all) | |
| version | No | Source version for syntax check (default "active"). Use "inactive" to validate pending changes. | |
| analysis | No | Trace analysis type (for traces action with id). hitlist = execution hot spots, statements = call tree, dbAccesses = database access stats. | |
| coverage | No | For action="unittest": also return statement/branch/procedure coverage for the object, plus methodsBelowFull — the methods below 100% statement coverage, worst first (what to test next) — in one extra round-trip. If the coverage endpoint or measurement is unavailable, returns the tests without coverage. Default false. | |
| sections | No | Dump chapter IDs to include for dumps detail mode (for example ["kap0","kap3","kap8"]). Omit to use focused defaults. | |
| sqlTrace | No | For trace_start: capture SQL/DB accesses (default true — required for analysis="dbAccesses"). | |
| aggregate | No | For trace_start: aggregate the trace (default true). | |
| detailUrl | No | ADT detail URL for gateway_errors detail mode (preferred over id+errorType). Accepts absolute or /sap/bc/adt/... path. | |
| errorType | No | Gateway error type for gateway_errors detail by id (for example "Frontend Error"). Required when using id without detailUrl. | |
| sourceUri | No | Exact ADT source URI for quickfix/apply_quickfix. Defaults to the type/name main source; use this for class includes such as /includes/definitions. | |
| traceUser | No | For trace_start/trace_requests: the SAP user whose matching execution is traced/listed. Defaults to the connected user. | |
| authObject | No | Authorization object filter, e.g. S_TCODE. | |
| maxResults | No | Maximum results for dumps/system_messages/gateway_errors (default 50) or authorization_trace (default 100); bounded to a safe cap. | |
| objectType | No | For trace_start: what to match within the process. Defaults to the valid type for the process type (http→url, dialog→transaction, batch→report, rfc→functionModule). | |
| description | No | For trace_start: optional label for the trace request. | |
| processType | No | For trace_start: the kind of work process to capture. Default "http" (OData/Gateway). dialog = SAP GUI transaction, batch = background job, rfc = RFC call. | |
| proposalUri | No | Quickfix proposal URI from quickfix action (required for apply_quickfix). | |
| expiresHours | No | For trace_start: hours until the armed request auto-expires (default 24). | |
| onlyFailures | No | For authorization_trace: return only denied checks (RC<>0), similar to the SU53 failure view. | |
| maxExecutions | No | For trace_start: how many matching executions to capture before the request is consumed (default 1). | |
| includeFullText | No | For dumps detail mode only: include full formattedText blob. Default false to reduce token usage. | |
| proposalUserContent | No | Opaque userContent from quickfix action (required for apply_quickfix). May be an empty string; pass through exactly. | |
| proposalAffectedObjects | No | Optional affectedObjects array from quickfix action. Include content for each affected source unit when applying multi-object quickfixes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly discloses behavioral traits beyond the annotations: it marks read-only actions (e.g., cds_testcases, atc_variants, object_state, dumps, traces, etc.) and write-scope actions (trace_start, trace_cancel). It also details side effects (e.g., trace_start defaults to HTTP, SQL on) and limitations ('needs allowDataPreview'). No contradiction with annotations.
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 long but well-structured: a one-line summary, a bullet list of actions with concise descriptions, and a brief workflow reference. It front-loads the overall purpose. Minor redundancy exists (e.g., repeating 'read-only' for multiple actions), but it remains efficient for the tool's complexity.
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?
Given the tool's complexity (35 parameters, 20 actions, multiple workflows), the description covers all actions, their parameters, and contextual behavior. It includes a workflow example for quickfixes and a link to full reference. The lack of an output schema is mitigated by action-specific return descriptions (e.g., 'returns ETags/hashes/divergence flags').
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 100% schema coverage, the schema already describes all parameters. The description adds substantial value by explaining action-specific usage, default behaviors, and relationships (e.g., 'id' for dumps/traces; 'Omit to list, provide to get details'). It also clarifies parameter dependencies like 'proposalUserContent: pass through exactly'.
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 begins with a clear verb+resource statement: 'Run diagnostics on ABAP objects and analyze runtime errors.' It then enumerates 20 distinct actions, each with a specific purpose. This distinguishes SAPDiagnose from siblings like SAPRead, SAPSearch, etc., which handle other concerns.
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?
The description provides explicit usage guidance for each sub-action, including preconditions (e.g., 'optional source = pre-write dry-run, nothing written'), the workflow for quickfixes, and constraints like 'read-only' flags. It also references a full action reference page. While it doesn't explicitly contrast with siblings, the guidance is thorough and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run local abaplint rules on ABAP/CDS source (auto-selects cloud or on-prem rules by system type). Actions:
"lint": check source (errors+warnings) for ABAP (PROG/CLAS/INTF/FUNC) and CDS (DDLS).
"lint_and_fix": lint + auto-fix fixable issues (keyword case, obsolete statements); returns fixed source.
"list_rules": list rules + current config (no source).
"format": pretty-print via SAP's ADT formatter (needs source).
"get_formatter_settings" / "set_formatter_settings": read/update the system's global PrettyPrinter (indentation bool, style keywordUpper|keywordLower|keywordAuto|none; set is blocked read-only). lint/lint_and_fix/list_rules run locally; format/*_formatter_settings call SAP. For ATC/syntax/unit tests use SAPDiagnose.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Object name (used for filename detection) | |
| rules | No | Rule overrides: { "rule_name": false } to disable, { "rule_name": { "severity": "Warning" } } to configure. Overrides system defaults. | |
| style | No | PrettyPrinter: keyword casing (for set_formatter_settings) | |
| action | Yes | Check type | |
| source | No | ABAP or CDS source code to lint/format (not needed for list_rules/get_formatter_settings) | |
| indentation | No | PrettyPrinter: indent source (for set_formatter_settings) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint: false and destructiveHint: false, and the description adds context by noting that lint_and_fix returns fixed source, format calls SAP, and set_formatter_settings is blocked read-only. It does not fully detail side effects (e.g., whether lint_and_fix persists changes), but the information is largely adequate.
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 well-structured with a clear opening sentence and a bullet-style enumeration of actions. It is concise for the amount of information conveyed, though slightly dense.
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?
Given the 6-parameter input schema and no output schema, the description covers all actions, local vs remote behavior, parameter requirements, and hints to sibling tools (SAPDiagnose). It is fully complete for an agent to correctly invoke the 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?
Schema description coverage is 100%, so the schema already documents all 6 parameters. The description adds value by naming actions and their prerequisites (e.g., 'source' needed for lint/format but not list_rules), but this is supplementary rather than essential.
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 starts with 'Run local abaplint rules on ABAP/CDS source' and enumerates six specific actions (lint, lint_and_fix, etc.), clearly stating what the tool does. It distinguishes from sibling tools like SAPDiagnose by mentioning 'For ATC/syntax/unit tests use SAPDiagnose.'
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?
The description explicitly tells when to use each action (e.g., 'format: pretty-print via SAP's ADT formatter (needs source)') and when not to ('For ATC/syntax/unit tests use SAPDiagnose'). It also clarifies which actions run locally vs remotely, providing clear context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probe and report SAP system capabilities. Use BEFORE operations that depend on optional features (abapGit, RAP/CDS, AMDP, HANA, UI5/Fiori, CTS transports, FLP). Also handles package (DEVC) lifecycle.
Actions:
"features": cached feature status (fast, no round-trip; id, available, mode, probedAt). "probe": re-probe now (feature probes + auth + discovery refresh). "cache_stats": object cache health.
"create_package" / "delete_package" / "change_package": DEVC lifecycle via ADT packages API.
FLP read: flp_list_catalogs, flp_list_groups, flp_list_tiles (catalogId). FLP write: flp_create_catalog, flp_create_group, flp_create_tile, flp_add_tile_to_group, flp_delete_catalog.
"set_api_state": release/revoke an object's API release contract (objectUri, or name+objectType; apiState defaults RELEASED, contract defaults C1 — C0 for SRVD, C3 for classic views). Write counterpart of SAPRead(type="API_STATE").
Returns features + systemType ("onprem"/"btp"); "available: false" means do NOT attempt dependent operations.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Package name (required for create_package and delete_package). | |
| tile | No | Tile definition for flp_create_tile. | |
| title | No | Title — required for flp_create_catalog and flp_create_group. | |
| action | Yes | Action to execute. Read actions: features, probe, cache_stats, flp_list_catalogs, flp_list_groups, flp_list_tiles. Mutating package/FLP actions require writable safety config and write scope in authenticated mode. | |
| groupId | No | FLP group/page identifier (required for flp_create_group, flp_add_tile_to_group). | |
| apiState | No | For set_api_state: target state of the object's API release contract — RELEASED (mark released for ABAP Cloud / Clean Core) or NOT_RELEASED (revoke). Default RELEASED. Visibility (ABAP Cloud / Key User Apps) follows the contract's defaults. Read the current state first with SAPRead(type="API_STATE"). | |
| contract | No | For set_api_state: which release contract to set. Default C1 (Key-User/Cloud — the common clean-core contract). Object types support different contracts: e.g. service definitions (SRVD) only support C0, classic DDIC views only C3, behavior definitions and tables support C0+C1. If the object does not support the chosen contract, the error lists the ones it does. | |
| domainId | No | Domain ID — required for flp_create_catalog (e.g., ZRCP1_SALES). | |
| catalogId | No | FLP catalog identifier — accepts either full ID (X-SAP-UI2-CATALOGPAGE:MY_CAT) or domain ID (MY_CAT). Required for flp_list_tiles, flp_create_tile, flp_add_tile_to_group, flp_delete_catalog. | |
| objectUri | No | ADT URI of the object to move (e.g., /sap/bc/adt/oo/classes/zcl_my_class). If not provided, resolved automatically from objectName + objectType via search. For set_api_state: the object whose API release contract to set (or pass name + objectType instead). | |
| transport | No | Optional transport request (corrNr) for create_package, delete_package, or change_package. | |
| newPackage | No | Target package to move the object to. Required for change_package. | |
| objectName | No | Object name to move (e.g., ZCL_MY_CLASS). Required for change_package. | |
| objectType | No | ADT object type (e.g., CLAS/OC, DDLS/DF, PROG/P). Required for change_package. For set_api_state: object type of "name" when objectUri is omitted (e.g. CLAS, INTF, DDLS, TABL). | |
| oldPackage | No | Current package of the object. Required for change_package. | |
| description | No | Package description (required for create_package). | |
| packageType | No | Package type for create_package (default: development). | |
| responsible | No | BTP only: the internal ABAP user (XUBNAME, e.g. CB9980000000) for the new package person-responsible. Auto-resolved from prior object creates if omitted; the IAS email is rejected. | |
| superPackage | No | Parent package for create_package (defaults to empty root package). | |
| recordChanges | No | Whether the created package records object changes in transport requests. Defaults to true for non-LOCAL software components or when a transport layer is set; false for literal LOCAL packages. | |
| tileInstanceId | No | Tile instance ID in the source catalog (required for flp_add_tile_to_group). | |
| transportLayer | No | Transport layer for create_package (optional; required by some transportable landscapes). | |
| softwareComponent | No | Software component for create_package (default: LOCAL on-prem, ZLOCAL on BTP). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=true. The description confirms this by listing mutating actions (create_package, delete_package, FLP write, set_api_state) and notes that mutating actions require 'writable safety config and write scope in authenticated mode.' This adds context beyond annotations without contradiction.
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 somewhat verbose but well-structured with a clear high-level statement followed by bullet points for actions. Every sentence adds value, though it could be slightly more concise.
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 complex tool with 23 parameters, nested objects, and no output schema, the description covers major actions, prerequisites, and return format (features + systemType). It explains 'available: false' as a guard for dependent operations. However, it lacks full output schema details.
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 100%, so baseline is 3. The description adds value by explaining defaults for apiState and contract, and context for object types. It does not detail every parameter but provides meaningful guidance for key parameters.
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 clearly states 'Probe and report SAP system capabilities' and enumerates specific actions (features, probe, cache_stats, package lifecycle, FLP management, set_api_state). It distinguishes from sibling tools like SAPRead and SAPSearch by focusing on management and probe actions.
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?
The description explicitly advises using the features action before operations depending on optional features. It also outlines when to use each action (e.g., package lifecycle for DEVC, FLP actions for tiles, set_api_state for API contracts). However, it does not provide explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read SAP ABAP objects — exact raw source, a method body, grep output, inactive drafts, revision history, or metadata. For "what does this object do?", explanations, spec work, reviews, or pre-change orientation, prefer SAPContext first (intent-level context before raw source). Types: PROG, CLAS, INTF, FUNC, FUGR (expand_includes=true for all include sources), INCL, DDLS, DCLS, DDLX, BDEF, SRVD, SRVB, SKTD/KTD (KTD aliases SKTD), TABL (covers both transparent tables AND DDIC structures — no separate STRU type), VIEW, DOMA, DTEL, TRAN, TABLE_CONTENTS (single-column filter), TABLE_QUERY (multi-column WHERE via the freestyle endpoint; gated by allowDataPreview; CDS views need SAP_BASIS 752+), DEVC, SOBJ (BOR — method param reads one method), SYSTEM, COMPONENTS, MSAG, TEXT_ELEMENTS, VARIANTS, BSP, BSP_DEPLOY, API_STATE (contract states C0-C4; objectType for non-class), INACTIVE_OBJECTS (no name; pending-activation list), AUTH, FEATURE_TOGGLE, ENHO, VERSIONS, VERSION_SOURCE. AUTH/FEATURE_TOGGLE/ENHO/VERSIONS/VERSION_SOURCE are on-prem only. CLAS: to save tokens, prefer method="*" (all signatures), method="NAME" (one body, ~95% fewer tokens than the full class), or grep over reading the full source. Omit include for the full source, or include=definitions|implementations|macros|testclasses for a local section. Full per-type detail: docs_page SAPRead. Optional grep: case-insensitive regex returning only matching source lines (+context, line numbers); for CLAS, matches are annotated with the owning class/method. Optional version parameter (default "active"): "inactive" reads the user's draft, "auto" the developer view. Active reads note when an inactive draft exists.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | action="diff" NEW side (default "inactive" = pending unactivated changes). Same values as from. | |
| from | No | action="diff" OLD side: "active" (default), "inactive", a revision id from SAPRead(type="VERSIONS"), or a /sap/bc/adt/ revision URI. | |
| grep | No | Regex pattern (case-insensitive) to search within the object source. Returns only matching lines with 1-based line numbers and ±3 context lines, instead of the full source — token-efficient. For CLAS, matches are annotated with the owning class/method; combine with include= to scope a section, but do NOT combine with method= (use grep to find, then method= to read). Works for source-bearing types (CLAS, INTF, DDLS, DCLS, BDEF, SRVD, SRVB, SKTD/KTD, DDLX, TABL, PROG, FUNC, FUGR, INCL, VIEW). Falls back to a literal search when the pattern is not valid regex. | |
| name | No | Object name (e.g., ZTEST_PROGRAM, ZCL_ORDER, MARA) | |
| type | Yes | Object type to read (on-prem): PROG, CLAS, INTF, FUNC, FUGR, INCL, DDLS, DCLS, DDLX, BDEF, SRVD, SRVB, SKTD or KTD (Knowledge Transfer Documents), TABL (transparent tables and DDIC structures), VIEW, DOMA, DTEL, MSAG, TRAN, TABLE_CONTENTS, TABLE_QUERY, DEVC, SOBJ, SYSTEM, COMPONENTS, TEXT_ELEMENTS, VARIANTS, BSP, BSP_DEPLOY, API_STATE, INACTIVE_OBJECTS, AUTH, FEATURE_TOGGLE, ENHO, VERSIONS, VERSION_SOURCE. Server-driven objects (discovery-gated; XML metadata; source is AFF JSON, or DDL text for DTSC/DSFD/DTDC): DESD (Logical External Schema), EVTB (RAP Event Binding), EVTO (RAP Event Object), DTSC (Static Cache), CSNM (CSN Model), COTA (Communication Target), DSFD (Scalar Function Def), DTDC (Dynamic Cache). Deprecated aliases: MESSAGES (use MSAG), FTG2 (use FEATURE_TOGGLE). | |
| group | No | For FUNC/VERSIONS type. The function group containing the function module. Optional for FUNC — auto-resolved via SAPSearch if omitted. Required for VERSIONS when querying a function module revision feed. | |
| where | No | For TABLE_QUERY: structured WHERE conditions, ANDed together. Each item: {field, op, value?}. Allowed ops: =, !=, <>, <, <=, >, >=, LIKE, NOT LIKE, IN, NOT IN, IS NULL, IS NOT NULL. For IN/NOT IN: value must be a comma-separated list of single-quoted literals, e.g. "'261','262'". Subqueries are not allowed. Example: [{"field":"MATNR","op":"=","value":"300006888"},{"field":"BUDAT_MKPF","op":">=","value":"20250101"}]. | |
| action | No | Set to "diff" for a unified diff between two source versions (uses from/to) — cheaper than fetching both sources. Source types only: PROG, CLAS, INTF, FUNC, FUGR, INCL, DDLS, DCLS, BDEF, SRVD, DDLX, TABL. | |
| format | No | Output format. "text" (default): raw source. "structured" (CLAS only): JSON metadata + EVERY class include (main, testclasses, definitions, implementations, macros) — a superset of "text", so it always costs MORE (measured +10% to +1685%). Use only to split test from production code; otherwise method="*" / method="name" / grep=. | |
| method | No | For CLAS: method name to read a single method implementation (e.g., "get_name", "zif_order~process"). Use "*" to list all methods with signatures and visibility. For SOBJ: BOR method name to read. If omitted, returns the full BOR method catalog. Not used with other types. | |
| columns | No | For TABLE_QUERY: columns to SELECT (default: all). Example: ["MATNR","BWART","BUDAT","MENGE"]. | |
| include | No | For CLAS: DO NOT use this to read the main class — omit include entirely to get the full class source (CLASS DEFINITION + CLASS IMPLEMENTATION). This parameter reads class-LOCAL auxiliary files only: definitions (local type definitions, NOT the main class definition), implementations (local helper class implementations), macros, testclasses (ABAP Unit). Comma-separated. For DDLS: use include="elements" for the CDS field catalog (key fields, aliases, associations, expression types) instead of raw DDL. For VERSIONS (CLAS): include selects the class include history to query (main, definitions, implementations, macros, testclasses). | |
| maxRows | No | For TABLE_CONTENTS and TABLE_QUERY: max rows to return (default 100) | |
| toLabel | No | action="diff" optional display label for the NEW side in the summary and patch header, e.g. "active" or "inactive draft". Does not affect source resolution. | |
| version | No | Source version to read. "active" (default) returns the last activated version. "inactive" returns the user's unactivated draft or active if no draft exists. "auto" returns the draft if one exists, else active. | |
| fromLabel | No | action="diff" optional display label for the OLD side in the summary and patch header, e.g. "DNT-6-6: Validate discounts (DS7K900123)". Does not affect source resolution. | |
| sqlFilter | No | For TABLE_CONTENTS: condition expression only (no WHERE, no SELECT), e.g. "MANDT = '100'" or "MATNR LIKE 'Z%'". | |
| maxResults | No | For DEVC: max number of objects to list (default 200, clamped to [1, 1000]). Larger packages may be silently truncated by SAP at this limit; raise it if needed. | |
| objectType | No | For API_STATE and VERSIONS: SAP object type (CLAS, INTF, PROG, FUNC, INCL, DDLS, DCLS, BDEF, SRVD, etc.). For API_STATE: auto-detected from name if omitted. For VERSIONS: required to pick the correct revisions endpoint (e.g., "FUNC" + group for function modules); inferred from CL_/IF_/CX_ name prefixes when possible, defaults to PROG. | |
| versionUri | No | For VERSION_SOURCE: URI of a specific revision from SAPRead(type="VERSIONS") response (.revisions[].uri). Must start with /sap/bc/adt/. | |
| force_refresh | No | For source reads: bypass cached source and inactive-list state before reading. Use when you know the object changed outside RCP-1. | |
| expand_includes | No | For FUGR type only. When true, recursively expands the function group include tree — the main source plus all nested INCLUDEs (the FUNCTION...ENDFUNCTION bodies live in nested LZ<grp>U01/U02 includes, so a flat one-level walk misses them). Each block is prefixed with a "=== name ===" marker; depth/count-capped. Dynpros and GUI status are not included (ADT does not expose them over REST). | |
| includeSignature | No | For FUNC type only. When true, response is JSON: {source, signature: {importing[], exporting[], changing[], tables[], exceptions[], raising[]}} — each parameter parsed into {kind, name, type, byValue?, default?, optional?}. Default false (returns plain source body). Use this to introspect FM parameter signatures programmatically without re-parsing ABAP. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses many behavioral traits beyond the readOnlyHint annotation, such as caching behavior with force_refresh, token-efficient grep, and how version parameter works with drafts. It also explains limitations like on-prem only types and truncated packages. No contradictions with annotations.
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 very long (600+ words) and dense with details. While it is well-structured and front-loads the purpose, it could be more concise. However, for the complexity of the tool, the length is justified.
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?
Given the complexity (23 parameters, many object types, no output schema), the description is remarkably complete. It covers all major behaviors, parameter combinations, and edge cases (e.g., deprecated aliases).
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 100% schema coverage, baseline is 3. The description adds meaning by explaining interactions between parameters (e.g., method vs include for CLAS, grep vs method) and providing usage examples, which goes beyond the schema descriptions.
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 clearly states the tool's purpose: 'Read SAP ABAP objects — exact raw source, a method body, grep output, inactive drafts, revision history, or metadata.' It uses specific verbs and resources, and distinguishes from sibling tools like SAPContext by recommending it for intent-level context.
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?
The description provides explicit guidance on when to use this tool versus alternatives, e.g., 'prefer SAPContext first (intent-level context before raw source).' It also advises on token-saving strategies for CLAS (method="*" or grep) and explains on-prem only types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for ABAP objects, exact object-directory entries, or source code. Modes:
Object search (default): name pattern with wildcards (*); returns type, name, package, description, ADT URI.
TADIR lookup (searchType="tadir_lookup"): exact cross-package lookup of one or more names (prefer over long SAPQuery TADIR IN-lists). Tips: BOR objects appear as SOBJ; the uri field feeds SAPNavigate, objectType feeds SAPRead/SAPWrite/SAPActivate. Searches object NAMES only — for field names use SAPRead(type='DDLS', include='elements') or SAPQuery on DD03L.
| Name | Required | Description | Default |
|---|---|---|---|
| names | No | For tadir_lookup: exact object names to resolve across packages. Prefer this over long SAPQuery TADIR IN-lists. | |
| query | No | Search pattern for object search, or comma/whitespace-separated names for tadir_lookup. | |
| source | No | For tadir_lookup only: data source for the lookup. "adt" (default) uses the ADT info-system endpoint — workbench-resolvable objects only. "db" issues SQL against table TADIR — also surfaces orphan/ghost rows from aborted create-delete cycles (requires sql scope and SAP_ALLOW_FREE_SQL=true). "both" runs both paths and adds a "splitBrain" array listing names where the two sources disagree, plus a "warnings" array explaining each divergence (requires sql scope). | |
| maxResults | No | Maximum results (default 100) | |
| objectType | No | For source_code search: filter by object type (e.g., PROG, CLAS, FUNC). For tadir_lookup: single type filter; use objectTypes for multiple. | |
| searchType | No | Search mode: "object" (default) searches by object name, "tadir_lookup" does exact cross-package object lookup. | |
| objectTypes | No | For tadir_lookup: optional ADT/TADIR type filters (e.g., TABL, DDLS, BDEF, SRVB, CLAS/OC). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Descriptions of modes and parameter behavior (e.g., BOR objects appear as SOBJ, source parameter options for tadir_lookup) add behavioral context beyond the readOnlyHint annotation. No contradictions; all described behaviors are read-only.
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?
Very concise yet comprehensive. Uses numbered modes and tips. Every sentence adds value; no redundant or irrelevant content. Front-loaded with main purpose and then details.
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 complex tool with 7 optional parameters and no output schema, the description sufficiently explains usage modes, parameter interdependencies, and return field semantics (uri, objectType). Refers to other tools for further actions, ensuring an agent can use it correctly.
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 100%, so baseline is 3. The description adds valuable context: explains how query parameter applies to both modes, restrictions on source parameter, and relationships between objectType and objectTypes for different search modes. This goes beyond schema descriptions but does not cover every edge case.
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?
Clearly states the tool searches for ABAP objects, exact TADIR entries, or source code. Distinguishes between object search and tadir_lookup modes, and explicitly contrasts with sibling tools like SAPQuery and SAPRead.
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?
Provides explicit when-to-use guidance: object search for name patterns, tadir_lookup for exact cross-package lookup. Advises preferring tadir_lookup over long SAPQuery IN-lists. Also references alternatives for field name searches (SAPRead, SAPQuery).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage CTS transport requests (SE09/SE10). Actions: list (current user, modifiable), get (tasks + objects), create (always a Workbench (K) request — the package/target sets target & layer, not the request category; optional explicit target), release, delete, remove_object (keep the request), reassign (change owner), release_recursive (tasks then parent), check (does a package need a transport — type, name, package), history (transports referencing an object — type, name; read-only, no write scope needed). IDs look like A4HK900123. Status: D=modifiable, R=released.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Transport request ID, e.g. A4HK900123 (required for get/release/delete/reassign/release_recursive/remove_object) | |
| name | No | Object name (for check, history, or remove_object actions) | |
| type | No | Object type for check/history/remove_object actions (PROG, CLAS, DDLS, etc.). Not used by create — the SAP backend infers transport type (K/W/T) from the package's TADIR route on the CreateCorrectionRequest endpoint. | |
| user | No | SAP username to filter by (for list). Defaults to the current SAP user. Use "*" to list all users. | |
| owner | No | New owner SAP username (required for reassign) | |
| pgmid | No | Program ID for remove_object: "R3TR" (whole object) or "LIMU" (sub-object). Required — object type alone does not determine pgmid. | |
| action | Yes | list: show transports (defaults to current user, modifiable only). Pass summary=true for a headers-only overview that omits each transport's object lists (keeps an objectCount) — far cheaper when many transports are open. get: fetch transport details including tasks and objects. create: create a new transport request (description required). To target another system, pass target=<system | system.client | /group/> (the Transportziel / TR_TARGET, e.g. "/TRG/" or "C11"; the group and system.client forms require extended transport control to be active). Otherwise omit target and pass an optional package to let SAP infer the route (defaults to $TMP). The response reports the resolved transport target; an empty target means a LOCAL request (cannot be transported onward). release: release a single transport or task. delete: delete a transport (use recursive=true to delete tasks first; removeLockedObjects=true to strip locked objects that otherwise block deletion with "...contains locked objects"). remove_object: remove one object from a request, keeping the request — needs the full key pgmid+type+name. reassign: change transport owner (use recursive=true for tasks too). release_recursive: release all unreleased tasks first, then the transport itself. check: check if a transport is needed for a package/object (requires type, name, package). history: list transports referencing an object (reverse lookup; requires type, name; works without SAP_ALLOW_TRANSPORT_WRITES). layers: list the transport layers this system offers (name + description + resolved target where any) — the valid values for create's transportLayer. Use this to discover a real value instead of guessing; works without SAP_ALLOW_TRANSPORT_WRITES. targets: list the valid transport targets (Transportziel / TR_TARGET) this system offers — the valid values for create's target. Use this to discover a real target (e.g. before create with target=). Read-only. Both report unavailability at runtime on releases that lack the value-help endpoint. | |
| status | No | Transport status filter (for list). D=modifiable (default), R=released, "*"=all statuses. | |
| target | No | Explicit transport target (Transportziel / TR_TARGET) for create — what the user means by "create a transport with target X". Forms: a system ("C11"), system.client ("C11.021"), or target group ("/TRG/"). The group and system.client forms require extended transport control (CTC) to be active. Created via the tm:root/newrequest endpoint (the only ADT path that sets the target directly) — this needs a newer ABAP Platform / S/4HANA; SAP_BASIS 7.50 rejects it with "user action is not supported" (an ADT-stack limitation, so set the target in SE09/SE10 there instead). SAP validates the target — an unknown target is rejected. Pass the exact value the user gives; do not invent one. | |
| package | No | Package name. For create: optional — defaults to $TMP, pass an explicit package to influence the transport route (SAP infers K/W/T from the package's TADIR route). For check: required. | |
| summary | No | For list only. DEFAULT true: headers-only — drops each transport's (and task's) object lists, keeping id/description/owner/status/target + objectCount; use action="get" for one in full. Pass false for full object lists (~5x larger). | |
| recursive | No | Apply recursively to child tasks (for delete/reassign). release_recursive always recurses. | |
| maxResults | No | list: max transports (default 50, max 1000). "total" always reports the full backlog. | |
| description | No | Transport description text (required for create) | |
| transportLayer | No | Transport layer for create (optional, advanced). Sent as the ?transportLayer= query param to override which consolidation route — and therefore which target — SAP resolves. OMIT IT by default: SAP resolves the target from the package automatically, which is correct for almost all cases. Never invent a value — if you need a specific layer, obtain it from action="layers" or from the user. Only effective when that layer has a classic STMS consolidation route; otherwise the request is local regardless. | |
| removeLockedObjects | No | For delete only. Strip locked objects from each task before deleting, so a request that still holds a locked object (e.g. a deleted object's lingering record → HTTP 400 "...contains locked objects") can be removed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits beyond annotations. It details destructive actions (delete, release, remove_object) with sub-options (recursive, removeLockedObjects), explains create's inference of transport type, and notes read-only actions (history, layers, targets). No contradiction with annotations (destructiveHint=true).
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 efficient and front-loaded, immediately stating the tool's purpose and actions. While long, every sentence adds value. Could be slightly more structured (e.g., bulletized actions), but it remains clear and concise for the complexity.
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?
Given the tool's complexity (16 parameters, 11 actions, no output schema), the description is complete. It covers actions, parameters, prerequisites (e.g., for target), side effects (e.g., delete with removeLockedObjects), and error conditions. It also mentions response characteristics for key actions (e.g., 'The response reports the resolved transport target' for create).
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 100%, but the description adds significant context beyond the schema. For example, it explains the 'target' parameter's forms and restrictions, and notes that the 'action' parameter's description includes behavioral details for each value. Baseline 3; extra context justifies a 4.
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 clearly states the tool's purpose as managing CTS transport requests (SE09/SE10). It lists 11 specific actions, each with a distinct verb and resource. The sibling tools (SAPRead, SAPSearch, etc.) are different in scope, making this tool well-differentiated.
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?
The description provides explicit guidance for each action, including when to use each (e.g., 'list: show transports (defaults to current user, modifiable only)') and context like using summary=true for cheaper list operations. It does not explicitly state when not to use this tool, but the distinct sibling tools make it clear. Minor omission: no direct comparison to alternatives.
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. Dates show when Glama detected each change.
v0.9.27SAPContextSAPDiagnoseSAPLintSAPManageSAPNavigateSAPReadSAPSearchSAPTransportEach tool has a clearly distinct purpose: SAPRead for raw source, SAPSearch for object names, SAPNavigate for code navigation, SAPTransport for transport management, SAPLint for static analysis, SAPDiagnose for diagnostics, SAPContext for understanding, and SAPManage for system capabilities. No overlap in functionality.
All tool names follow a consistent 'SAP' prefix plus a descriptive verb/noun (Read, Search, Navigate, Transport, Lint, Diagnose, Context, Manage), maintaining a uniform pattern.
With 8 tools, the set is well-scoped for an SAP ABAP development environment, covering reading, searching, navigation, transport, linting, diagnostics, context analysis, and system management without being overwhelming.
The tools cover analysis and management well, but lack a direct tool for writing or modifying ABAP objects (e.g., SAPWrite). While SAPTransport and SAPManage handle some writes, the absence of code-writing capabilities is a notable gap for a development-oriented server.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dhruvmahendrapatel/abap-mcp-rcp-v1'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
