The SAP Documentation MCP Server provides unified access to official SAP documentation, real-time SAP Community content, and SAP Help Portal resources for comprehensive SAP development support.
Core Capabilities:
Search SAP Documentation (sap_docs_search): Query SAPUI5, CAP, OpenUI5 APIs, and wdi5 documentation for controls, technical concepts, and development topics
Search SAP Community (sap_community_search): Find high-quality blog posts and solutions with real-time access and automatic full content retrieval for top results
Search SAP Help Portal (sap_help_search): Access comprehensive SAP product documentation across S/4HANA, SAP BTP, Analytics Cloud, Fiori, and ABAP
Retrieve Specific Content (sap_docs_get, sap_help_get): Fetch detailed documentation, control APIs, or community posts using unique IDs with optional filtering
Content Coverage: Over 4,180+ documentation files including SAPUI5 (1,485+ files), CAP (195+ files), OpenUI5 APIs (500+ definitions), 2,000+ sample code examples, plus real-time community posts and full SAP Help Portal access.
Smart Features: Intelligent search with context-aware scoring, automatic code highlighting, quality filtering, and sample categorization.
Access Methods: Remote via public SSE endpoint or local via STDIO/HTTP server, compatible with popular MCP clients like Claude, VS Code, Cursor, Zed Editor, Windsurf, and others.
Provides offline access to SAP documentation and real-time SAP Community content, including SAPUI5, CAP, OpenUI5 APIs and samples, and wdi5 E2E test framework documentation. Enables searching across official documentation and community posts, retrieving specific resources, and accessing high-quality community solutions.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@SAP Documentation MCP Server search for SAPUI5 table component examples"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants (Claude, Cursor, ChatGPT, etc.) access to SAP documentation through a unified search and fetch interface. It combines a local full-text + semantic index over git-cloned SAP docs with optional live queries to SAP Help, SAP Community, and Software Heroes — all exposed as MCP tools.
Or add it to any MCP client that supports streamable HTTP:
{
"mcpServers": {
"sap-docs": {
"type": "http",
"url": "https://mcp-sap-docs.marianzeis.de/mcp"
}
}
}No API key or login required — the server is public and read-only.
Related MCP server: ABAP MCP Server
Ready to use — no setup required
Variant
URL
SAP Docs
http://mcp-sap-docs.marianzeis.de/mcpABAP
https://mcp-abap.marianzeis.de/mcp
mcp-sap-docs is the upstream repository for two MCP server variants that share one codebase and differ by configuration (MCP_VARIANT / .mcp-variant):
Variant | Scope | Extra tools |
| Broad SAP docs: UI5, CAP, Cloud SDK, ABAP, BTP, AI, Terraform | Discovery Center tools |
| ABAP-focused: ABAP keyword docs, RAP, cheat sheets, style guides |
|
Source | Description |
| Official ABAP Keyword Documentation — on-premise / full syntax |
| Official ABAP Keyword Documentation — ABAP Cloud / BTP (restricted syntax) |
| Practical ABAP/RAP code snippets and examples |
| Annotation-driven RAP + OData V4 + Fiori Elements feature showcase |
| openSAP "Building Apps with RAP" course samples |
| ABAP Cloud + RAP example projects |
| RAP reuse services examples (number ranges, mail, Adobe Forms, …) |
| SAP Clean ABAP Style Guide and best practices |
| DSAG ABAP Leitfaden (German) development guidelines |
| SAP BTP concepts, development, security, administration |
| SAP AI Core and SAP AI Launchpad documentation |
| SAPUI5 / OpenUI5 framework documentation |
| SAP Cloud Application Programming Model (CAP) documentation |
| SAP Cloud SDK documentation |
| SAP Terraform Provider for BTP — resources and data sources |
| SAP Architecture Center reference architectures and guidance |
| wdi5 (WebdriverIO + UI5) testing framework documentation |
Source | Description |
SAP Help Portal | Official SAP product documentation (broad scope) |
SAP Community | Community blogs, Q&A, and troubleshooting posts |
Software Heroes | ABAP/RAP articles and tutorials (EN + DE, deduplicated) |
Tool | Description |
| Unified hybrid search (BM25 + semantic) across offline docs and optional online sources. Supports |
| Retrieve full document content by ID returned from |
| Check ABAP feature availability across SAP releases (7.40–LATEST) using the Software Heroes feature matrix. |
| Dedicated SAP Community search via the Khoros LiQL API — returns full content of top posts. Use when |
| Search SAP released objects (classes, interfaces, tables, CDS views, …) by name/component/type from the official SAP/abap-atc-cr-cv-s4hc release state repo. Useful for clean core compliance discovery. |
| Full release state details for a specific SAP object including clean core level (A/B/C/D), successor objects, and optional compliance verdict. |
sap-docs variant onlyTool | Description |
| Search the SAP Discovery Center service catalog for BTP services by keyword, category, or license model. |
| Get comprehensive BTP service details: pricing plans, product roadmap, documentation links, and key features. Accepts a service UUID or name. |
| List all matching FEATURE / FIX / DEPRECATED changes and SAPUI5 What's New entries for a version or range from a local all-changes bundle ( |
abap variant onlyTool | Description |
| Run static code analysis on ABAP source code using abaplint. Auto-detects file type from code patterns. Returns findings with line numbers, severity, and rule keys. |
Upstream source of truth: mcp-sap-docs
One-way sync target: abap-mcp-server
Search uses Hybrid BM25 + Semantic (embedding) fusion via Reciprocal Rank Fusion (RRF)
Embeddings model: Xenova/all-MiniLM-L6-v2 (~90 MB, cached in dist/models/)
Resolution order:
MCP_VARIANT environment variable
.mcp-variant file in repo root
fallback: sap-docs
Examples:
# Run as full sap-docs profile
MCP_VARIANT=sap-docs npm run setup
MCP_VARIANT=sap-docs npm run build
MCP_VARIANT=sap-docs npm run start:streamable
# Run as ABAP profile
MCP_VARIANT=abap npm run setup
MCP_VARIANT=abap npm run build
MCP_VARIANT=abap npm run start:streamablesearch performs fused retrieval over:
Offline FTS index (local submodule content)
Optional online sources (includeOnline=true):
SAP Help
SAP Community
Software Heroes content search (EN/DE merge + dedupe)
Ranking and filtering highlights:
Hybrid BM25 + Semantic (embedding) search — keyword and meaning, fused via RRF
Reciprocal Rank Fusion (RRF) across offline and online sources
Source-level boosts from metadata
includeSamples can remove sample-heavy sources
abapFlavor (standard / cloud / auto) filters official ABAP docs libraries while keeping non-ABAP sources
sources can restrict offline libraries explicitly
The offline search combines BM25 (FTS5 keyword matching) with semantic similarity
(dense embeddings via Xenova/all-MiniLM-L6-v2). This allows natural-language and
paraphrase queries to find relevant docs even when the exact keywords are missing.
Example: "how to check if a user has permission" finds AUTHORITY-CHECK docs.
Embeddings are pre-computed at build time and stored in docs.sqlite.
The model (~90 MB) is cached in dist/models/ (gitignored, in-project).
See docs/HYBRID-SEARCH.md for full details, size impact, and tuning.
search includes online sources by default. To run offline-only, use:
local index/submodules only (npm run setup + npm run build)
includeOnline=false in each search request
Example search request body:
{
"query": "RAP draft",
"k": 8,
"includeOnline": false
}Run the container with host binding and call search with includeOnline=false:
docker run --rm -p 3122:3122 \
-e MCP_VARIANT=sap-docs \
-e MCP_PORT=3122 \
-e MCP_HOST=0.0.0.0 \
mcp-sap-docsFor strict air-gapped execution, disable container networking:
docker run --rm --network none -p 3122:3122 \
-e MCP_VARIANT=sap-docs \
-e MCP_PORT=3122 \
-e MCP_HOST=0.0.0.0 \
mcp-sap-docsNotes:
With --network none, online fetches are impossible by runtime isolation.
Startup may log warnings for online prefetch attempts (for example ABAP feature matrix); this does not prevent offline search usage.
npm ci
npm run setup
npm run buildStart server modes:
# MCP stdio
npm start
# HTTP status/dev server
npm run start:http
# MCP streamable HTTP
npm run start:streamableDefault ports by variant:
sap-docs: HTTP 3001, streamable 3122
abap: HTTP 3002, streamable 3124
Health checks:
curl -sS http://127.0.0.1:3122/health | jq .
curl -sS http://127.0.0.1:3001/status | jq .Use variant-specific ports when running abap profile.
Script names remain shared (setup, build, start, start:streamable).
Behavior changes by variant config:
setup.sh only initializes variant-allowed submodules
build-index only includes variant-allowed libraries
build-fts only indexes variant-allowed libraries
This keeps abap faster and smaller without maintaining a separate build script set.
Build image for a variant:
# sap-docs image
docker build --build-arg MCP_VARIANT=sap-docs -t mcp-sap-docs .
# abap image
docker build --build-arg MCP_VARIANT=abap -t abap-mcp-server .Run streamable server:
# sap-docs
docker run --rm -p 3122:3122 \
-e MCP_VARIANT=sap-docs \
-e MCP_PORT=3122 \
mcp-sap-docs
# abap
docker run --rm -p 3124:3124 \
-e MCP_VARIANT=abap \
-e MCP_PORT=3124 \
abap-mcp-serverFor BTP CF, the recommended sap-docs path is to deploy the maintained
ghcr.io/marianfoo/mcp-sap-docs:sap-docs image with MTA. Cloud Foundry only
pulls and runs the prepared semantic image.
See docs/BTP-CF-DEPLOYMENT.md for the public-first
deployment guide. Start with
Deployment Options and Tradeoffs
to choose between MTA, direct cf push, custom registry images, and refresh
setup.
abap-mcp-serverThis repository contains direct sync automation:
Workflow: .github/workflows/sync-to-abap-main.yml
Script: scripts/sync-to-abap.sh
Flow:
Push to mcp-sap-docs/main
Workflow clones abap-mcp-server
Tracked upstream files are synced (with exclude rules)
ABAP overlay is applied
.mcp-variant is forced to abap
ABAP package identity is patched
Commit is pushed to abap-mcp-server/main
Required secret in mcp-sap-docs repo:
ABAP_REPO_SYNC_TOKEN
Commit message controls:
[skip-sync] skips sync workflow
mcp-sap-docs: upstream implementation + sync trigger
abap-mcp-server: deployment trigger remains push-to-main in that repository
This preserves ABAP deployment automation while keeping one shared upstream codebase.
ecosystem.config.cjs is variant-aware and resolves:
process names
ports
deploy path
from config/variants/*.json.
npm run build:tsc
npm run test:url-generation
npm run test:integration
npm run test:software-heroes
npm run test:discovery-center # mocked Discovery Center REST contract tests
npm run test:discovery-center:live # opt-in live API smoke test
npm run test:sap-objects # SAP Released Objects unit tests
# Variant-specific build checks
MCP_VARIANT=sap-docs npm run build:index
MCP_VARIANT=abap npm run build:index
MCP_VARIANT=sap-docs npm run build:fts
MCP_VARIANT=abap npm run build:ftsdocs/ARCHITECTURE.md
docs/DEV.md
docs/TESTS.md
docs/UPSTREAM-ONE-WAY-SYNC-IMPLEMENTATION.md
REMOTE_SETUP.md
ABAP FEATURE MATRIX: abap_feature_matrix(query="feature keywords")
FUNCTION NAME: abap_feature_matrix
Search the Software Heroes ABAP Feature Matrix to check feature availability across SAP releases. The matrix shows which ABAP features are available in different SAP releases (7.40, 7.50, 7.52, 7.54, 7.55, 7.56, 7.57, 2020, 2021, 2022, 2023, LATEST).
DATA SOURCE: https://software-heroes.com/en/abap-feature-matrix Full matrix is fetched in English and cached for 24 hours. Filtering is done locally.
STATUS MARKERS: • ✅ available - Feature is available in the release • ❌ unavailable - Feature is not available • ⭕ deprecated - Feature is deprecated • ❔ needs_review - Status needs verification • 🔽 downport - Feature was backported from a newer release
PARAMETERS: • query (optional): Feature keywords to search for (e.g., "inline declaration", "CORRESPONDING", "mesh"). If empty, returns all features. • limit (optional): Maximum number of results. If not specified, returns all matching features.
RETURNS JSON with: • matches: Array of matching features with:
feature: Feature name
section: Category (e.g., "ABAP SQL", "ABAP Statements")
link: URL to more information (if available)
statusByRelease: Object mapping release versions to status
score: Relevance score • meta: Matrix metadata (totalFeatures, totalSections, sections) • sourceUrl: Attribution URL to Software Heroes • legend: Explanation of status markers
EXAMPLES: abap_feature_matrix(query="inline declaration") abap_feature_matrix(query="CORRESPONDING") abap_feature_matrix() - returns all features abap_feature_matrix(query="CDS", limit=10)
USE CASES: • Check if a feature is available in your target SAP release • Find when a specific ABAP feature was introduced • Compare feature availability across releases • Get full matrix and let LLM interpret/filter results
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results. If not specified, returns all matching features. | |
| query | No | Feature keywords to search for, in ENGLISH (matrix is English). If empty or not provided, returns all features. |
| Name | Required | Description |
|---|---|---|
| meta | Yes | |
| legend | Yes | |
| matches | Yes | |
| sourceUrl | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses the data source, caching behavior (24-hour cache), local filtering, and status markers. It also describes the return structure with JSON fields. No destructive or auth-related information is needed as it is a read-only query tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (FUNCTION NAME, DESCRIPTION, DATA SOURCE, STATUS MARKERS, PARAMETERS, RETURNS, EXAMPLES, USE CASES). It is somewhat verbose but every section adds value. The key purpose is front-loaded in the first line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 optional parameters, no required params, output schema present), the description is complete. It explains all possible behaviors, return fields, status meanings, and provides multiple usage examples. An agent can use this tool without ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (both query and limit are defined). The description adds significant value: it clarifies query expects English keywords, provides concrete examples (inline declaration, CORRESPONDING, CDS), shows how to use limit with an example, and demonstrates empty query behavior. This greatly aids correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it searches the ABAP Feature Matrix to check feature availability across SAP releases. It clearly distinguishes itself from sibling tools that search SAP community or discovery center, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'USE CASES' section lists four specific scenarios for when to use this tool (check feature availability, find introduction, compare releases, get full matrix). While it doesn't explicitly state when not to use or mention alternatives, the scenarios are clear and comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET FULL DOCUMENT CONTENT: fetch(id="result_id")
FUNCTION NAME: fetch
Retrieves the full content of a document from search results.
USAGE:
First use search() to find relevant documents
Use the 'id' from search results to fetch full content
Returns complete document text with metadata
PARAMETERS: • id (required): Document ID from search results. Use the exact ID returned by search.
RETURNS: • id: Document identifier • title: Document title • text: Full document content (markdown or code) • url: Link to online documentation (if available) • metadata: Source information and content details
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Document ID from search results. Use exact IDs returned by search. |
| Name | Required | Description |
|---|---|---|
| id | Yes | |
| url | Yes | |
| text | Yes | |
| title | Yes | |
| metadata | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It states returns full document text with metadata and lists return fields. Implies safe read operation, but could disclose potential costs or limits. Still, adequate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headers (usage, parameters, returns). Front-loaded with purpose. A bit verbose but every sentence adds value. Minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple 1-param tool with output schema. Description covers workflow, parameter usage, and return fields. Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with description and examples. Description adds crucial context: ID must come from search results and be exact. Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieves the full content of a document from search results.' The verb 'fetch' and resource 'full content of a document' are specific. Distinguishes from sibling 'search' by outlining the workflow: use search first, then fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage instructions provided: '1. First use search() to find relevant documents, 2. Use the 'id' from search results to fetch full content.' Also emphasizes using exact IDs. Clearly guides when to use and implies prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SEARCH SAP COMMUNITY: sap_community_search(query="search terms")
FUNCTION NAME: sap_community_search
Dedicated search across SAP Community blogs, Q&A posts, and discussions. Returns full content of the top matching posts.
IMPORTANT: The main search tool (with includeOnline=true) already includes SAP Community results alongside offline docs, SAP Help, and Software Heroes. Use this dedicated tool only when:
• The main search tool returned no useful results for your question
• You are looking for specific error messages, runtime exceptions, or obscure symptoms
• You need practical workarounds, troubleshooting steps, or real-world implementation experiences not covered in official documentation
• You want to see full community post content (not just snippets)
This tool searches SAP Community via the Khoros LiQL API and automatically retrieves full content for the top 3 posts.
PARAMETERS: • query (required): Search terms. Use specific error messages, symptoms, or technical terms for best results. • k (optional, default=30): Number of results to return. • minKudos (optional, default=1): Minimum number of kudos (likes) a post must have.
Default 1 filters out zero-engagement posts, giving higher-quality results.
Set to 0 for the broadest possible search (includes all posts, even those with no engagement — useful when looking for very niche or recent topics).
Set higher (e.g. 5 or 10) to surface only well-received, community-validated content.
Suggested maximum: 10. Higher values may return very few or no results.
RETURNS (JSON with): • results: Array of community posts, each containing:
id: Post identifier (use with fetch to retrieve full content later)
title: Post title
url: Direct link to the SAP Community post
snippet: Text excerpt
metadata.author: Post author
metadata.likes: Number of kudos
metadata.tags: Topic tags
WORKFLOW:
Start with search(query="your question") (includes community + other sources)
If results are insufficient, use sap_community_search(query="specific error or symptom")
Use fetch(id="community-...") to retrieve full content of any community post from either tool
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of results to return. Default: 30. | |
| query | Yes | Search terms for SAP Community, in ENGLISH (corpus is primarily English). Be specific - use error messages, symptoms, or technical terms. | |
| minKudos | No | Minimum kudos (likes) a post must have. Default 1 (filters zero-engagement posts). Set 0 for broadest search (niche/recent topics). Set higher (5-10) for well-received, community-validated content only. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully compensates by disclosing the underlying API (Khoros LiQL), automatic full content retrieval for top 3 posts, and detailed parameter behavior (minKudos defaults and effects). It covers all relevant behavioral aspects for a search tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear headings (IMPORTANT, PARAMETERS, RETURNS, WORKFLOW) and front-loaded with the core purpose. Every sentence adds value, and there is no redundancy. It is concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is very complete, including return format details and workflow. However, there is slight ambiguity: the description says it returns results from top 3 posts but also has a k parameter for number of results. Clarifying the relationship between k and the top 3 limit would improve completeness. Still, it is fully functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds significant value by explaining the semantic meaning of minKudos values, recommending specific query types like error messages, and clarifying defaults. This goes well beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches SAP Community blogs, Q&A, and discussions, returning full content of top matching posts. It distinguishes from the sibling tool 'search' which already includes community results, making the purpose specific and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: use the main search first, then this tool if results are insufficient or for specific scenarios like error messages. It also gives a clear workflow with steps, and explains alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SEARCH SAP BTP SERVICES: sap_discovery_center_search(query="SAP Build")
FUNCTION NAME: sap_discovery_center_search
Search the SAP Discovery Center service catalog to find SAP Business Technology Platform (BTP) services, solutions, and capabilities.
Use this tool when you need to:
Find which SAP BTP services are available for a specific use case (e.g., integration, AI, database, extension development)
Discover services by name or keyword (e.g., "HANA", "Integration Suite", "Build", "AI Core")
Browse services filtered by license model (free tier, pay-as-you-go, subscription)
Find deprecated BTP services and their replacements
Explore SAP AI and machine learning services on BTP
Compare BTP services within a category
Do NOT use this for ABAP documentation, code examples, or SAP Help content – use the 'search' tool for those. After finding a service, use sap_discovery_center_service(serviceId="...") to get full details including pricing, roadmap, and documentation links.
PARAMETERS: • query (required): Search terms for BTP services. Use service names or capability keywords. • top (optional, default 10, max 25): Number of results to return. • category (optional): Filter by category, e.g., "AI", "Integration", "Data and Analytics", "Application Development and Automation", "Foundation / Cross Services". • license_model (optional): Filter by license type: "free", "payg", "subscription", "btpea", "cloudcredits".
RETURNS (JSON): • services[]: Array of matching services with id, name, shortName, description, category, additionalCategories, licenseModelType, provider, tags, ribbon, isDeprecated • total: Number of results returned
| Name | Required | Description | Default |
|---|---|---|---|
| top | No | Number of results (default 10, max 25). | |
| query | Yes | Search terms for BTP services, in ENGLISH. | |
| category | No | Category filter (e.g., 'AI', 'Integration', 'Data and Analytics'). | |
| license_model | No | License model filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, description carries the burden. It clearly explains the search behavior, filtering options, and output. However, it does not disclose any rate limits or potential side effects, but as a search tool, it is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bold summary, function call example, use case list, exclusions, parameter details, and output explanation. Every sentence is valuable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with 4 parameters and no output schema, the description covers purpose, usage, parameters, and return format comprehensively. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds value by providing examples for query, explaining default/max for top, listing categories, and enum for license_model. It also describes the output format, which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search the SAP Discovery Center service catalog to find SAP BTP services', specifies verbs like 'find', 'discover', 'browse', and lists concrete use cases. It distinguishes itself from siblings like sap_discovery_center_service and search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit when-to-use (e.g., 'Find which SAP BTP services are available for a specific use case') and when-not-to-use ('Do NOT use this for ABAP documentation... use the 'search' tool for those'). Also provides follow-up action: 'After finding a service, use sap_discovery_center_service to get full details.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET SAP BTP SERVICE DETAILS: sap_discovery_center_service(serviceId="abc-123-def")
FUNCTION NAME: sap_discovery_center_service
Get comprehensive details for a specific SAP BTP service from the SAP Discovery Center, including pricing plans with per-unit costs, product roadmap, documentation links, and key features.
Use this tool when you need to:
Get pricing information for a BTP service (plans, metrics, costs per unit, free tier availability)
View the product roadmap and upcoming features planned for a service
Find official documentation, tutorials, and community resources for a service
Understand service plans and their differences (free tier vs. standard vs. extended)
Get the SAP cost calculator link or SAP Store link for a service
Learn about key features and capabilities of a specific service (headlines)
Check what billing metrics a service uses (e.g., Capacity Units, API Calls)
You can pass either a UUID from search results OR the service name directly (e.g., "SAP Build Code", "SAP AI Core", "SAP HANA Cloud"). The tool will auto-resolve names to UUIDs.
PARAMETERS: • serviceId (required): Service UUID from search results OR the service name (e.g., "SAP Build Code"). Names are auto-resolved via search. • currency (optional, default "USD"): Pricing currency code (e.g., "EUR", "USD", "GBP"). • include_roadmap (optional, default true): Include product roadmap data with planned features by quarter. • include_pricing (optional, default true): Include pricing plans with per-unit costs and billing metrics.
RETURNS (JSON): • Core: name, description, category, productType, licenseModelType, tags, csnComponent • links: calculator, sapStore, featureDescription, discoveryCenter URLs • headlines[]: Key feature highlights with descriptions • resources: Documentation links grouped by type (documentation, tutorials, community, support, calculator) • metrics[]: Billing metric definitions (name, description, code) • pricing[]: Service plans with planName, planCode, description, usageType, features, and commercialModels (model, metric, chargingPeriod, pricePerUnit, blockSize). The pricing section contains actual per-unit prices from the SAP Discovery Center (e.g., "1.04 EUR" per Capacity Unit/month). • roadmap: Planned features organized by quarter with categories and deliverables (or null if no roadmap exists)
| Name | Required | Description | Default |
|---|---|---|---|
| currency | No | Pricing currency code (default 'USD'). | |
| serviceId | Yes | Service UUID from search results OR service name (e.g., 'SAP Build Code'). Names are auto-resolved. | |
| include_pricing | No | Include pricing plans (default true). | |
| include_roadmap | No | Include product roadmap (default true). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses auto-resolution of serviceId, default parameter values, and detailed return structure. Does not mention error handling or rate limits, but overall transparent for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with a concise function signature, then organized into use-case bullets and detailed sections. Slightly verbose in the return structure but well-structured and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description provides a comprehensive return structure (JSON fields). Covers use cases, parameter details, auto-resolution, and defaults. Complete for a moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds valuable semantics: auto-resolution for serviceId, default currency 'USD', and defaults for boolean flags. All parameters are explained beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'GET SAP BTP SERVICE DETAILS' and lists specific data returned (pricing, roadmap, documentation). This clearly distinguishes it from sibling tools like sap_discovery_center_search (search) and sap_get_object_details (general details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a bulleted list of when to use, covering pricing, roadmap, docs, service plans, etc. It does not explicitly state when not to use, but it implies context (e.g., needing a service name or UUID). Lacks explicit alternatives but clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GET SAP OBJECT DETAILS: sap_get_object_details(object_type="CLAS", object_name="CL_ABAP_REGEX")
Get complete release state details for a specific SAP object by its TADIR type and name.
Use this tool when you: • Know a specific SAP object name and need to verify if it is released/deprecated/internal • Want to check Clean Core compliance: is this object allowed in BTP ABAP or S/4HANA Cloud? • Need to find the recommended successor object when a deprecated SAP API should be replaced • Want the full context of an object: software component, application component, Clean Core level (A/B/C/D), and release state • Are checking whether a specific table (MARA, VBAK), class (CL_*), interface (IF_*), or CDS view is safe to use in a clean core / cloud-ready ABAP development scenario
Clean Core levels: A=Released API (safe for cloud/BTP), B=Classic API (on-premise only), C=Internal/Stable (not for customer use), D=No API
Optionally pass target_clean_core_level to receive an explicit compliance verdict for that object.
PARAMETERS: • object_type (required): TADIR type, e.g. "CLAS", "TABL", "INTF", "DDLS", "FUGR" • object_name (required): Exact object name, e.g. "CL_ABAP_REGEX", "EKKO", "IF_OS_TRANSACTION" • system_type (optional, default: "public_cloud"): "public_cloud" | "btp" | "private_cloud" | "on_premise" • target_clean_core_level (optional): "A" or "B" — receive a compliance verdict against this target
RETURNS (JSON with): • found: boolean • objectType, objectName, state, cleanCoreLevel, cleanCoreLevelLabel • applicationComponent, softwareComponent • successor: successor classification and recommended replacement objects • successorObjects: full details of successor objects (if available in the dataset) • complianceStatus (if target_clean_core_level given): "compliant" | "non_compliant"
| Name | Required | Description | Default |
|---|---|---|---|
| object_name | Yes | Exact object name, e.g. CL_ABAP_REGEX, EKKO, IF_OS_TRANSACTION. | |
| object_type | Yes | TADIR object type, e.g. CLAS, TABL, INTF, DDLS, FUGR, BDEF. | |
| system_type | No | Target SAP system type. Default: public_cloud. | public_cloud |
| target_clean_core_level | No | Optional compliance target level. Returns complianceStatus: compliant or non_compliant. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the tool's behavior well (retrieves details, returns JSON with various fields), but it does not explicitly state that it is a read-only operation, nor does it mention any potential side effects, authentication requirements, or rate limits. The 'GET' in the title implies read-only, but it could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bold title line, a bulleted list of use cases, a parameter list, and a return structure. It is front-loaded with the main purpose. While it is somewhat lengthy, each section provides useful information, and the organization aids comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description compensates by explaining the return structure (including fields like 'found', 'state', 'cleanCoreLevel', 'successor', etc.) and the clean core levels. It also provides examples of API calls. However, it does not mention error handling or authentication, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers all 4 parameters with descriptions, giving 100% schema coverage. The description adds extra context by providing examples (e.g., 'CL_ABAP_REGEX', 'EKKO') and explaining the clean core levels for the optional parameter. This adds some value beyond the schema but is not essential since the schema is already clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves complete release state details for a specific SAP object, with a specific verb ('GET') and resource ('object details'). It distinguishes itself from siblings by providing specific use cases and examples, such as checking Clean Core compliance and finding successors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a bulleted list of specific scenarios when to use the tool (e.g., verifying if an object is released, checking Clean Core compliance, finding successors). However, it does not explicitly mention when not to use it or provide direct comparisons with sibling tools, though the use cases imply when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SEARCH SAP RELEASED OBJECTS: sap_search_objects(query="CL_ABAP_REGEX")
Search SAP released objects from the official SAP API Release State repository (SAP/abap-atc-cr-cv-s4hc).
Use this tool when you need to: • Find which SAP objects (classes, interfaces, tables, CDS views, function groups, BAdIs, etc.) are available and released for a given topic or application area • Discover released APIs in a specific application component (e.g., MM-PUR, FI-GL, SD-SLS) • Browse what objects exist in a system type (S/4HANA Cloud Public, BTP ABAP, Private Cloud) • Filter by Clean Core compliance level: A=Released APIs only, B=includes Classic APIs, C=includes internal/stable, D=all objects • Find alternative released objects when looking for functionality in a specific domain
Do NOT use this for documentation content, code examples, or general SAP help — use the search tool for those. Use this specifically for API release status and clean core compliance discovery.
PARAMETERS: • query (optional): Object name or keyword to search (e.g. "CL_ABAP_REGEX", "purchase order", "MM") • system_type (optional, default: "public_cloud"): "public_cloud" | "btp" | "private_cloud" | "on_premise" • clean_core_level (optional, default: "A"): "A" | "B" | "C" | "D" — cumulative: B includes A+B, C includes A+B+C • object_type (optional): TADIR type filter, e.g. "CLAS", "INTF", "TABL", "DDLS" • app_component (optional): Application component prefix, e.g. "MM-PUR", "FI-GL" • state (optional): "released" | "deprecated" | "classicAPI" | "stable" | "notToBeReleased" | "noAPI" • limit (optional, default: 25, max: 100): Number of results per page • offset (optional, default: 0): Pagination offset
RETURNS (JSON with): • objects: Array of SAP objects with objectType, objectName, state, cleanCoreLevel, applicationComponent, softwareComponent • total: Total matching count • hasMore: Whether more results exist • nextOffset: Offset to use for next page
[PRE-LOADED CONTEXT] Context loading — data will be available on first use.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Results per page. Default: 25. Max: 100. | |
| query | No | Object name or topic keyword to search, in ENGLISH. | |
| state | No | Filter by release state. | |
| offset | No | Pagination offset. Default: 0. | |
| object_type | No | TADIR object type filter, e.g. CLAS, INTF, TABL, DDLS, FUGR, BDEF, SRVD. | |
| system_type | No | Target SAP system type. Default: public_cloud. | public_cloud |
| app_component | No | Application component prefix, e.g. MM-PUR, FI-GL, SD-SLS. | |
| clean_core_level | No | Maximum Clean Core level to include. A=Released only, B=+Classic, C=+Internal, D=all. Default: A. | A |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, but description covers the behavior well: searches an official repository, filters by Clean Core level and system type. Could explicitly state read-only nature for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with bullet points and a clear example; front-loads the main purpose. Slightly verbose but justified by complexity of the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description details return structure (objects, total, hasMore, nextOffset). All 8 optional parameters are explained with sensible defaults and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds value with examples like 'query="CL_ABAP_REGEX"' and clarifies filter semantics (e.g., cumulative Clean Core levels). Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search SAP released objects' and provides concrete examples and use cases. It distinguishes from siblings like 'sap_get_object_details' and the general 'search' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit 'Use this when' and 'Do NOT use this for' sections with named alternatives (e.g., 'search' tool for documentation). Clearly guides when to choose this tool over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SEARCH ABAP/RAP DOCUMENTATION: search(query="search terms")
FUNCTION NAME: search
Unified search for ABAP + RAP development documentation. It searches across curated OFFLINE sources (fast, deterministic) and can also include ONLINE sources (best-effort, 10s timeout per source) when enabled.
Use this to discover the best document IDs, then call fetch(id=...) to retrieve full content.
LANGUAGE: Query in ENGLISH — the corpus and ranking are primarily English; non-English queries return weaker results.
SOURCES OVERVIEW
OFFLINE sources (local FTS index; always searched unless filtered via sources):
Reference & guidance (not sample-heavy):
• abap-docs-standard (offline): Official ABAP Keyword Documentation for on‑premise systems (full syntax). Best for statement syntax + semantics.
• abap-docs-cloud (offline): Official ABAP Keyword Documentation for ABAP Cloud/BTP (restricted syntax). Best for Steampunk/BTP constraints.
• sap-styleguides (offline): SAP Clean ABAP Style Guide + best practices (includes translations; non‑English duplicates are filtered).
• dsag-abap-leitfaden (offline): DSAG ABAP Leitfaden (German) with ABAP development guidelines and best practices.
• btp-cloud-platform (offline): SAP Business Technology Platform documentation - concepts, getting started, development, extensions, administration, security.
• sap-artificial-intelligence (offline): SAP AI Core and SAP AI Launchpad documentation.
Sample-heavy OFFLINE sources (controlled by includeSamples; great for implementation, can dominate broad queries):
• abap-cheat-sheets (offline, samples): Many practical ABAP/RAP snippets; quick “how-to” reference.
• abap-fiori-showcase (offline, samples): Annotation-driven RAP + OData V4 + Fiori Elements feature showcase.
• abap-platform-rap-opensap (offline, samples): openSAP “Building Apps with RAP” course samples (ABAP/CDS).
• cloud-abap-rap (offline, samples): ABAP Cloud + RAP example projects (ABAP/CDS).
• abap-platform-reuse-services (offline, samples): RAP reuse services examples (number ranges, change documents, mail, Adobe Forms, ...).
OPTIONAL ONLINE SOURCES (when includeOnline=true): • sap-help (online): SAP Help Portal product documentation (official, broad scope). • sap-community (online): SAP Community blogs + Q&A + troubleshooting (practical, quality varies). • software-heroes (online): Software Heroes ABAP/RAP articles & tutorials (searched in EN+DE, deduplicated by URL; feed search is disabled).
NOTE ABOUT abapFlavor:
• OFFLINE: filters the official ABAP Keyword Documentation libraries (abap-docs-standard vs abap-docs-cloud); other offline sources are kept.
• ONLINE: when set EXPLICITLY to "standard"/"cloud", it ALSO scopes the SAP Help leg to the matching ABAP product (standard → ABAP Platform docs; cloud → ABAP environment docs), removing cross-product noise on conceptual ABAP queries. "auto" leaves SAP Help unscoped.
• IMPORTANT — "standard"/"cloud" is a QUERY-DOMAIN signal ("this is an ABAP-LANGUAGE question"), NOT a system flag. Forcing it on a non-ABAP-language query scopes SAP Help to ABAP-language docs and buries the relevant content. Route by DOMAIN:
ABAP language/RAP/CDS → "standard" or "cloud".
FUNCTIONAL / configuration (Asset Accounting, Controlling, EWM ) → leave abapFlavor "auto" and pass the product param (e.g. "SAP_S4HANA_ON-PREMISE").
CAP / UI5 / Fiori → leave "auto". The OFFLINE corpus is the authoritative source for these; note the online SAP Help leg is NOT scoped for them (no abapFlavor/product fit yet), so it may still contribute some off-topic or low-value SAP Help hits.
PARAMETERS: • query (required): Search terms. Be specific and use technical ABAP/RAP terminology. • k (optional, default=50): Number of results to return. • includeOnline (optional, default=true): Keep this ON for best answers. Only set to false if online search is blocked/slow/unreliable in your environment OR you explicitly want OFFLINE-only sources. • includeSamples (optional, default=true): Includes sample-heavy offline sources (repos, showcases, cheat sheets). If results are flooded by examples and you want more conceptual/reference docs, set to false. Turn it on when you want implementation/code. • abapFlavor (optional, default="auto"): Filter by ABAP flavor:
"standard": Only Standard ABAP (on-premise, full syntax)
"cloud": Only ABAP Cloud (BTP, restricted syntax)
"auto": Detect from query (add "cloud" or "btp" for cloud, otherwise standard) • sources (optional): Restrict OFFLINE search to specific source IDs (does not disable online sources; use includeOnline for that). Example: ["abap-docs-standard", "sap-styleguides"]
RETURNS (JSON array of results, each containing): • id: Document identifier (use with fetch to get full content) • title: Document title • url: Link to documentation • snippet: Text excerpt from document • score: Relevance score (RRF-fused from multiple sources) • library_id: Source library identifier • metadata.source: Source ID (abap-docs-standard, sap-help, etc.) • metadata.sourceKind: "offline" | "sap_help" | "sap_community" | "software_heroes"
TYPICAL WORKFLOW:
search(query="your ABAP/RAP question")
fetch(id="result_id_from_step_1") to get full content
QUERY TIPS: • Be specific: "RAP behavior definition" not just "RAP" • Include ABAP keywords: "SELECT FOR ALL ENTRIES", "LOOP AT GROUP BY" • For ABAP Cloud: Add "cloud" or "btp" to query, or set abapFlavor="cloud" • For OFFLINE-only: Set includeOnline=false (use this mainly when online search does not work for you) • If results are too code-heavy: Set includeSamples=false • For implementation examples: Keep includeSamples=true
ESCALATION: If search returns no useful results (especially for specific error messages, niche runtime issues, or workaround patterns), try the dedicated sap_community_search tool which searches SAP Community blogs and Q&A directly and returns full post content for the top matches.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | Number of results to return. Default: 50. | |
| query | Yes | Search terms for ABAP/RAP documentation, in ENGLISH (corpus is primarily English). Be specific and use technical terms. | |
| product | No | Optional SAP Help product-id scope, applied ONLY to the online SAP Help leg (offline unaffected). Routes the online query to ONE product's docs — use it for FUNCTIONAL/configuration questions that `abapFlavor` cannot express (e.g. 'SAP_S4HANA_ON-PREMISE' for Asset Accounting, Grants, sales customizing). Takes precedence over the abapFlavor auto-mapping. DISCOVER valid values exactly like `version`: run the search once WITHOUT product and copy a result's `metadata.productId` EXACTLY — that is the scope facet, NOT `metadata.product`, which is the human display label (e.g. 'SAP S/4HANA') and will NOT filter. Never invent a slug (e.g. 'ABAP_PLATFORM' is wrong; the real facet is 'ABAP_PLATFORM_NEW'). An unknown product safely falls back to unscoped, so nothing is lost. | |
| sources | No | Optional: specific source IDs to search. If not provided, searches all ABAP sources. | |
| version | No | Optional SAP release filter, applied ONLY to online SAP Help (help.sap.com) — offline docs are unaffected. Omit it for the latest content (the right default for most queries). To pin an older release, copy a result's `versionId` value EXACTLY and pass it back here — it is case-sensitive and its format varies by product (e.g. '2025.001', '2.0.08', '10.0', '2211', 'Cloud', '2026_06'). Discover valid values in one step: run the same search WITHOUT version first; every result shows its `versionId`. Never invent, reformat, or guess the token (a bare year like '2025' is usually a different release). If a version matches nothing, the latest results are returned instead, so no results are lost. | |
| abapFlavor | No | Filter by ABAP flavor: 'standard' (on-premise), 'cloud' (BTP), or 'auto' (detect from query). Default: auto. Offline: picks the abap-docs library. Online: an EXPLICIT 'standard'/'cloud' also scopes the SAP Help leg to the matching ABAP product, removing cross-product noise. QUERY-DOMAIN signal ('this is an ABAP-language question'), NOT a system flag. Route by domain: ABAP language → 'standard'/'cloud'; FUNCTIONAL/config → 'auto' + the `product` param (e.g. SAP_S4HANA_ON-PREMISE); CAP/UI5/Fiori → 'auto' (offline corpus is authoritative; the online leg stays unscoped for these). Forcing 'standard' on a non-ABAP query buries the relevant docs. | auto |
| includeOnline | No | Include online sources (SAP Help, SAP Community, Software Heroes). Default: true. Only turn off if online search is blocked/slow/unreliable or you explicitly want offline-only sources. | |
| includeSamples | No | Include sample-heavy offline sources (cheat sheets, showcases, example repos). Default: true. Turn off if you want fewer code examples and more reference/guidance docs. |
| Name | Required | Description |
|---|---|---|
| results | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully discloses behavior: it searches offline (fast, deterministic) and online (best-effort, 10s timeout per source), the language sensitivity (English preferred), how `abapFlavor` affects offline/online legs, and how `version`/`product` parameters only apply to online SAP Help. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured with sections, bullet points, and clear formatting. Every sentence earns its place by providing critical guidance. It is front-loaded with the function signature and overall purpose, and the structure makes it easy to navigate. For a complex tool with 8 parameters and many sources, this level of detail is appropriate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, multiple source types, output schema), the description covers all aspects: purpose, parameters with detailed usage, return format, workflow, query tips, escalation, and relationship to siblings. The output schema is documented, and the description explains how to interpret results (e.g., use `id` with `fetch`). Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial context beyond the schema: for `abapFlavor`, it explains offline/online behavior and routing advice; for `sources`, it lists and characterizes each source; for `includeOnline`/`includeSamples`, it gives conditions to disable; for `version` and `product`, it explains how to discover valid values. This significantly aids agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a unified search for ABAP/RAP development documentation, searching offline and online sources. It distinguishes its purpose from siblings like `fetch` (for retrieving content) and `sap_community_search` (escalation for niche queries). The verb 'search' is specific and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use this tool versus alternatives, including when to turn off `includeOnline`, how to set `abapFlavor` based on query domain, and when to use `sap_community_search` for escalation. Also gives query tips and a typical workflow. This is comprehensive and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
UI5 VERSION DIFF: ui5_version_diff(library="SAPUI5", from_version="1.108.0", to_version="1.130.0")
FUNCTION NAME: ui5_version_diff
List the new features, fixes, deprecations, and SAPUI5 What's New entries that landed between two UI5 releases, or inspect one exact release. Use this when planning or executing an upgrade so you know which workarounds can be dropped, which APIs are now deprecated, and which fixes might replace local patches.
DATA SOURCE: local all-changes bundle at UI5_LIB_DIFF_BUNDLE_PATH (default: dist/data/ui5-lib-diff/all-changes.json). The runtime tool is local-only and does not fetch hosted URLs. Refresh the bundle during setup with npm run download:ui5-lib-diff. If a requested release is newer than the local bundle, the response includes meta.notes and meta.generatedAt so the caller can tell setup data is stale.
RANGE SEMANTICS: returns changes that landed AFTER from_version up to and including to_version (i.e. what you gain by upgrading from from_version to to_version). If a requested patch version is unavailable, the tool uses the nearest lower available version with the same major.minor, matching the web app. For one release, pass version instead of a range.
PARAMETERS: • library (optional, default "SAPUI5"): "SAPUI5" or "OpenUI5". • version (optional): exact release to inspect, e.g. "1.130.0". Can also be supplied as the only from_version or only to_version. • from_version + to_version (optional range pair): version you are upgrading FROM/TO, e.g. "1.108.0" -> "1.130.0". • types (optional): subset of ["FEATURE", "FIX", "DEPRECATED"]. Defaults to all three. • ui5_library (optional): case-insensitive substring filter on the UI5 library, e.g. "sap.m", "sap.ui.core", "sap.fe". • query (optional): case-insensitive substring filter on change text and What's New title/description, e.g. "Table", "ObjectStatus", "ManagedObject".
RETURNS JSON with: • mode, library, from_version, to_version, version? • versionsInRange: versions covered by the range (newest first) • counts: { FEATURE, FIX, DEPRECATED } totals across the full range • totalEntries: sum of counts • entries: [{ version, date, library, type, text, commit_url? }] • whatsNewEntries, whatsNewTotalEntries: SAPUI5 What's New entries for the same version/range • meta: { availableVersions, minVersion, maxVersion, generatedAt, sourceDataPath, cacheSource, requested, resolved, notes? } — "notes" is a list of soft signals (version resolution, stale-bundle hints, out-of-range hints, coercion warnings) • sourceUrl: browser URL for human inspection of the same range
USE CASES: • Upgrade planning: "What deprecations should I clean up before moving 1.108 -> 1.130?" • Workaround cleanup: filter by query="" to find the fix that replaces a local patch • Library-scoped review: ui5_library="sap.m" to focus on a single library • Combine with @ui5/mcp-server tools (run_ui5_linter, run_manifest_validation, get_api_reference) for code-level follow-up
EXAMPLES: ui5_version_diff(from_version="1.108.0", to_version="1.130.0", types=["DEPRECATED"]) ui5_version_diff(version="1.130.0", ui5_library="sap.m") ui5_version_diff(library="OpenUI5", from_version="1.120.0", to_version="1.130.0", ui5_library="sap.m") ui5_version_diff(from_version="1.96.0", to_version="1.120.0", query="ObjectStatus")
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Case-insensitive substring filter on change text and What's New title/description. | |
| types | No | Filter to a subset of change types. Defaults to all three. | |
| library | No | Which UI5 flavour to diff. Defaults to SAPUI5. | SAPUI5 |
| version | No | Single UI5 release to inspect, e.g. "1.130.0". If unavailable, resolves to the nearest lower available patch with the same major.minor. | |
| to_version | No | Version you are upgrading to (inclusive bound), e.g. "1.130.0". If unavailable, resolves to the nearest lower available patch with the same major.minor. | |
| ui5_library | No | Case-insensitive substring filter on UI5 library name (e.g. "sap.m", "sap.ui.core"). | |
| from_version | No | Version you are upgrading from (exclusive bound), e.g. "1.108.0". If unavailable, resolves to the nearest lower available patch with the same major.minor. |
| Name | Required | Description |
|---|---|---|
| meta | No | |
| mode | Yes | |
| counts | Yes | |
| entries | Yes | |
| library | Yes | |
| version | No | |
| sourceUrl | Yes | |
| to_version | Yes | |
| from_version | Yes | |
| totalEntries | Yes | |
| versionsInRange | Yes | |
| whatsNewEntries | Yes | |
| whatsNewTotalEntries | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It clearly discloses the data source (local all-changes bundle), runtime behavior (local-only, no hosted URLs), version resolution logic (nearest lower available patch), and signals like meta.notes for stale data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, front-loaded purpose, and clear examples. However, it is quite verbose; some information could be condensed without losing clarity. Still, the structure aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, no required, output schema exists), the description is highly complete. It covers data source, version resolution, return structure, and use cases. The presence of output schema does not reduce the need because description still adds context on meta fields and version resolution.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but the description significantly adds value: it explains range semantics (exclusive from, inclusive to), details each parameter's role, provides examples, and clarifies edge cases like single version usage. This goes well beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool lists new features, fixes, deprecations, and What's New entries between two UI5 releases or for one release. It also specifies the use case of upgrade planning. This makes the purpose distinct from sibling tools which cover ABAP, community search, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for upgrade planning and gives concrete use cases (upgrade planning, workaround cleanup, library-scoped review). It also mentions combining with other @ui5/mcp-server tools. However, it does not explicitly contrast with alternative tools or state when not to use it, so it's slightly below perfect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.3.50abap_feature_matrixfetch3 fields changedInput schema / properties / id / descriptionPrevious value: -"Unique document ID from search results. Use exact IDs returned by search."New value: +"Document ID from search results. Use exact IDs returned by search."Input schema / properties / id / examplesPrevious value: -[
- "/cap/guides/domain-modeling",
- "/sapui5/controls/button-properties",
- "/openui5-api/sap/m/Button",
- "/abap-docs-758/inline-declarations",
- "community-12345"
-]New value: +[
+ "/abap-docs-standard/abapselect",
+ "/abap-docs-cloud/abaploop",
+ "/abap-cheat-sheets/rap",
+ "/sap-styleguides/clean-abap"
+]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "metadata": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "text": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "text",
+ "url"
+ ],
+ "type": "object"
+}sap_community_search5 fields changedInput schema / properties / kAdded value: +{
+ "default": 30,
+ "description": "Number of results to return. Default: 30.",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "number"
+}Input schema / properties / minKudosAdded value: +{
+ "default": 1,
+ "description": "Minimum kudos (likes) a post must have. Default 1 (filters zero-engagement posts). Set 0 for broadest search (niche/recent topics). Set higher (5-10) for well-received, community-validated content only.",
+ "maximum": 100,
+ "minimum": 0,
+ "type": "number"
+}Input schema / properties / query / descriptionPrevious value: -"Search terms for SAP Community. Include error codes and specific technical details."New value: +"Search terms for SAP Community, in ENGLISH (corpus is primarily English). Be specific - use error messages, symptoms, or technical terms."Input schema / properties / query / examplesRemoved value: -[
- "CAP action parameter binary file upload 415 error",
- "wizard implementation best practices",
- "fiori elements authentication",
- "UI5 deployment issues",
- "wdi5 test automation problems"
-]Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "metadata": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "score": {
+ "type": "number"
+ },
+ "snippet": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}sap_discovery_center_searchsap_discovery_center_servicesap_get_object_detailssap_help_getsap_help_searchsap_search_objectssearch10 fields changedInput schema / properties / abapFlavorAdded value: +{
+ "default": "auto",
+ "description": "Filter by ABAP flavor: 'standard' (on-premise), 'cloud' (BTP), or 'auto' (detect from query). Default: auto. Offline: picks the abap-docs library. Online: an EXPLICIT 'standard'/'cloud' also scopes the SAP Help leg to the matching ABAP product, removing cross-product noise. QUERY-DOMAIN signal ('this is an ABAP-language question'), NOT a system flag. Route by domain: ABAP language → 'standard'/'cloud'; FUNCTIONAL/config → 'auto' + the `product` param (e.g. SAP_S4HANA_ON-PREMISE); CAP/UI5/Fiori → 'auto' (offline corpus is authoritative; the online leg stays unscoped for these). Forcing 'standard' on a non-ABAP query buries the relevant docs.",
+ "enum": [
+ "standard",
+ "cloud",
+ "auto"
+ ],
+ "type": "string"
+}Input schema / properties / includeOnlineAdded value: +{
+ "default": true,
+ "description": "Include online sources (SAP Help, SAP Community, Software Heroes). Default: true. Only turn off if online search is blocked/slow/unreliable or you explicitly want offline-only sources.",
+ "type": "boolean"
+}Input schema / properties / includeSamplesAdded value: +{
+ "default": true,
+ "description": "Include sample-heavy offline sources (cheat sheets, showcases, example repos). Default: true. Turn off if you want fewer code examples and more reference/guidance docs.",
+ "type": "boolean"
+}Input schema / properties / kAdded value: +{
+ "default": 50,
+ "description": "Number of results to return. Default: 50.",
+ "maximum": 100,
+ "minimum": 1,
+ "type": "number"
+}Input schema / properties / productAdded value: +{
+ "description": "Optional SAP Help product-id scope, applied ONLY to the online SAP Help leg (offline unaffected). Routes the online query to ONE product's docs — use it for FUNCTIONAL/configuration questions that `abapFlavor` cannot express (e.g. 'SAP_S4HANA_ON-PREMISE' for Asset Accounting, Grants, sales customizing). Takes precedence over the abapFlavor auto-mapping. DISCOVER valid values exactly like `version`: run the search once WITHOUT product and copy a result's `metadata.productId` EXACTLY — that is the scope facet, NOT `metadata.product`, which is the human display label (e.g. 'SAP S/4HANA') and will NOT filter. Never invent a slug (e.g. 'ABAP_PLATFORM' is wrong; the real facet is 'ABAP_PLATFORM_NEW'). An unknown product safely falls back to unscoped, so nothing is lost.",
+ "type": "string"
+}Input schema / properties / query / descriptionPrevious value: -"Search terms using natural language. Be specific and include technical terms."New value: +"Search terms for ABAP/RAP documentation, in ENGLISH (corpus is primarily English). Be specific and use technical terms."Input schema / properties / query / examplesRemoved value: -[
- "CAP binary data LargeBinary MediaType",
- "UI5 button properties",
- "wdi5 testing locators",
- "ABAP SELECT statements 7.58",
- "415 error CAP action parameter"
-]Input schema / properties / sourcesAdded value: +{
+ "description": "Optional: specific source IDs to search. If not provided, searches all ABAP sources.",
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+}Input schema / properties / versionAdded value: +{
+ "description": "Optional SAP release filter, applied ONLY to online SAP Help (help.sap.com) — offline docs are unaffected. Omit it for the latest content (the right default for most queries). To pin an older release, copy a result's `versionId` value EXACTLY and pass it back here — it is case-sensitive and its format varies by product (e.g. '2025.001', '2.0.08', '10.0', '2211', 'Cloud', '2026_06'). Discover valid values in one step: run the same search WITHOUT version first; every result shows its `versionId`. Never invent, reformat, or guess the token (a bare year like '2025' is usually a different release). If a version matches nothing, the latest results are returned instead, so no results are lost.",
+ "type": "string"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "results": {
+ "items": {
+ "additionalProperties": true,
+ "properties": {
+ "id": {
+ "type": "string"
+ },
+ "library_id": {
+ "type": "string"
+ },
+ "metadata": {
+ "additionalProperties": true,
+ "type": "object"
+ },
+ "score": {
+ "type": "number"
+ },
+ "snippet": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ },
+ "topic": {
+ "type": "string"
+ },
+ "url": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "id",
+ "title",
+ "url"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "results"
+ ],
+ "type": "object"
+}ui5_version_diffv1.0.0fetchsap_community_search2 fields changedInput schema / properties / query / descriptionPrevious value: -"What to search for in the SAP Community. Examples: 'wizard implementation', 'button best practices', 'authentication', 'deployment', 'fiori elements', or any SAP development topic. Searches both post titles and content for comprehensive results."New value: +"Search terms for SAP Community. Include error codes and specific technical details."Input schema / properties / query / examplesAdded value: +[
+ "CAP action parameter binary file upload 415 error",
+ "wizard implementation best practices",
+ "fiori elements authentication",
+ "UI5 deployment issues",
+ "wdi5 test automation problems"
+]sap_docs_getsap_docs_searchsap_help_get2 fields changedInput schema / properties / result_id / descriptionPrevious value: -"The ID from sap_help_search results (e.g., 'sap-help-12345abc'). This ID is used to fetch the complete page content including metadata."New value: +"Exact ID from sap_help_search results. Copy the ID exactly as returned."Input schema / properties / result_id / examplesAdded value: +[
+ "sap-help-12345abc",
+ "sap-help-98765def"
+]sap_help_search2 fields changedInput schema / properties / query / descriptionPrevious value: -"What to search for in SAP Help Portal. Examples: 'S/4HANA configuration', 'Fiori Launchpad setup', 'BTP integration', 'ABAP development', 'SAP Analytics Cloud', or any SAP product or technical topic. Searches across all SAP Help content."New value: +"Search terms for SAP Help Portal. Include product names and specific topics."Input schema / properties / query / examplesAdded value: +[
+ "S/4HANA configuration",
+ "Fiori Launchpad setup",
+ "BTP integration",
+ "ABAP development guide",
+ "SAP Analytics Cloud setup"
+]searchsap_community_searchsap_docs_getsap_docs_searchsap_help_getsap_help_searchEach tool has a clearly distinct purpose: abap_feature_matrix checks feature availability, sap_community_search targets community posts, search unifies general documentation, etc. Even though search can include community results, the dedicated community tool is justified for deeper retrieval, and descriptions clarify when to use which.
Most tools follow a consistent snake_case pattern with descriptive prefixes (sap_discovery_center_search, sap_get_object_details, etc.), but there are minor deviations like 'fetch' and 'search' being single verbs, and 'abap_feature_matrix' being a noun phrase. Overall mostly consistent.
9 tools is well-scoped for a documentation MCP server covering ABAP, SAP Community, BTP services, API release states, and UI5 version diffs. Each tool earns its place and the count feels appropriate without being overwhelming.
The tool surface is remarkably complete for its domain: it covers official ABAP docs, community content, BTP service discovery and pricing, API release status, ABAP feature matrices, and UI5 version differences. The central search and fetch tools tie everything together, leaving no obvious gaps for typical SAP development documentation needs.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Get up-to-date, version-specific documentation and code examples from official sources directly in…
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Provides tools for searching Google Workspace documentation and much more.
Provides access to Avalara developer documentation, integration guides, and code examples
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/marianfoo/mcp-sap-docs'
If you have feedback or need assistance with the MCP directory API, please join our Discord server