ABAP MCP Server

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each of the 13 tools has a clearly distinct purpose: analyze_abap_context provides structured context, batch_read parallelizes reads, fetch_url fetches web content, find_tools enables deferred tools, get_abap_contract returns compressed interfaces, list_tools lists all tools, the four SAP verbs (Diagnose, Read, Search, Write) consolidate granular operations, search_abap_syntax queries syntax docs, search_sap_web searches SAP resources, and validate_ddic_references checks DDIC references. No two tools overlap in functionality.
Naming Consistency3/5
Most tools follow a verb_noun pattern (e.g., fetch_url, find_tools, search_abap_syntax), but there are stylistic inconsistencies: three tools use a capitalized 'SAP' prefix (SAPDiagnose, SAPRead, SAPSearch, SAPWrite) which mixes with lowercase verb-first names, and 'batch_read' uses an adjective-noun structure. While still readable, the convention is not uniform.
Tool Count5/5
With 13 tools, the set is well-scoped. It provides a reasonable number of high-level abstractions that cover the main workflows (read, write, search, diagnostics, utilities) without overwhelming the user. The count is appropriate for a specialized ABAP development server.
Completeness5/5
The tool set covers all major aspects of ABAP development: reading source code and context, writing and activating code, searching code and documentation, performing diagnostics, validating DDIC references, and enabling/disabling tools. The consolidated SAP verbs (Read, Write, Search, Diagnose) ensure that granular operations are accessible, and utilities like batch_read and fetch_url address additional needs. No obvious gaps are present.
Average 3.9/5 across 13 of 13 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 25 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states delegation and argument passing, but does not disclose safety (e.g., read-only nature), side effects, authentication, or rate limits. For a read tool, more safety context would be beneficial.
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 with three sentences: purpose, operation list, and usage rationale. No filler or redundant information. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (delegation to 10+ operations) and no output schema, the description lacks return value details, error handling, or examples. It is incomplete for an agent to understand what each operation returns.
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%, so baseline is 3. The description adds that 'args' must match the underlying granular tool's shape, which provides extra context beyond the schema description. However, it largely repeats the operation enum from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as a consolidated READ verb that delegates to multiple operations, listing all available operations. This distinguishes it from siblings like SAPWrite, though it doesn't explicitly contrast with each sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a use case: wanting a smaller tool surface instead of 50 granular tools. However, it does not mention when NOT to use it or specify alternatives (e.g., the underlying granular tools are not listed as siblings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the delegation behavior and the need to pass appropriate args, but does not specify whether the tool is read-only, what happens on invalid operation, or any side effects. The disclosure is accurate but minimal.
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 extremely concise: two sentences with no extraneous information. It front-loads the tool's purpose and then gives the key delegation pattern.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a consolidated tool with nested args and no output schema or annotations, the description is incomplete. It does not specify what args each operation expects or provide examples, leaving the agent to infer or rely on external knowledge, which risks incorrect 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 both parameters. The description adds the list of accepted operations and clarifies that args are passed through to the underlying tool, which adds some context beyond the schema. However, it does not elaborate on the structure of args for each operation, so value added is moderate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a consolidated search verb that delegates by operation (objects, source, call_graph, dead_code). It distinguishes itself from sibling tools like search_abap_syntax and search_sap_web by being a meta-tool covering multiple ABAP search domains, but does not explicitly contrast them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this consolidated tool versus the individual search tools (e.g., search_abap_syntax, search_sap_web) or other siblings. The description lacks any 'when to use' or 'alternative' hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions inheriting safety guards (ALLOW_WRITE/DELETE, role, audit) which gives some context, but fails to disclose important details like error behavior, idempotency, rate limits, or what happens on failure. The inclusion of 'delete' implies destructiveness but is not elaborated.
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 (three sentences) and front-loads the purpose. It avoids redundancy and directly states the delegation mechanism. However, it could be more structured with bullet points for the operation list to improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (18+ operations, dynamic args) and lack of output schema, the description is incomplete. It does not explain return values, error handling, prerequisites, or how to determine the correct operation for a task. Users are left to infer from the operation list without guidance.
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 descriptions for both parameters. The description adds value by clarifying that 'args' must match the shape expected by the granular tool for a given operation, which is not evident from the schema alone. This dynamic structure is hinted, though no per-operation details are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'Consolidated WRITE verb' that delegates by operation, listing many specific write operations. This distinguishes it from sibling tools like SAPRead (read) and SAPSearch (search), though it doesn't explicitly differentiate from potential granular write tools that might exist outside the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for writing SAP objects but does not explicitly specify when to use this consolidated tool versus alternatives (e.g., if there were separate tools per operation). It lacks when-not-to-use guidance or scenarios where other tools would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions delegation and passing 'args' as expected, but does not disclose side effects, auth needs, rate limits, or error behavior. For a dispatching tool, more transparency is needed.
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, front-loaded with purpose and delegate mechanism. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10+ operations), the description is too brief. It does not explain return values, error handling, or how to choose operations. Missing output schema and behavioral details make it incomplete for an agent.
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 covers both parameters with descriptions. The description adds that 'args' are 'as the underlying tool expects', which provides marginal extra context. No parameter details beyond schema are added.
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 is a consolidated diagnostics verb that delegates by operation, listing specific operations. This distinguishes it from sibling tools like analyze_abap_context or search_abap_syntax which are more specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for diagnostics by listing operations, but does not explicitly state when to use this tool vs alternatives or provide exclusions. The sibling list hints at specialization, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes reading, detecting, and retrieving, but does not explicitly state read-only nature, side effects, failure modes, or permissions needed. Does not disclose what 'structured context report' contains.
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 with zero fluff. First sentence delivers core functionality; second sentence contextualizes as workflow entry point. Perfectly front-loaded and efficient.
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 3 parameters (all with enums) and no output schema, description covers purpose and mode semantics adequately. However, lacks hints about output structure or prerequisites. Slightly incomplete for a tool that likely produces complex results, but reasonable for an entry-point 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% (baseline 3). Description adds meaningful context beyond schema: 'shallow = main source + direct includes only; deep = recursively all references' and explains full vs contract modes by token usage. Adds value above raw enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb+resource: 'Analyzes the complete context of an ABAP object' with specifics (reads source, detects references, retrieves metadata, returns structured report). Identifies as entry point for a workflow, but does not explicitly differentiate from siblings like get_abap_contract or SAPRead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as entry point for abap_develop workflow, but no explicit when-to-use, when-not, or alternatives mentioned. Lacks guidance on selecting between shallow/deep or full/contract modes for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It warns that most tools are deferred and that the 'enable' parameter defaults to true, but does not elaborate on side effects of enabling, rate limits, or idempotency. This is adequate but not rich.
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 front-loads the core purpose and warning, then lists categories concisely within a single paragraph. While the category list is somewhat lengthy, it is necessary for clarity. No redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the tool's purpose and behavior well, including the deferred nature and enablement. However, it lacks information about return values (no output schema) and what happens if tools are already enabled or if enable is false. Adequate but not comprehensive.
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 description only adds marginal value beyond the schema. It mentions categories and implies search by name/description, but does not detail parameter usage or format needs. Baseline of 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 finds and enables ABAP tools by search term or category, with a specific warning about deferred tools. It distinguishes from siblings like list_tools by explaining its role as a prerequisite for non-core tool usage.
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 advises calling this tool before using any non-core tool, provides a comprehensive list of categories, and notes that enabled tools become immediately available. It could further clarify when not to use it or contrast with sibling tools, but the guidance is effective.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that it works with JavaScript-rendered pages and returns extracted text. However, it does not mention potential failure modes, rate limits, or error handling, leaving gaps in transparency.
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 three sentences, front-loaded with the core purpose, followed by context and usage. Every sentence earns its place with no fluff.
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 one simple parameter and no output schema, the description is fairly complete: it explains the tool's function, usage context, and a prerequisite. It could elaborate on error behavior, but it is sufficient for a straightforward tool.
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%, so the baseline is 3. The description does not add new meaning for the 'url' parameter beyond what the schema already provides, as both state the same examples and behavior.
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 fetches and extracts readable content from a URL, works with JavaScript-rendered pages, and distinguishes itself from search tools by noting 'not search'. It specifies the verb 'Fetches and extracts' and the resource 'readable content from a URL'.
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 when to use: 'when you need to read the actual content of a specific URL (not search)'. It also mentions the requirement for TAVILY_API_KEY, providing context for usage. However, it does not explicitly exclude alternatives or specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description partially discloses behavior: it returns compressed content (5-10% of source), no method bodies, and implies cheapness. But it doesn't mention permissions, error cases, or side effects.
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, front-loaded with the action and purpose, with zero waste. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the return value (compressed public interface, signatures) adequately for a simple tool. Lacks output schema or error details, but sufficient given tool complexity.
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 provides 100% coverage for the single parameter, so baseline is 3. The tool description does not add additional meaning 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 returns the compressed public interface (signatures, no method bodies) of a class or interface, using specific verbs and specifying the resource type. It is distinct from sibling tools like SAPRead or analyze_abap_context.
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 states when to use: to give an agent the API surface of a dependency cheaply before writing code. However, it does not mention when not to use or compare with alternatives.
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, so description carries full burden. It discloses behavior: automatically identifies main keyword, loads documentation page, and returns relevant section. This implies a read-only operation with no side effects, but does not explicitly state non-destructiveness or error handling. Adequate but not exhaustive.
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, each purposeful. First sentence defines functionality, second provides usage guidance. No redundant words or fluff. Front-loaded with core action.
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 no output schema, description adequately explains input and process. It does not specify return format (e.g., text, JSON) or error handling, but for a simple search tool with two parameters and high schema coverage, this is mostly complete. Slightly lacking for full transparency.
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 baseline is 3. The description adds context about how the tool processes the query (identifies main keyword, loads page), but does not add new parameter-level meaning beyond the schema descriptions. Minimal added value.
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 it searches official ABAP syntax documentation and returns relevant syntax section, using specific verb 'searches' and resource 'ABAP syntax documentation'. It distinguishes from siblings like 'search_sap_web' which searches broader SAP web, and 'analyze_abap_context' which analyzes ABAP code context.
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?
Explicitly recommends calling 'before writing ABAP code to ensure correct syntax', giving clear when-to-use guidance. However, it does not explicitly mention when not to use or suggest alternatives, which would elevate it to a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It mentions returning compact results (title+URL+snippet) to minimize token usage and the API key requirement. However, it does not disclose rate limits, error handling, or behavior when sources are unavailable.
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 a single paragraph of three sentences, front-loaded with the tool's main purpose. Every sentence adds essential information: what it searches, output format, use cases, and prerequisite. No unnecessary words.
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 no output schema, the description still explains the return format (compact results with title, URL, snippet). It covers usage, parameters, and prerequisites comprehensively. However, it could be more explicit about the absence of complex behavior like pagination or sorting.
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 schema already documents all three parameters. The description adds value by providing examples for the query parameter (e.g., 'SAP Note 2081285') and clarifying sources with human-readable names, going beyond the schema enum descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches three specific SAP resources (help.sap.com, community.sap.com, me.sap.com) via Tavily API, and returns compact results. The verb 'searches' is specific, and the resource is well-defined, distinguishing it from sibling tools like SAPSearch or search_abap_syntax.
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 lists use cases: error messages, SAP Notes, best practices, etc. It also notes the prerequisite TAVILY_API_KEY. However, it does not explicitly contrast with sibling tools or state when not to use it, which would improve the score.
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, but description details parallel execution via Promise.allSettled, read-only restriction, max 20 ops, and latency benefits. Adds behavioral context beyond basic function.
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 paragraphs plus a concise example. Every sentence is informative, no fluff. Structure is logical: purpose, constraints, usage pattern.
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?
No output schema, but the description indicates all results are returned. Could mention error handling or result format, but for a batching utility it's sufficiently 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% with detailed description of operations array. The description reinforces structure with an example and max limit, adding 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 the tool batches multiple read-only calls, executes them in parallel, and returns results together. It distinguishes from siblings by being a batching tool for read-only operations, with explicit list of allowed tools in schema.
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?
It specifies that only read-only tools are allowed and max 20 operations, with an example. Missing explicit guidance on when not to use (e.g., for single calls), but the context is clear.
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, the description carries full burden. It correctly discloses the tool is read-only (does not enable tools) and describes output format. Could mention absence of side effects, but sufficient.
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 front-loaded first sentence stating functionality. No wasted 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?
Comprehensive for a listing tool: covers what it returns, how to use, what it doesn't do. No missing information given the simplicity.
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 has 100% description coverage for the single optional parameter. Description adds context about grouping by category but does not elaborate on parameter usage beyond schema. 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 returns a compact overview of all tools with short descriptions grouped by category, and distinguishes from sibling find_tools by noting it does not enable tools.
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 guidance to use this tool for discovering the right tool for a task, and explicitly contrasts with find_tools which enables tools. Provides clear when-to-use and when-not-to-use.
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, the description carries full burden. It discloses read-only analysis, return of invalid field names, and detection patterns. However, it omits error handling details (e.g., malformed source) and does not specify the return format—though this is acceptable for a simple validation 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?
Two sentences plus a bulleted list of detection patterns. Front-loaded with the main purpose and usage recommendation. Every sentence adds value, no redundancy.
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 one string input, no output schema, and no annotations, the description sufficiently explains the tool's function and output. It could optionally detail the format of the invalid field names list, but the current level is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (source) with a description. The tool description adds context by explaining what happens to the source during validation (DDIC reference checking), which provides meaning beyond the schema alone.
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 does static analysis of ABAP source code to check DDIC references, naming four specific detection patterns. This verb+resource definition distinguishes it from sibling tools like SAPWrite or analyze_abap_context.
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 recommends calling before write_abap_source to prevent syntax errors, providing a concrete when-to-use scenario. No exclusion criteria needed for such a targeted tool.
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:

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

Score Badge

Copy to your README.md:

[![dimidr-abap-mcp MCP server](https://glama.ai/mcp/servers/jackxiong11894/dimidr-abap-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jackxiong11894/dimidr-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/jackxiong11894/dimidr-abap-mcp'

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