Connects an AI assistant to an ADT-enabled SAP ABAP system through a governed capability-discovery and invocation gateway.
Search available SAP capabilities by keyword, name, category, risk level, and pagination cursor.
Describe one or more capabilities (up to 10) to retrieve exact input schemas, schema hashes, and optionally output schemas.
Invoke read-only capabilities using a described capability name, schema hash, and arguments.
Invoke write capabilities with schema-hash validation for scoped changes.
Invoke destructive capabilities when exposed, marked as destructive and not read-only.
Supports reading ABAP, inspecting check results, and making scoped changes through discovered capabilities; actual operations depend on what the connected SAP system exposes.
Provides tools to connect to SAP ABAP systems via ADT HTTP API, enabling management of ABAP objects, searching, reading source code, and more.
Click on "Deploy 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., "@sap-abap-mcp Search for ZCL_DEMO class in DEV100 and show its source."
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.
Connect your AI assistant to an ADT-enabled SAP system to read ABAP, make scoped changes and inspect actual check results.
Install Node.js 22/24 and connect to your company VPN.
Run npx -y @coaspe/sap-abap-mcp@2.2.0 onboard (npx.cmd on Windows).
Verify and save your SAP connection, register your host, then restart the app and verify an actual SAP system read.
Host | Setup command |
Claude Code |
|
Codex |
|
VS Code |
|
Cursor |
|
Gemini CLI |
|
Claude Desktop |
|
Version 2.2.0 includes company CA files, six-host registration and Windows SAP
Logon import. Omit --apply to preview a registration; existing entries are
preserved and existing settings files are backed up. Claude Desktop MCPB users
should avoid a duplicate registration. On Windows replace npx with npx.cmd.
CA profiles use file format version 3 and need 2.2.0 or later. Existing npm registrations pin their package version: restart alone does not update a 2.1.0 registration. Use registration doctor and reviewed repair to update an existing registration to 2.2.0 before using a CA profile.
See setup details, including Linux environment-only credentials and registration recovery.
2.1.0 fixes noninteractive startup, native macOS credential storage and registration recovery. Windows DPAPI explicitly loads its native security module even when Node inherits a PowerShell 7 module path. Bundled npm/npx Windows launchers are resolved without a shell while preserving custom wrappers. This release also reduces the runtime package. Patched vendor bytes are preserved across Windows and Unix checkouts. Existing five gateways still reach 120 capabilities.
Related MCP server: dassian-adt
Repeated source patches use the same current-source view, preserve literal $
sequences and activate after unlock. Transport release supports ADT background
runs; the release also improves RAP response recovery, V4 unpublish errors,
old open-transport discovery, CTS-key object assignment, Dictionary checks and
top-level package creation. See the eight fixes and validation limits.
These paths have local automated coverage. Live B4D write/release acceptance has not been established by this release. Older npm 2.1.0 still has the reported source-patch limitations; upgrading the package and its pinned host registration is required to use the fixes.
Select the existing sap-change-object prompt, with the configured systemId,
exact Z program/class as target, and desired behavior in goal. It reuses
source, semantic/public API, dependency, quality and transport features.
Production/read-only policy, package restrictions, transport requirements and exact-source checks remain enforced. In 2.2.0, source writes recheck the same current-source view under lock, without an explicit inactive probe. A changed current version stops the write. Requested activation follows successful unlock and is skipped on syntax errors. Uncertain multi-object writes stop with saved/uncertain/unattempted identities; there is no automatic rollback or atomic-transaction claim. Inspect state before retrying. Zero tests, unsupported checks and partial findings cannot establish completion.
For a read-only evaluation, keep readOnly: true and expose only search,
describe and invoke_read gateways in the host. Do not execute write, activation,
Unit, ATC, debugger or profiling operations during that evaluation.
See workflow prompts and T1–T5 criteria.
Scope | Evidence and limit |
Clean npm tarball, macOS arm64, Node 24 | Eight launch/profile combinations, Unicode/spaces, help, invalid commands and shutdown passed on the reliability candidate |
macOS Keychain | Actual throwaway legacy-item/UTF-8/9,000-byte storage, renewal and deletion passed |
Windows read-only field procedure | Owner reports all supplied steps passed without candidate source changes; sanitized operation records were not supplied |
Windows DPAPI / npx.cmd automation | Windows CI passed: native storage/module-shadow regression, bundled launchers and eight installed-tarball protocol cases |
Native Desktop MCPB / host restart | Standalone bundle checks and an owner's overall field report remain distinct from retained app-level evidence |
Current 2.x live-SAP acceptance | not verified by retained operation-level records; owner-reported read-only completion is recorded separately |
Historical live SAP / model comparison | 2026-08-05 results are historical; no identical-model T1–T5 completion rate or product ranking is established |
Candidate measurements reduced compressed npm size from 26.29 to 13.33 MB and installed dependency bytes from 118.89 to 91.81 MB. Three warm protocol sessions measured 346–351 to 223–239 ms. Cold install was 12.92 to 16.06 seconds; no cold speed improvement is claimed. See exact snapshots and limits.
Symptom | Next action |
MCP closes immediately | Keep |
| Complete local setup and reconnect; this state is not an accepted SAP installation |
Removed Node/cache or old registered version | |
Certificate untrusted / expired / hostname mismatch | Keep verification enabled; use the company CA PEM file or ask the administrator to fix the certificate/URL. See TLS trust |
SAP URL unknown | On Windows use SAP Logon import to find candidate URLs, then check ADT and confirm the endpoint with your administrator |
SAP authentication/authorization failure | Renew locally or ask the administrator for ADT permission; avoid blind repeated logins |
Inactive conflict / uncertain write | Read current active/inactive state and reconcile with its owner before resuming |
Transport assure and CI, full reference, CLI, profiles, changelog.
Reliability validation and field procedure. Checkout manifest version: 2.2.0.
Normal clients should omit both --api-version and --toolsets.
PRIVACY.md: no default remote telemetry. Credentials remain in OS-protected storage. Feedback exports are voluntary; public adopter names and quotes require separate explicit permission. Downloads and automated tests do not establish active users, task success or independent adoption.
Get exact input schemas and hashes: name or names (up to 10).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| names | No | ||
| includeOutputSchema | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive, so the safety profile is covered. The description adds that the return is 'exact input schemas and hashes', which is useful behavioral context, but says nothing about error handling for unknown names or how the hash should be used.
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?
A single dense sentence with no filler and the verb/object front-loaded. The telegraphic ': name or names (up to 10)' phrasing is efficient, though slightly clipped for a first read.
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 simple read tool with annotations covering safety and no output schema, the description is serviceable but thin: it never explains what a 'hash' is for, when the described schema should be fetched, or how the result feeds into the invoke_* siblings.
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 0%, so the description must compensate. It does clarify the name-or-names alternation and the 10-item cap, but completely omits includeOutputSchema, which materially changes the response and is the one parameter an agent would most likely mis-set.
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?
States a specific verb ('Get') and resource ('exact input schemas and hashes') tied to SAP capabilities, so the agent knows this is a schema-discovery tool. It implicitly separates itself from the invoke_* siblings, but never explicitly names them or states the relationship.
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?
There is no when-to-use guidance at all: nothing says this should be called before sap.capability.invoke_read/write/destructive to learn the required inputs, nor any exclusion against sap.capability.search. The intended workflow is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke a destructive capability with its described schemaHash and arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | No | ||
| schemaHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact – that the invocation is bound to a 'described' schemaHash – but says nothing about irreversibility, argument validation, or what happens if the hash does not match.
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?
One short sentence with no filler and the key requirement front-loaded, which is the right shape for a dispatch-style tool. It is efficient rather than wasteful, though its brevity leaves real questions unanswered given 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?
For a destructive, open-world dispatcher with no output schema, nested argument objects and 0% schema coverage, the definition is insufficient. An agent cannot tell how to obtain a valid schemaHash, how arguments are validated, or what a destructive result looks like, and no prior-step workflow is described.
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 0% across three parameters, so the description must carry the burden and largely does not. It mentions schemaHash and arguments by name but gives no meaning for either (origin of the hash, validation against the described capability, free-form argument shape), and it omits the required 'name' parameter entirely.
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 names a specific verb (invoke) and a scoped resource (a destructive capability), which lets an agent separate it from the read/write siblings at a glance. It is clear but thin: it never explains what a 'capability' is or that the target is resolved by name, so the purpose is understood only at the level of the title.
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?
There is no guidance on when to choose invoke_destructive over invoke_write or invoke_read, and no prerequisite stated even though the schemaHash clearly implies a prior describe call. The only hint of routing is the word 'destructive' in the name, which the sibling names already convey.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke a read capability with its described schemaHash and arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | No | ||
| schemaHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond the schema: no error behavior, no hash-mismatch semantics, no note that the capability is dispatched by name from an open-world catalog.
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?
A single front-loaded sentence with no filler; the invocation and its two key inputs lead the sentence. It is efficient, though its brevity comes at the cost of specification rather than being a model of tightness.
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?
This is a generic dispatcher for an open-world capability catalog with no output schema and zero parameter documentation, so the description carries a heavy burden. It omits how to discover valid 'name' values, how to obtain the required 64-hex schemaHash, and what failure modes exist, leaving an agent unable to call it reliably without trial and error.
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 0% across three parameters (two required), and the description only names 'schemaHash' and 'arguments' without explaining format, origin, or how the arguments object must match the target capability's schema. The phrase 'described schemaHash' hints at provenance but does not compensate for the total absence of parameter documentation.
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 states a specific verb and resource ('invoke a read capability'), and the 'read' qualifier separates it from sibling tools invoke_write and invoke_destructive without the agent needing to open those schemas. However, it never explains what a 'capability' is in this system, leaving the resource concept abstract.
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?
There is no when-to-use guidance, no exclusions, and no mention of the alternative siblings (search, describe, invoke_write). The word 'described' weakly implies the schemaHash must first be obtained elsewhere, likely via sap.capability.describe, but this prerequisite is never stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invoke a write capability with its described schemaHash and arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | No | ||
| schemaHash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false and openWorldHint=true, so the safety profile is partly carried by structured data. The description adds nothing beyond that: it does not say whether the write is reversible, whether it requires prior describe/search to obtain a valid schemaHash, or how it differs behaviorally from the destructive sibling.
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?
A single front-loaded sentence with no filler, which is structurally clean. However, it is under-specified rather than concise by design, leaving no room for the routing or parameter guidance the tool needs.
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 non-idempotent, open-world write tool with a nested arguments object, 0% parameter documentation, and no output schema, the description is too thin. It does not explain how to obtain the schemaHash, what happens on mismatch, or how it relates to the destructive variant.
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 0%, so the schema gives no prose for any of the three parameters. The description mentions schemaHash and arguments but omits the required 'name' parameter entirely and offers no format, sourcing, or validation guidance (e.g., that schemaHash must be a 64-char hex digest obtained from describe).
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?
States a verb (invoke) and scope (write capability) with the two things it needs, but 'capability' is a meta-resource and the description never distinguishes this from the sibling sap.capability.invoke_destructive, which is the boundary an agent most needs to see. Purpose is inferable but not sharp.
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?
No when-to-use, when-not-to-use, or alternative routing is given, despite three closely related siblings (invoke_read, invoke_destructive, describe). The agent is left to guess whether a given capability should go through invoke_write or invoke_destructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find capabilities; browse categories if keyword search misses.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| risk | No | ||
| limit | No | ||
| query | No | ||
| cursor | No | ||
| category | No |
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 structurally. The description adds the useful behavioral detail that there are two lookup modes (keyword vs. category browse), but says nothing about pagination, result limits, or what the returned capability records contain.
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?
A single front-loaded clause pair with no filler; the primary action precedes the fallback. Brevity here borders on under-specification given the six undocumented parameters, but the sentence itself is efficient.
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?
With six parameters at zero schema coverage, no output schema, and an enum param whose meaning is never explained, an agent cannot reliably construct a call — limit/cursor pagination semantics and the risk filter are entirely absent. The description does not compensate for the structural gaps.
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 0% across 6 parameters, so the description carries the full burden. It only gestures at two of them ('keyword search' maps to query, 'categories' maps to category) and leaves name, risk (an enum with read/write/destructive), limit, and cursor completely unexplained.
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?
States a specific verb and resource ('Find capabilities') and implies a discovery-only role via keyword browsing, which distinguishes it in spirit from the invoke_* siblings. It never names those siblings or explicitly says it does not execute capabilities, so differentiation is left to inference.
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 one fallback rule: 'browse categories if keyword search misses,' which implies when to use the category parameter. There is no guidance on when to search vs. call sap.capability.describe, and no mention of exclusions or 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.
v2.0.1sap.capability.describe2 fields changedInput schema / properties / namesAdded value: +{
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 10,
+ "minItems": 1,
+ "type": "array"
+}Input schema / requiredRemoved value: -[
- "name"
-]v1.7.0sap.artifact.mermaid.createsap.artifact.mermaid.detectsap.artifact.mermaid.validatesap.artifact.test_document.createsap.capability.describesap.capability.invoke_destructivesap.capability.invoke_readsap.capability.invoke_writesap.capability.searchsap.classic.readsap.classic.writesap.data.exportsap.data.querysap.ddic.readsap.ddic.updatesap.debug.breakpoint.removesap.debug.breakpoint.setsap.debug.evaluatesap.debug.session.inspectsap.debug.session.startsap.debug.session.stopsap.debug.stacksap.debug.statussap.debug.stepsap.debug.variablessap.execution.executesap.execution.healthsap.execution.previewsap.git.branch.switchsap.git.checksap.git.createsap.git.inspectsap.git.listsap.git.pullsap.git.pushsap.git.stagesap.git.unlinksap.ops.watch.historysap.ops.watch.startsap.ops.watch.statussap.ops.watch.stopsap.ops.watch.task.addsap.ops.watch.task.disablesap.ops.watch.task.enablesap.ops.watch.task.listsap.ops.watch.task.removesap.ops.watch.task.updatesap.ops.watch.triggersap.ops.watch.watchlist.readsap.quality.atc.cachedsap.quality.atc.documentationsap.quality.atc.runsap.quality.test_include.createsap.quality.unit_testsap.rap.availabilitysap.rap.binding.inspectsap.rap.binding.publishsap.rap.binding.unpublishsap.rap.defaultssap.rap.generatesap.rap.previewsap.rap.schemasap.rap.validatesap.refactor.executesap.refactor.previewsap.repository.comparesap.repository.createsap.repository.delete.executesap.repository.delete.previewsap.repository.dependency_graphsap.repository.inspectsap.repository.resolvesap.repository.searchsap.repository.where_usedsap.runtime.dump.inspectsap.runtime.dump.listsap.runtime.feed.readsap.runtime.trace.configurationsap.runtime.trace.hit_listsap.runtime.trace.inspectsap.runtime.trace.listsap.runtime.trace.statementssap.semantic.completesap.semantic.componentssap.semantic.definitionsap.semantic.documentationsap.semantic.format_previewsap.semantic.hierarchysap.semantic.quick_fixessap.source.activatesap.source.diagnosesap.source.exportsap.source.patchsap.source.readsap.source.read_batchsap.source.searchsap.system.capabilitiessap.system.discoverysap.system.discovery.exportsap.system.inspectsap.system.listsap.text_elements.readsap.text_elements.writesap.transport.assesssap.transport.comparesap.transport.createsap.transport.deletesap.transport.inspectsap.transport.listsap.transport.object.addsap.transport.object.resolvesap.transport.owner.setsap.transport.releasesap.transport.user.addsap.transport.user.listsap.ui.object_urlsap.ui.transaction_launchsap.ui.transaction_urlsap.version.history.comparesap.version.history.listsap.version.history.readsap.version.inactive.listsap.version.inactive.readsap.version.restore.executesap.version.restore.previewv1.4.0sap.classic.readsap.classic.writesap.ddic.readsap.ddic.updatesap.repository.create2 fields changedInput schema / properties / activate / descriptionAdded value: +"Activate after writing create-time source"Input schema / properties / source / descriptionAdded value: +"Create-time source for textual ADT object types"sap.repository.inspect5 fields changedInput schema / properties / childLimitAdded value: +{
+ "default": 50,
+ "maximum": 500,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / childStartIndexAdded value: +{
+ "default": 0,
+ "maximum": 9007199254740991,
+ "minimum": 0,
+ "type": "integer"
+}Input schema / properties / includeChildrenAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Input schema / properties / includeEnhancementSourceAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Input schema / properties / includeEnhancementsAdded value: +{
+ "default": false,
+ "type": "boolean"
+}sap.repository.search1 field changedInput schema / properties / objectTypes / items / enumPrevious value: -[
- "FUNC",
- "CLAS",
- "TABL",
- "PROG",
- "INTF",
- "DTEL",
- "DDLS",
- "DOMA",
- "TTYP",
- "ENQU",
- "MSAG",
- "FUGR",
- "DEVC",
- "TRAN",
- "VIEW",
- "SICF",
- "WDYN",
- "SPRX",
- "XSLT",
- "TRANSFORMATIONS",
- "SUSH",
- "SUSC",
- "PINF",
- "ENHC",
- "ENHS",
- "BADI",
- "BADII",
- "SAMC",
- "SAPC",
- "SFSW",
- "SFBF",
- "SFBS",
- "JOBD",
- "NROB",
- "ENHO",
- "SUSO",
- "BDEF",
- "SRVB"
-]New value: +[
+ "FUNC",
+ "CLAS",
+ "TABL",
+ "PROG",
+ "INTF",
+ "DTEL",
+ "DDLS",
+ "DCLS",
+ "DDLX",
+ "DDLA",
+ "DOMA",
+ "TTYP",
+ "ENQU",
+ "MSAG",
+ "FUGR",
+ "DEVC",
+ "TRAN",
+ "VIEW",
+ "SICF",
+ "WDYN",
+ "SPRX",
+ "XSLT",
+ "TRANSFORMATIONS",
+ "SUSH",
+ "SUSC",
+ "PINF",
+ "ENHC",
+ "ENHS",
+ "BADI",
+ "BADII",
+ "SAMC",
+ "SAPC",
+ "SFSW",
+ "SFBF",
+ "SFBS",
+ "JOBD",
+ "NROB",
+ "ENHO",
+ "SUSO",
+ "BDEF",
+ "SRVD",
+ "SRVB"
+]sap.runtime.feed.readsap.source.read1 field changedInput schema / properties / objectType / enumPrevious value: -[
- "FUNC",
- "CLAS",
- "TABL",
- "PROG",
- "INTF",
- "DTEL",
- "DDLS",
- "DOMA",
- "TTYP",
- "ENQU",
- "MSAG",
- "FUGR",
- "DEVC",
- "TRAN",
- "VIEW",
- "SICF",
- "WDYN",
- "SPRX",
- "XSLT",
- "TRANSFORMATIONS",
- "SUSH",
- "SUSC",
- "PINF",
- "ENHC",
- "ENHS",
- "BADI",
- "BADII",
- "SAMC",
- "SAPC",
- "SFSW",
- "SFBF",
- "SFBS",
- "JOBD",
- "NROB",
- "ENHO",
- "SUSO",
- "BDEF",
- "SRVB"
-]New value: +[
+ "FUNC",
+ "CLAS",
+ "TABL",
+ "PROG",
+ "INTF",
+ "DTEL",
+ "DDLS",
+ "DCLS",
+ "DDLX",
+ "DDLA",
+ "DOMA",
+ "TTYP",
+ "ENQU",
+ "MSAG",
+ "FUGR",
+ "DEVC",
+ "TRAN",
+ "VIEW",
+ "SICF",
+ "WDYN",
+ "SPRX",
+ "XSLT",
+ "TRANSFORMATIONS",
+ "SUSH",
+ "SUSC",
+ "PINF",
+ "ENHC",
+ "ENHS",
+ "BADI",
+ "BADII",
+ "SAMC",
+ "SAPC",
+ "SFSW",
+ "SFBF",
+ "SFBS",
+ "JOBD",
+ "NROB",
+ "ENHO",
+ "SUSO",
+ "BDEF",
+ "SRVD",
+ "SRVB"
+]v1.0.1sap.artifact.mermaid.detectsap.artifact.mermaid.validatesap.data.exportsap.debug.breakpoint.removesap.debug.breakpoint.setsap.debug.evaluatesap.debug.session.inspectsap.debug.session.startsap.debug.session.stopsap.debug.stacksap.debug.stepsap.debug.variablessap.git.unlinksap.ops.watch.startsap.quality.atc.documentationsap.quality.atc.runsap.quality.unit_testsap.rap.availabilitysap.rap.binding.inspectsap.rap.defaultssap.rap.generatesap.rap.previewsap.rap.schemasap.rap.validatesap.repository.searchsap.runtime.dump.inspectsap.runtime.dump.listsap.runtime.trace.inspectsap.runtime.trace.listsap.runtime.trace.statementssap.semantic.quick_fixessap.source.exportsap.source.readsap.source.searchsap.system.capabilitiessap.system.discoverysap.transport.assesssap.transport.object.resolvesap.transport.user.listsap.ui.transaction_launchsap.ui.transaction_urlsap.version.history.comparesap.version.history.listsap.version.history.readsap.version.inactive.listsap.version.inactive.readsap.version.restore.previewv1.0.0abap_activateabap_debug_breakpointabap_debug_sessionabap_debug_stackabap_debug_statusabap_debug_stepabap_debug_variableabap_downloadabap_fs_documentationadt_discovery_exportanalyze_abap_dumpsanalyze_abap_tracescompare_abap_systemscreate_mermaid_diagramcreate_object_programmaticallycreate_test_documentationcreate_test_includedetect_mermaid_diagram_typeexecute_data_queryfind_where_usedget_abap_dependency_graphget_abap_diagnosticsget_abap_object_infoget_abap_object_linesget_abap_object_workspace_uriget_abap_sql_syntaxget_atc_decorationsget_batch_linesget_mermaid_documentationget_object_by_uriget_version_historyinspect_abap_codemanage_abap_versionsmanage_abapgitmanage_heartbeatmanage_rap_generatormanage_transport_requestsopen_objectrefactor_abap_codereplace_string_in_abap_objectrun_abap_applicationrun_atc_analysisrun_sap_transactionrun_unit_testssap.artifact.mermaid.createsap.artifact.test_document.createsap.data.querysap.debug.statussap.execution.executesap.execution.healthsap.execution.previewsap.git.branch.switchsap.git.checksap.git.createsap.git.inspectsap.git.listsap.git.pullsap.git.pushsap.git.stagesap.ops.watch.historysap.ops.watch.statussap.ops.watch.stopsap.ops.watch.task.addsap.ops.watch.task.disablesap.ops.watch.task.enablesap.ops.watch.task.listsap.ops.watch.task.removesap.ops.watch.task.updatesap.ops.watch.triggersap.ops.watch.watchlist.readsap.quality.atc.cachedsap.quality.test_include.createsap.rap.binding.publishsap.rap.binding.unpublishsap.refactor.executesap.refactor.previewsap.repository.comparesap.repository.createsap.repository.delete.executesap.repository.delete.previewsap.repository.dependency_graphsap.repository.inspectsap.repository.resolvesap.repository.where_usedsap.runtime.trace.configurationsap.runtime.trace.hit_listsap.semantic.completesap.semantic.componentssap.semantic.definitionsap.semantic.documentationsap.semantic.format_previewsap.semantic.hierarchysap.source.activatesap.source.diagnosesap.source.patchsap.source.read_batchsap.system.discovery.exportsap.system.inspectsap.system.listsap.text_elements.readsap.text_elements.writesap.transport.comparesap.transport.createsap.transport.deletesap.transport.inspectsap.transport.listsap.transport.object.addsap.transport.owner.setsap.transport.releasesap.transport.user.addsap.ui.object_urlsap.version.restore.executesearch_abap_object_linesvalidate_mermaid_syntaxv0.4.15abap_activate5 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesAdded value: +falseInput schema / properties / connectionIdAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / urlAdded value: +{
+ "description": "One ABAP workspace URI to activate",
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / urlsAdded value: +{
+ "description": "One through 100 same-connection ABAP workspace URIs to activate in one batch",
+ "items": {
+ "minLength": 1,
+ "type": "string"
+ },
+ "maxItems": 100,
+ "minItems": 1,
+ "type": "array"
+}create_object_programmatically2 fields changedInput schema / properties / activate / descriptionAdded value: +"Activate after create-time source writing; currently supported only for BDEF/BDO"Input schema / properties / source / descriptionAdded value: +"Create-time source; currently supported only for BDEF/BDO"get_abap_object_urlget_connected_systemsget_sap_capabilitiesget_sap_system_infomanage_text_elementsmanage_transport_requests7 fields changedInput schema / properties / action / enumPrevious value: -[
- "get_user_transports",
- "get_transport_details",
- "get_transport_objects",
- "compare_transports",
- "create_transport",
- "release_transport",
- "delete_transport",
- "set_owner",
- "add_user",
- "add_object",
- "list_system_users",
- "resolve_object"
-]New value: +[
+ "get_user_transports",
+ "get_transport_details",
+ "get_transport_objects",
+ "assess_transport",
+ "compare_transports",
+ "create_transport",
+ "release_transport",
+ "delete_transport",
+ "set_owner",
+ "add_user",
+ "add_object",
+ "list_system_users",
+ "resolve_object"
+]Input schema / properties / checksAdded value: +{
+ "default": [
+ "atc",
+ "unit_tests"
+ ],
+ "items": {
+ "enum": [
+ "atc",
+ "unit_tests",
+ "target_compare"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / failOnAtcWarningsAdded value: +{
+ "default": false,
+ "type": "boolean"
+}Input schema / properties / maxObjectsAdded value: +{
+ "default": 20,
+ "maximum": 200,
+ "minimum": 1,
+ "type": "integer"
+}Input schema / properties / reportDirectoryAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / reportFormatsAdded value: +{
+ "default": [
+ "json"
+ ],
+ "items": {
+ "enum": [
+ "json",
+ "sarif",
+ "junit"
+ ],
+ "type": "string"
+ },
+ "maxItems": 3,
+ "minItems": 1,
+ "type": "array"
+}Input schema / properties / targetConnectionIdAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}search_abap_objectsv0.4.6run_abap_application8 fields changedInput schema / $schemaAdded value: +"http://json-schema.org/draft-07/schema#"Input schema / properties / actionAdded value: +{
+ "enum": [
+ "repl_health",
+ "preview_class",
+ "preview_snippet",
+ "execute"
+ ],
+ "type": "string"
+}Input schema / properties / classNameAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / codeAdded value: +{
+ "maxLength": 98304,
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / confirmationAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / connectionIdAdded value: +{
+ "minLength": 1,
+ "type": "string"
+}Input schema / properties / planIdAdded value: +{
+ "format": "uuid",
+ "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+ "type": "string"
+}Input schema / requiredAdded value: +[
+ "action",
+ "connectionId"
+]v0.4.5abap_activateabap_debug_breakpointabap_debug_sessionabap_debug_stackabap_debug_statusabap_debug_stepabap_debug_variableabap_downloadabap_fs_documentationadt_discovery_exportanalyze_abap_dumpsanalyze_abap_tracescompare_abap_systemscreate_mermaid_diagramcreate_object_programmaticallycreate_test_documentationcreate_test_includedetect_mermaid_diagram_typeexecute_data_queryfind_where_usedget_abap_dependency_graphget_abap_diagnosticsget_abap_object_infoget_abap_object_linesget_abap_object_urlget_abap_object_workspace_uriget_abap_sql_syntaxget_atc_decorationsget_batch_linesget_connected_systemsget_mermaid_documentationget_object_by_uriget_sap_capabilitiesget_sap_system_infoget_version_historyinspect_abap_codemanage_abap_versionsmanage_abapgitmanage_heartbeatmanage_rap_generatormanage_text_elementsmanage_transport_requestsopen_objectrefactor_abap_codereplace_string_in_abap_objectrun_abap_applicationrun_atc_analysisrun_sap_transactionrun_unit_testssearch_abap_object_linessearch_abap_objectsvalidate_mermaid_syntaxScored across 5 tools
Each tool has a clearly distinct role: search discovers capabilities, describe retrieves schemas/hashes, and the three invoke tools are cleanly separated by effect class (read/write/destructive). An agent can select the right tool based on intent without overlapping functionality.
All tools follow the same `sap.capability.<action>` namespace with lowercase and snake_case suffixes. The invoke variants consistently append the effect type, creating a predictable and readable pattern.
Five tools neatly cover the generic capability gateway pattern: discovery, introspection, and execution split by effect class. Each tool earns its place with no redundant or missing meta-operations.
The set covers discovery (search), schema retrieval (describe), and execution across all effect classes (read/write/destructive), forming a complete lifecycle for invoking SAP capabilities without obvious dead ends.
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.
Hosted MCP server connecting AI assistants to 9,000+ apps and 40,000+ actions via Zapier.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
