Skip to main content
Glama
ethanhan2014

sap-s4hana-odata-mcp

by ethanhan2014
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

sap-s4hana-odata-mcp

An MCP (Model Context Protocol) server for querying SAP S/4HANA Business Partner data via OData V2 API. Connects directly to on-premise S/4HANA systems using Basic Authentication.

Tools

Tool

Description

list_business_partners

List business partners with OData filtering, sorting, pagination, and field selection

get_business_partner

Get a specific business partner by ID with optional $expand for addresses, roles, etc.

Related MCP server: MCP ABAP Server

Setup

npm install
cp .env.example .env   # then edit with your S/4HANA connection details
npm run build

Configuration

All settings are in .env:

Variable

Required

Description

Example

S4HANA_HOSTNAME

Yes

S/4HANA application server hostname

s4hana.example.com

S4HANA_SYSNR

Yes

SAP system number (00-99)

50

S4HANA_USE_HTTPS

No

Use HTTPS (default: true)

true

S4HANA_USERNAME

Yes

SAP technical user

TECH_USER

S4HANA_PASSWORD

Yes

Password

secret123

S4HANA_CLIENT

No

SAP client number

001

S4HANA_ODATA_PATH

No

OData service path (default: /sap/opu/odata/sap/API_BUSINESS_PARTNER)

/sap/opu/odata/sap/API_BUSINESS_PARTNER

Port Calculation

The HTTP/HTTPS port is derived from the system number:

  • HTTPS port = 443 + system number (e.g. sysnr 50 -> port 44350)

  • HTTP port = 80 + system number (e.g. sysnr 50 -> port 8050)

Finding Your Connection Details

Run transaction SMICM in SAP GUI to find the hostname, system number, and active ports:

  1. Open SAP GUI and enter tcode SMICM

  2. Go to Goto > Services to see the list of active HTTP/HTTPS services

  3. Note the hostname and port numbers — the system number is the last two digits of the port (e.g. port 44350 means sysnr 50)

Usage with Claude Code

Add to .claude.json:

{
  "mcpServers": {
    "s4hana-bp": {
      "command": "node",
      "args": ["/path/to/sap-s4hana-odata-mcp/dist/index.js"]
    }
  }
}

Example Queries

List first 10 business partners:

Show me the first 10 business partners

Search by name:

Find business partners with "SAP" in the name

Filter by category (1=Person, 2=Organization):

List all person-type business partners

Get details with address:

Get business partner 21 with their address

Tech Stack

  • TypeScript

  • MCP SDK

  • Axios for OData HTTP calls

  • Zod for input validation

  • dotenv for configuration

License

MIT

Available Tools

2 tools
get_business_partnerA

Get a specific business partner by ID from SAP S/4HANA. Returns full details. Use $expand to include related data like addresses or roles.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesBusiness Partner ID (e.g. '1000001')
expandNoOData $expand (e.g. "to_BusinessPartnerAddress,to_BusinessPartnerRole")
selectNoComma-separated fields to return

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations available, the description must carry the behavioral disclosure burden. It states that the tool returns full details by default and that $expand can include related data, which is useful. However, it does not address response format, error behavior, or the effect of combining select and expand.

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?

The description is two sentences with no filler. It front-loads the primary purpose and then provides the most relevant optional-use guidance, so every sentence earns its place.

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

Completeness4/5

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

For a simple single-resource retrieval tool, the description is largely complete: it identifies the target resource, notes the return behavior, and covers the expand option. It could be more explicit about select usage and the exact response shape, but with a fully documented schema and a clear sibling contrast, nothing critical is missing.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3. The description adds value by clarifying that $expand includes related data like addresses and roles, and by framing the id as targeting a specific business partner. This goes slightly beyond the schema's generic descriptions.

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 the tool's function: retrieving a specific business partner by ID from SAP S/4HANA. It distinguishes itself from the sibling list_business_partners by emphasizing a single, specific entity rather than a collection.

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?

The description implies when to use this tool (when a specific business partner ID is known) rather than listing business partners. It also provides guidance on using $expand to include related data, but it does not explicitly state when not to use it or mention the sibling alternative by name.

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

list_business_partnersB

List business partners from SAP S/4HANA. Supports OData filtering, sorting, pagination, and field selection. Category '1' = Person, '2' = Organization. Use $filter for search, e.g. substringof('keyword',BusinessPartnerFullName).

ParametersJSON Schema
NameRequiredDescriptionDefault
topNoMax results (default: 20, max: 100)
skipNoRecords to skip (pagination)
expandNoOData $expand (e.g. "to_BusinessPartnerAddress")
filterNoOData $filter (e.g. "BusinessPartnerCategory eq '1'", "substringof('SAP',BusinessPartnerFullName)")
selectNoComma-separated fields to return
orderbyNoOData $orderby (e.g. "BusinessPartnerFullName asc")

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does add useful context by mentioning OData capabilities and the category code mapping. However, it does not disclose authentication requirements, default/return behavior, or potential errors, which is a notable gap for a tool with no annotation coverage.

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?

Three sentences with no filler: the purpose, OData capabilities, and category mapping are front-loaded, and the filter example is practical. It is concise while each sentence contributes useful information.

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

Completeness3/5

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

The description is reasonably complete for a list operation: purpose, OData capabilities, and an example are present, and parameter details live in the schema. Still, without an output schema or annotations, it leaves return-shape details and pagination defaults unaddressed, and it doesn't point to get_business_partner for singular lookups.

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

Parameters4/5

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

The schema already covers all 6 parameters, providing a baseline of 3. The description goes beyond by explaining that category '1' means Person and '2' means Organization and giving a concrete $filter example with substringof, which adds genuine semantic value.

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 clearly states the tool lists business partners from SAP S/4HANA and highlights OData filtering, sorting, pagination, and field selection. While the verb 'List' distinguishes it from the sibling 'get_business_partner', there is no explicit contrast naming that sibling, so it stops short of full differentiation.

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?

No explicit guidance is given on when to use this tool versus get_business_partner. The only usage hint, using $filter for search, is a how-to rather than a tool-selection criterion, leaving the agent to infer the appropriate context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedget_business_partner
    • First observedlist_business_partners
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 2 tools

Disambiguation5/5

list_business_partners and get_business_partner are clearly distinct: one handles collection-level querying with filters/pagination, the other handles single-record retrieval by ID. There is no overlap or ambiguity between them.

Naming Consistency5/5

Both tools follow the same verb_noun convention: list/get + business_partner, with plural for the collection and singular for the individual resource. The naming is clean, predictable, and consistent.

Tool Count3/5

Two tools is borderline for the server's stated scope. It is sufficient for a minimal business partner lookup server, but the generic 'sap-s4hana-odata-mcp' name suggests a broader OData surface, so the tool count feels thin at the low end.

Completeness3/5

The tool set covers basic read/query needs for business partners via list and get, but it lacks create/update/delete operations and exposes no other S/4HANA entities. Agents needing write capabilities or non-business-partner data will hit dead ends.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • SAP S/4HANA MCP Server

    Nidhideep
    F
    license
    A
    quality
    D
    maintenance
    Enables interaction with SAP S/4HANA systems via OData, allowing service discovery, metadata exploration, field value retrieval, and CRUD operations through natural language.
    4
    5
    -

  • sap-mcp-server

    Volshin
    F
    license
    Not graded
    quality
    C
    maintenance
    Enables natural language querying of SAP business partner data by exposing OData APIs as MCP tools for LLM agents.
    -

  • S/4HANA MCP Server

    ilia-inovaflow
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables interaction with SAP S/4HANA systems, providing 38 tools to search and manage business partners, products, pricing, purchase orders, supplier invoices, service entry sheets, journal entries, and cost centers via OData V2/V4 and SOAP.
    MIT