Skip to main content
Glama
Hollway

mcp-abap-abap-adt-api

by Hollway
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

runSnippet

Execute ABAP code on the SAP system to test function modules, class methods, or calculations, and return the printed output.

Instructions

Run a piece of ABAP on the system and return what it printed. The snippet is wrapped in a throwaway class implementing IF_OO_ADT_CLASSRUN, created in $TMP, activated, executed with runClass and deleted again - which is the only way ADT executes ABAP at all. Write output with out->write( lv_x ) or out->write_text( ... ); out is the console object the interface hands to main. It answers the questions no read can: what a function module returns for these inputs, what a class method does with this data, what a calculation comes to. It runs code on the target system as your user, so a snippet that writes changes data - it counts as a writing tool and is refused in read-only mode. On a syntax error the activation messages come back with the source, and the class is removed either way.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeYesThe ABAP to run, line by line, as it would stand inside a method. `out` is available for output.
dryRunNoReturn the class source that would be created, without touching the system.
classNameNoName for the throwaway class. Default: ZMCP_SNIP_<timestamp in base 36>.
keepClassNoLeave the class on the system instead of deleting it - for a snippet to run again or open in ADT. Default false.
transportNoTransport request, needed only outside $TMP.
packageNameNoWhere to create it. Default $TMP, which needs no transport; anything else does.
declarationsNoClass-level declarations the snippet needs: TYPES, CONSTANTS, DATA. They go into the private section.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, but the description goes beyond: it explains the tool's side effects (writes data), safety ('refused in read-only mode'), lifecycle (created in $TMP, activated, executed, deleted), and error handling (syntax errors return activation messages). It discloses that it runs as the user. This is rich behavioral context beyond annotations.

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?

The description is efficient and front-loaded: the core purpose and mechanism are in the first sentence. It includes necessary detail about the wrapping class Demo and output method. It has some redundancy (repeats the 'throwaway class' point) but overall each sentence earns its place. Could be slightly tightened but is well-organized.

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

Completeness5/5

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

For a tool with 7 parameters, 1 required, no output schema, this description is complete. It explains the execution model, the output mechanism, the side effects, the error behavior, and the prerequisites (transport for non-$TMP). There is no output schema, but the description explains the return value ('what it printed' and the activation messages on syntax error). The integration with siblings is clear. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

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 each parameter. However, the description adds critical context: it explains how the code is wrapped (in a class with IF_OO_ADT_CLASSRUN), how output works (out->write), and the purpose of the 'declarations' parameter (they go into a private section). It also explains the dryRun and keepClass semantics indirectly by describing the lifecycle. This adds valuable meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states what the tool does: 'Run a piece of ABAP on the system and return what it printed.' It specifies the verb (run), the resource (ABAP snippet), and the output (printed output). It distinguishes itself from siblings by explaining that it's the only way to execute ABAP and by referencing the alternative 'runClass' indirectly. The description is specific and not a tautology.

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

Usage Guidelines5/5

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

The description explains when to use this tool: 'It answers the questions no read can...' and implies it's for executing code when read-only tools are insufficient. It also states when NOT to use it: 'it counts as a writing tool and is refused in read-only mode.' It references the mechanism (runClass) and the necessity of the wrapper class. This is explicit context for selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools