Skip to main content
Glama
Coaspe

sap-abap-mcp

by Coaspe

Invoke Destructive SAP Capability

sap.capability.invoke_destructive
Destructive

Trigger a destructive SAP ABAP operation by providing its capability name, schema hash, and arguments for controlled changes or deletions.

Instructions

Invoke a destructive capability with its described schemaHash and arguments.

Input Schema

NameRequiredDescriptionDefault
nameYes
argumentsNo
schemaHashYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.7.0

TDQS

C2.9/5.0
Behavior3/5

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.

Conciseness4/5

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.

Completeness2/5

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.

Parameters2/5

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.

Purpose4/5

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.

Usage Guidelines2/5

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.