SAP Released Objects Server

Server Quality Checklist

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

Latest release: v1.14.0
Disambiguation5/5
Each tool has a clearly distinct purpose: listing versions, searching objects, getting details, finding successors, listing types, statistics, and compliance checking. No overlap.
Naming Consistency5/5
All tool names follow a consistent 'sap_verb_noun' pattern (e.g., sap_list_versions, sap_search_objects). No deviations.
Tool Count5/5
7 tools is an appropriate number for this domain, covering key operations without being excessive or insufficient.
Completeness5/5
The tool surface covers the full lifecycle of exploring and assessing SAP released objects: version discovery, search, detail, successor, types, statistics, and compliance. No obvious gaps.
Average 4.3/5 across 7 of 7 tools scored. Lowest: 3.7/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 July 6, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds minimal behavioral insight beyond stating the check action. No contradictions are present, but the description does not disclose additional behaviors like rate limits, authorization requirements, or error handling.
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 very concise, consisting of three sentences. Each sentence serves a purpose: stating the action, specifying input and output, and providing usage context. No extraneous information is present, and the critical details are front-loaded.
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 tool's complexity (4 parameters, no output schema) and the availability of annotations, the description is mostly complete. It explains the core functionality, input format, and return values. However, it could be improved by detailing the structure of the output or mentioning any limitations, such as a maximum number of objects.
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 input schema fully documents all 4 parameters (100% coverage). The description adds value by explaining the expected input format ('comma-separated list'), allowing optional type prefixes, and clarifying what the tool returns ('Clean Core Level classification, compliance status, and successor recommendations'), which compensates for the lack of an output 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 states a specific verb ('Check') and resource ('Clean Core compliance of a list of SAP objects'). It clearly conveys the tool's primary function but does not explicitly distinguish it from sibling tools like sap_search_objects or sap_get_object_details, which could also involve objects and compliance checks.
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 context ('Essential for assessing existing custom code during ABAP Cloud migration'), but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference sibling tools as alternatives. The context suggests usage, but lacks direct comparison.
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 declare readOnly=true and destructive=false. Description adds behavioral context by specifying what is returned (Clean Core Level, state, successor info, etc.), complementing annotations without 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?
Two sentences, front-loaded with purpose and use case. No wasted words; every sentence is meaningful and concise.
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 5 parameters and no output schema, description sufficiently covers purpose, return fields, and usage context. It could benefit from explicitly listing all return fields, but 'and more' suffices. Annotations cover side effects.
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 detailed parameter descriptions. The tool description does not add significant parameter information beyond what the schema already provides, so 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?
Description clearly states it retrieves detailed information for a specific SAP object by type and name, listing returned fields. It distinguishes from siblings like sap_search_objects (searching) and sap_find_successor (finding successor).
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?
Description gives clear use case: checking if an object is released for ABAP Cloud. It explicitly references sap_list_versions for version info, providing an alternative. However, it does not explicitly state when not to use this tool vs. all 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the description's behavioral burden is low. The description adds context by specifying the content of statistics (counts by level, type, state, components) and the practical benefit (migration planning). No contradiction, and it provides useful behavioral context beyond the safety profile.
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 main action ('Get overall statistics'), list key output categories, and end with a practical use case. Every sentence contributes value, no redundancy or 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 three optional parameters, no required fields, and no output schema, the description adequately covers the tool's purpose and output content (counts by categories). It could briefly mention the return format (e.g., JSON) or note that parameters filter the statistics, but the schema already handles parameter details.
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%: all three parameters (version, system_type, clean_core_level) have clear descriptions with defaults and enums. The description does not add any new meaning to these parameters beyond what the schema already provides, so it meets the baseline with no extra 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?
The description uses the specific verb 'Get' and resource 'overall statistics about the SAP Cloudification Repository,' listing detailed groupings (by Clean Core Level, object type, state, top application components). It clearly distinguishes from sibling tools like sap_search_objects or sap_get_object_details, which are for searching or individual object details, by framing this as an aggregation/overview tool.
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 states the tool is 'useful for understanding the scope of available APIs and planning ABAP Cloud migration efforts,' providing a clear use case. However, it does not explicitly state when NOT to use it (e.g., for specific object details) or directly reference sibling alternatives, leaving some ambiguity for an AI agent.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value by specifying the output includes counts per Clean Core Level and listing example object types, which provides behavioral context beyond 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, directly front-loaded with the action and resource. Every sentence provides essential information without unnecessary words or repetition, achieving high conciseness.
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 list operation with 3 fully described parameters and no output schema, the description adequately explains the output (list of object types with counts per level) and provides examples. It covers the most important aspects for an agent to understand what the tool 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 description coverage is 100%, so the schema fully documents each parameter. The description adds context about counts per Clean Core Level, which relates to the clean_core_level parameter, but does not add significant meaning beyond the 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 uses a specific verb ('list') and resource ('TADIR object types') along with the context of counts per Clean Core Level, clearly distinguishing it from siblings like sap_list_versions (versions) and sap_search_objects (specific objects).
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 states the tool is 'useful to understand what kind of objects are available and their distribution across Levels A-D,' providing clear usage context. It does not explicitly exclude alternatives but implies when to use this tool for overview vs. other search tools.
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 read-only and idempotent behavior. The description adds value by explaining the tool finds 'released' successors and is used for migration, which goes beyond the annotations. No contradiction is present.
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 (three sentences) effectively front-loaded with the main purpose and key use cases. Every sentence adds essential information without redundancy or 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 the moderate complexity and the rich annotations/schema, the description covers the core functionality well. It could mention the return format (e.g., list of successor objects), but the current information is sufficient for a competent agent to use the tool 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?
The input schema has 100% parameter coverage with detailed descriptions, so baseline is 3. The tool description adds value by providing examples (e.g., 'MARA', 'CL_AUNIT_ASSERT') and clarifying case-insensitive partial matching, which enhances understanding 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 'Find the released successor(s) of a deprecated or non-released SAP object' and gives concrete examples like 'MARA' to 'I_PRODUCT'. This verb-resource combination distinguishes it from sibling tools like sap_search_objects or sap_get_object_details which serve different purposes.
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 mentions 'Essential for ABAP Cloud migration' and 'Also useful for checking if a deprecated API has a modern replacement', providing clear usage context. It does not specify when not to use it or list alternatives, but the context is sufficient for an agent to understand appropriate scenarios.
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?
The description confirms the read-only, idempotent nature (consistent with annotations), explains result pagination via limit/offset, and clarifies search behavior for different system types and clean core levels without contradicting any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections and front-loaded purpose, but it is lengthy due to extensive tips and explanations; some redundancy could be trimmed without losing value.
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?
With no output schema, the description covers all necessary aspects: search behavior, pagination, filtering by multiple criteria, system type differences, and clean core levels; it is fully adequate for an agent to use 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?
All 9 parameters have schema descriptions (100% coverage). The description adds significant extra context with search tips, system type meanings, and clean core level definitions, 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 explicitly states it searches for SAP objects in the SAP Cloudification Repository, lists object types, and clearly distinguishes this search tool from sibling tools like sap_get_object_details which focus on details of specific objects.
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?
Provides extensive search tips and behavior (natural language vs exact names, query length, singular forms) and explains system types and clean core levels. However, it does not explicitly state when to use alternatives like sap_get_object_details for post-search details.
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 provide readOnlyHint and idempotentHint. The description adds that versions are discovered dynamically from GitHub, which is useful behavioral context beyond 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, zero waste. Front-loaded with purpose and ends with usage guidance. Every sentence earns its place.
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 zero-parameter, no-output-schema tool, the description fully covers purpose, source, and usage. 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?
No parameters exist, so description does not need to add parameter info. Baseline 4 is appropriate as the description adds value through usage guidance.
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 'list all available S/4HANA PCE versions' for specific system types, and mentions the dynamic discovery from GitHub, distinguishing it from sibling tools that deal with objects or details.
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 to find which versions can be passed to other tools' and names specific siblings (sap_search_objects, sap_get_object_details), guiding when to use this tool vs alternatives.
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:

[![ROSA MCP server](https://glama.ai/mcp/servers/ClementRingot/ROSA/badges/card.svg)](https://glama.ai/mcp/servers/ClementRingot/ROSA)

Score Badge

Copy to your README.md:

[![ROSA MCP server](https://glama.ai/mcp/servers/ClementRingot/ROSA/badges/score.svg)](https://glama.ai/mcp/servers/ClementRingot/ROSA)

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/ClementRingot/ROSA'

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