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

abap-config-mcp

by netweaver1970
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Ping Customizing Engine

customizing_engine_ping
Read-onlyIdempotent

Pings the Customizing Engine SICF endpoint to verify service activity and bootstrap success, reporting deployed vs expected version, release, client, and features. Use rawDump for unexpected responses.

Instructions

Call the Customizing Engine's SICF endpoint with a ping and report the deployed version against the version this server expects, plus the release, client and which engine features the system offers. Use it to confirm customizing_engine_bootstrap worked and the SICF service is active; a version mismatch means run bootstrap again. Read-only: changes nothing in SAP. On failure, retry with rawDump to see the raw HTTP response.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "customizing_engine_ping"
  }
}

Input Schema

NameRequiredDescriptionDefault
icfPathNoSICF path the engine service is registered under (default: /sap/bc/zmcp_cust)
rawDumpNoReturn the HTTP status, content type and first 2000 characters of the body instead of the parsed result (default false); use when the engine answers with unexpected content
connectionIdNoSAP system connection ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.16.2
    • changedInput schema / properties / icfPath / description
      Previous value: -"SICF path of the engine (default: /sap/bc/zmcp_cust)"New value: +"SICF path the engine service is registered under (default: /sap/bc/zmcp_cust)"
    • changedInput schema / properties / rawDump / description
      Previous value: -"Return the raw HTTP body for diagnostics instead of parsing it (useful when the engine is reachable but returning unexpected content)"New value: +"Return the HTTP status, content type and first 2000 characters of the body instead of the parsed result (default false); use when the engine answers with unexpected content"
  2. First observedv1.16.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so 'Read-only: changes nothing in SAP' largely restates the stated safety profile. The description does add real behavioral value beyond that: what the ping returns, how a version mismatch should be interpreted, and an escalation path ('retry with rawDump') when the engine answers with unexpected content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the action and the returned payload, then the diagnostic use case, then the safety statement, then the failure path. Nothing is repeated unnecessarily and there is no filler.

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?

There is no output schema, yet the description compensates by enumerating what the ping reports (version comparison, release, client, features). Combined with the failure handling via rawDump and the version-mismatch remediation, an agent has everything needed to call and interpret this tool.

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

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented, and the description's only parameter mention (rawDump on failure) duplicates the schema's own 'use when the engine answers with unexpected content' note. icfPath and connectionId receive no additional meaning in the description. This is the baseline case where the schema carries the load.

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 names a concrete verb and resource (ping the Customizing Engine's SICF endpoint) and enumerates exactly what is reported back: deployed version vs. expected version, release, client, and offered features. That is specific enough to separate it from siblings like customizing_engine_bootstrap or customizing_status without opening their schemas.

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

Usage Guidelines4/5

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

It gives explicit context for use ('confirm customizing_engine_bootstrap worked and the SICF service is active') and a concrete remediation rule ('a version mismatch means run bootstrap again'), which routes the agent between two siblings. It does not contrast against other superficially similar diagnostics such as customizing_selftest, so it falls short of a full when/when-not/alternatives statement.

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