SAP Documentation MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.6/5 across 9 of 9 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 25 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters5/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-sap-docs MCP server](https://glama.ai/mcp/servers/marianfoo/mcp-sap-docs/badges/card.svg)](https://glama.ai/mcp/servers/marianfoo/mcp-sap-docs)

Score Badge

Copy to your README.md:

[![mcp-sap-docs MCP server](https://glama.ai/mcp/servers/marianfoo/mcp-sap-docs/badges/score.svg)](https://glama.ai/mcp/servers/marianfoo/mcp-sap-docs)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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