Data provider class in the Hub MCP Designer

Interface

The DPC must implement /neptune/if_dxp_mcp_dpc.

Unlike the Hub API Designer, which uses public class attributes for importing and exporting data, the Hub MCP Designer derives tools solely from the method signature. The method name becomes the tool name, importing parameters become the tool’s input schema, and exporting parameters become the tool’s output schema. There are no public attributes involved in the MCP tool contract.

This means that the names you give your methods and parameters in ABAP are directly visible to the AI agent as tool and parameter names. Choose names that are clear and meaningful in natural language rather than internal technical conventions. Where an API DPC class uses system abbreviations, Hungarian notation prefixes, or SAP field names as parameter names, a purpose-built MCP DPC class gives you the opportunity to define a cleaner interface that the model can work with more reliably.

Methods and tools

In the Hub MCP Designer, each public method in the DPC is available as a tool. Tools are disabled by default. A tool only appears in tool lists and becomes callable once it is actively enabled in the Hub MCP Designer.

Within the Hub MCP Designer, you can also configure descriptions, formats, minimum and maximum values, and enumeration values for tools, their parameters, and any structured content they return.

Implementation recommendations

When implementing DPC methods, apply the following practices to produce tools that are reliable and efficient for AI agent use:

  • Give methods names that reflect their intent clearly. Method names become tool names and are used by the model to decide which tool to call.

  • For simple parameters, use the most specific suitable ABAP data type to produce an accurate JSON Schema type with appropriate constraints.

  • For structured and tabular data, define dedicated structures with meaningful attribute names and suitable data types, rather than reusing existing technical structures directly.

  • Implement authorization checks within the method to ensure tools do not expose data to unauthorized users.

  • Return only the data the model needs to complete the task. Avoid passing through raw API payloads or full table data not required for the tool’s purpose.

  • Raise /neptune/cx_dxp_http_mcp_exec with a descriptive message for execution errors, so the model receives actionable information when a tool call fails.

For a further best practices for tool naming, parameter design, output scoping, and related considerations, see MCP tool design best practices.

ABAP type to JSON Schema type mapping

When you assign types to your method parameters in ABAP, the Hub MCP Designer automatically translates them into the appropriate JSON Schema types — including formats, constraints, and patterns where relevant. You do not need to configure these manually. The schema is derived directly from your method signature.

Parameter and property names are lower-cased in the generated schema. For example, an ABAP parameter named CUSTOMER_ID becomes customer_id in the JSON Schema. Keep this in mind when writing tool descriptions or instructions that reference specific parameter names.

A parameter is required in the schema only when it is non-optional and carries no default value. A parameter with a default value is treated as optional, regardless of its ABAP declaration.

ABAP type JSON Schema type Notes

Table type

array

Items schema derived from the line type; nesting is recursive

Structure type

object

Included structures (as_include) are flattened into the parent’s properties

abap_bool, abap_boolean, xfeld, boole_d

boolean

timestamp, timestampl

string

Format: date-time

int1

integer

Minimum: 0, Maximum: 255

int2

integer

Minimum: −32768, Maximum: 32767

int4, int8

integer

i

integer

packed, float, decfloat16, decfloat34, utclong

number

d

string

Format: date

t

string

Format: time

c

string

Maximum length derived from the type definition

n

string

Maximum length derived from the type definition; numeric pattern applied

Any other type

string

Fallback for unresolvable or unsupported ABAP types

Error handling in DPC methods

Use the following exception classes when implementing DPC methods to signal errors to the MCP runtime. The exception class you raise determines how the error is returned to the calling MCP client.

Exception class Used for Resulting response

/neptune/cx_dxp_http_mcp_exec

Business logic or execution errors within a tool

A successful tool result with isError: true and the exception message as content. The client receives a well-formed tool result, not a protocol error.

/neptune/cx_dxp_http_mcp_prot

MCP protocol-level errors

A JSON-RPC error response. Use this only when the error relates to the MCP protocol itself, not to the tool’s business logic.

In most cases, raise /neptune/cx_dxp_http_mcp_exec to communicate tool failures to the agent. This keeps the MCP exchange intact and passes the error message back as readable content that the AI agent can handle or report.

Related topics