abap-mcp

Server Quality Checklist

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

Latest release: v0.4.5
Disambiguation5/5
Each tool targets a distinct functionality: cloud readiness, API release, comparison, rule explanation, formatting, outline, linting, rule listing, and RAP scaffolding. No two tools have overlapping purposes.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_cloud_readiness, list_abap_rules, scaffold_rap_bo). No mixing of conventions.
Tool Count5/5
With 9 tools covering analysis, formatting, scaffolding, and linting, the set is well-scoped for an ABAP development MCP server, providing essential capabilities without unnecessary bloat.
Completeness4/5
The tool surface covers core ABAP development workflows (linting, cloud readiness, API checks, formatting, scaffolding). Minor gaps like generating simple reports or test classes are acceptable given the server's focus on static analysis and boilerplate generation.
Average 4.7/5 across 9 of 9 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 30 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true contradicts the described behavior of generating code artifacts, which is a side effect. While the description adds some behavioral detail (validations, templating), the contradiction undermines trust. Score 1 due to contradiction.
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 concise yet comprehensive, using front-loaded purpose, bullet-like listing of artifacts, and clear limitations. Every sentence adds value without redundancy.
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 7 parameters and an output schema, the description fully covers usage context: what is generated, when to use, limitations, validation steps, and an example. It leaves no critical gaps for an agent to understand invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all parameters. The description adds minimal extra meaning beyond the schema, such as the example and clarifying generated artifact names. Baseline 3 is appropriate.
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 generates a complete RAP managed business-object stack for one root entity, listing specific artifacts (CDS view, behavior definition, handler class, etc.). It distinguishes from sibling tools like lint_abap or format_abap, which are not about code generation.
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?
Explicitly says 'Use this when starting a new RAP business object' and provides exclusions: does not create table or service binding, single-entity BOs only. Includes an example call and mentions validation steps.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint is false. The description adds valuable behavioral context beyond annotations: it is a 'cheap first call,' does not return method bodies or analyze quality, and yields empty outlines for CDS/behavior-definition files. The mermaid option is also explained.
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 concise—about 6 sentences—and front-loaded with the main purpose. Every sentence adds value: purpose, usage guidance, limitations, parameter explanation, and an example. It could be slightly shorter, but it is well-structured and clear.
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 output schema exists and annotations are present, the description is complete enough for this moderately complex tool. It covers what is returned (structural outline of classes, interfaces, FORM), limitations (no method bodies, CDS yields empty), and the optional mermaid output. No critical gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds little extra meaning beyond the schema: it repeats the mermaid option purpose and provides an example call, which is helpful but not significant. No deeper parameter semantics are introduced.
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 returns a structural outline of ABAP sources—listing classes, methods, visibility, interfaces, inheritance, and FORM routines—and explicitly differentiates from siblings by noting it does not return method bodies or analyze code quality. It also specifies that CDS/behavior-definition files yield an empty outline, leaving no ambiguity.
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 this when navigating a large class or legacy program to decide which part to read or edit next; it is the cheap first call.' It also excludes alternatives: 'use lint_abap for' code quality analysis, and mentions CDS files produce empty outlines, helping the agent decide correctly.
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?
Annotations already indicate idempotent and read-only (safe transformation). Description adds that it does not change logic and fails cleanly, but could mention return format or error specifics. No contradiction with annotations.
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?
Three sentences with no wasted words. Front-loaded with purpose, immediately followed by when to use and a concrete example.
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 simple tool with full annotations and output schema, description covers purpose, usage, exclusions, and failure mode fully. No gaps identified.
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 covers both parameters with descriptions (100% coverage). Description adds context that filename can be inferred when omitted and includes a usage example, slightly augmenting 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 it pretty-prints ABAP source, normalizing keyword casing and indentation using abaplint's formatter. Distinguishes as offline equivalent of ADT/SE80 Pretty Printer, separate from sibling tools like lint_abap or explain_abap_rule.
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?
Explicitly tells when to use (inconsistent casing/indentation before review or commit), what it does not do (does not reformat CDS or behavior definitions, does not change logic), and failure behavior (fails cleanly on unparseable source).
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?
Annotations provide readOnlyHint, openWorldHint, and idempotentHint. The description reinforces this by stating 'it is a read-only catalog' and adds context that it does not run analysis or change configuration, which is helpful but not critical given the annotations.
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?
Two sentences plus an example code block. Every sentence adds value: purpose, usage guidelines, and a concrete example. No unnecessary words.
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 simplicity, presence of an output schema, and complete annotations, the description covers all necessary aspects: purpose, filtering options, example, and what the tool does not do, making it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds an example usage with query parameter and explains the filtering concept, providing practical context 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?
The description starts with 'List the abaplint rules this server can check' which clearly states verb and resource. It specifies optional filters and return fields, distinguishing it from siblings like lint_abap (which runs analysis) and explain_abap_rule (which explains a specific rule).
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?
Explicitly states 'Use this when deciding which rules to enable or override in lint_abap, or to discover what a Clean-ABAP-style check exists for.' and clarifies 'It does not run any analysis and does not change configuration,' providing clear when-to-use and when-not-to-use guidance.
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?
Annotations (readOnlyHint=true, idempotentHint=true) indicate no side effects. The description goes beyond annotations by disclosing that the tool uses a bundled snapshot, operates offline, does not connect to SAP systems, and that 'absent from the list' means 'not-released as of snapshot'. It also mentions providing curated CDS successor hints for common tables. This comprehensive behavioral disclosure exceeds what annotations alone convey.
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 detailed but well-organized, starting with the main function, then elaborating on scope, limitations, and an example. While not the most concise, every sentence contributes useful information. The structure is clear, with key points front-loaded. Minor redundancy could be trimmed, but overall effective.
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 simplicity (one parameter, output schema present) and the annotations already handling safety and idempotency, the description leaves no gaps. It covers intended use, limitations, snapshot date, offline nature, what results mean, and how it relates to system ATC. It is fully self-contained for an AI agent to select and invoke correctly.
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?
Input schema has full coverage of 'objects' parameter description (100%). Description adds value beyond schema by explaining the purpose of the parameter in context (objects to check for API status), giving an example format, specifying min/max items, and clarifying that the tool returns statuses. This enriches the schema's basic description, thus earning a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: looking up ABAP repository objects against SAP's Cloudification list and reporting their API status (released, deprecated, not-released). It specifies the resource (ABAP repository objects) and action (check status), and distinguishes itself from the sibling tool 'check_cloud_readiness' by noting that aspect is left to ATC. The example invocation further clarifies usage.
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 explicitly advises when to use this tool: to determine if code can reference objects in ABAP Cloud or to find a released CDS view replacement for classic tables. It also states when not to rely solely on it (not a substitute for ATC) and that the system's own list is authoritative. It highlights limitations (offline snapshot, not real-time) and provides alternatives by mentioning 'check_cloud_readiness' as a complementary tool.
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?
Annotations already indicate read-only and idempotent. The description adds critical behavior: runs entirely offline, doesn't connect to SAP systems, doesn't run ATC, and explains how presets affect semantic checks. 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 moderately long but well-organized. It opens with the core function and output, then usage conditions, limitations, parameter details, alternative tool, and an example. Each section is informative without redundancy, justifying its length.
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 (5 parameters, 3 enums, nested objects, output schema exists), the description covers all essential aspects: offline usage, preset behaviors, focus tags, rule overrides, file limits, and language version. It also mentions output structure. No gaps.
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. The description adds value by explaining the 'focus' tag as a themed review, 'preset' options in detail, and 'rules' as overrides. It also includes an example call, enhancing understanding 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 the tool's purpose: running abaplint static analysis on ABAP, CDS, or behavior-definition sources and returning structured findings. It specifies output fields and distinguishes from sibling check_cloud_readiness.
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 explicitly states when to use (after writing/modifying ABAP code for offline feedback) and when not to (for system-level checks like ATC or object existence). It provides guidance on presets and mentions an alternative tool for cloud readiness.
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?
Annotations declare readOnly, idempotent, not open world. The description adds substantial behavioral context: parsing twice with baseline and cloud versions, diffing, reporting broken code separately, static analysis, no external connections. It explains the process and output structure transparently.
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 relatively long but well-structured: method, output, usage, limitations, example. Every sentence adds value. It could be slightly more concise, but the level of detail is appropriate for a complex tool, and it is front-loaded with the core action.
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 (parsing source, multiple versions, categories) and the existence of an output schema, the description is complete. It covers what, how, when, limitations, and includes an example. No gaps remain.
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% with detailed parameter descriptions. The description adds meaning: explains baselineVersion's role (separate broken code from blockers), gives an example call for files, and clarifies that omitting filename infers type. It enhances understanding 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?
The description clearly states the tool assesses ABAP source for ABAP Cloud readiness by parsing twice and diffing, providing categories, score, grade, and verdict. It distinguishes from siblings by explicitly noting it does not check released API usage (unlike check_released_api) and is static/parser-level.
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 explicitly states when to use: for cloud-readiness queries, before porting to ABAP Cloud, or for tech-debt assessment. It also clarifies limitations: does not check released-API usage (needs ATC), no system connection, verdict is language-level only, not certification. This provides clear when/not-to-use guidance.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds context: it uses dual-parse diff, does not connect to SAP, and reports specific metrics. No contradictions; the description reinforces the safe, stateless behavior.
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?
Approximately 150 words, front-loaded with purpose, then details, exclusions, and an example. Every sentence adds value; no redundancy or fluff.
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 complexity (6 params, nested objects) and existence of output schema, the description sufficiently covers inputs, output expectations, limitations, and usage context. It mentions error handling (parser errors always surface).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value beyond schema by explaining how the tool works (dual-parse diff, content-matching to avoid noise) and what the output includes, though it does not elaborate on individual parameter syntax 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?
The description clearly states it compares BEFORE and AFTER ABAP source, reporting lint findings, cloud-blocker/score/A-D grade movement, and structural changes. It distinguishes from siblings like check_cloud_readiness and git diff, with a specific verb and resource.
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?
Explicitly says when to use ('reviewing a refactor, modernization step, AI-generated rewrite') and what not to use it for ('not a textual diff tool', 'cannot judge functional equivalence'). Provides an example call, giving clear guidance.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that the tool does not perform analysis and is limited to abaplint rules, providing clear behavioral context beyond annotations.
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?
Concise and well-structured: purpose first, then usage context, then limitations, then example. Every sentence adds value with no redundancy.
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 simple single-parameter schema, annotations, and presence of output schema, the description is fully complete. It covers all necessary information for an AI agent to decide when and how to invoke the tool.
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% with a clear description of the 'rule' parameter. The description adds an example usage (explain_abap_rule({ "rule": "exit_or_check" })), which adds practical value 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?
The description clearly states it explains an abaplint rule in depth, listing specific elements (title, description, rationale, examples). It distinguishes itself from sibling tools like lint_abap and check_cloud_readiness by focusing on justification, not analysis.
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?
Explicitly states when to use: 'when a lint_abap or check_cloud_readiness finding needs justification'. Also specifies what is out of scope: 'does not run analysis and only knows abaplint rules; SAP ATC check documentation is out of scope'.
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:

[![abap-mcp MCP server](https://glama.ai/mcp/servers/palimkarakshay/abap-mcp/badges/card.svg)](https://glama.ai/mcp/servers/palimkarakshay/abap-mcp)

Score Badge

Copy to your README.md:

[![abap-mcp MCP server](https://glama.ai/mcp/servers/palimkarakshay/abap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/palimkarakshay/abap-mcp)

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/palimkarakshay/abap-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server