sap-abap-mcp

by Coaspe

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.4.0
Disambiguation4/5
Tool names are highly domain-scoped and mostly distinct, with clear boundaries between repository, source, semantic, transport, debugging, and runtime operations. Some minor overlap exists around system inspection (`inspect`, `capabilities`, `discovery`) and version/imactive source reads, but the descriptions prevent serious confusion.
Naming Consistency4/5
The overall pattern is consistent: `sap.<domain>.<action>` using lowercase snake_case and English verbs (list, create, inspect, execute, read, write). A few names use bare nouns rather than verbs (e.g., `sap.semantic.documentation`, `sap.runtime.trace.configuration`, `sap.quality.atc.cached`), but the hierarchy remains predictable and readable.
Tool Count1/5
120 tools is an extreme count and severely exceeds what is usually manageable for an MCP server. Even though the tools are organized into domains, the sheer number creates a steep discovery and selection burden, and many competing tools (`preview`, `inspect`, `read`, `list`) multiply that load.
Completeness5/5
The tool surface is exceptionally comprehensive, covering repository lifecycle, source read/patch/activate, transports, DDIC, semantic browsing, syntax checks, unit testing, ATC, debugging, version restore, abapGit, RIP, runtime diagnostics, and data/export. There are no obvious dead ends or missing core workflows for the stated ABAP development purpose.
Average 3/5 across 120 of 120 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 145 commits in the last 12 weeks
- Last stable release on August 20, 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.
This repository includes a glama.json configuration file.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. However, the description adds no behavioral context beyond 'preview'—it doesn't state what the preview returns (e.g., diff, changed objects), whether it makes any changes (though implied by annotations), or what limitations exist. Given the annotations, a moderate score is appropriate, but the description fails to enrich the agent's understanding of the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (one sentence), but this is under-specification rather than admirable conciseness. The sentence merely restates the title and adds no substantive information. It does not front-load any critical detail beyond the title, so the brevity is not an asset.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters, an output schema, and sibling tools for executing or inspecting versions, this description is grossly incomplete. It does not explain the purpose of the preview, what information it returns, how it relates to restore.execute, or any nuances of its usage. Even with an output schema, the description must provide enough context for an agent to decide when and how to use the tool; it fails to do so.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions no parameters at all. With 10 parameters including required fields like systemId, objectName, and versionNumber, the description provides no meaning or context for any of them. It does not compensate for the lack of schema descriptions, leaving the agent without adequate information to construct valid calls.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Preview restoration of one historical revision' is nearly a tautology of the title 'Preview ABAP Version Restore'. It does identify the action (preview) and object (restoration of one revision), but adds no detail about what the preview shows or what makes it distinct from similar operations like version.history.read. The verb is somewhat specific, but the description fails to convey the tool's specific output or purpose beyond what the name already states.
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?
There is no guidance on when to use this tool versus alternatives such as sap.version.restore.execute or sap.version.history.read. The description does not mention that this is a safe, non-destructive preview to run before an actual restore, nor any prerequisites or context for using it. It provides no explicit context for selection.
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?
Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false. The description does not add any behavioral context beyond what the annotations provide, such as whether the update merges or overwrites fields, or triggers 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief (one sentence), but it sacrifices necessary detail and parameter explanations. It is under-specified rather than elegantly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (22 parameters, many sibling tools) and the presence of an output schema, the description is severely incomplete. It does not address core functionality, parameter roles, or typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 22 parameters and 0% schema description coverage, the description must compensate but fails entirely. No parameter is explained, leaving the agent without any guidance on what each parameter does or which are commonly used.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update SAP Watch Task' clearly indicates the verb and resource, but it does not differentiate from sibling tools like enable, disable, or add. The phrase 'through the in-process SAP watch service' adds minimal value.
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 on when to use this tool versus alternatives such as sap.ops.watch.task.enable, disable, or add. No prerequisites, context, or exclusions are provided.
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?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. However, the description adds little beyond these annotations; 'shared RAP generator capability' is too vague to disclose concrete behavioral traits like whether changes are applied or what the output represents.
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 a single sentence and is concise in length, but the phrase 'through the shared RAP generator capability' is wordy and obscure. It lacks any structured explanation, though it is not overly verbose.
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?
The tool has a complex nested schema and an output schema, but the description is too sparse to contextualize the operation. It does not explain how the preview relates to actual generation, what the output represents, or what inputs are required, which is a critical gap for a high-complexity tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the eight parameters or their semantics. The description does not compensate for the missing schema descriptions, so an agent cannot understand what 'systemId', 'generatorId', 'content', and other parameters mean beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Preview RAP Generation' which identifies a clear verb and resource, but the phrase 'through the shared RAP generator capability' is vague and does not clarify what 'preview' actually produces. It does not explicitly distinguish this from the sibling tool 'sap.rap.generate' beyond the word 'preview'.
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?
The description provides no guidance on when to use this tool versus alternatives like sap.rap.generate or sap.rap.validate. There is no mention of use cases, prerequisites, or exclusions, leaving the agent without any context for tool selection.
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?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds minimal context (e.g., 'through shared abapGit capability') but no new behavioral traits. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it sacrifices necessary detail. It is not verbose but fails to be informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no schema descriptions, and an output schema not explained, the description is severely incomplete. It does not clarify what a 'check' returns or how constraints like limit work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for all 4 parameters. The description does not explain the purpose of any parameter (e.g., limit, systemId). This is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Check abapGit Repository' which identifies the resource and action, but 'check' is vague and does not differentiate from sibling tools like 'sap.git.inspect'. It lacks specific details on what the check entails.
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 tool versus alternatives (e.g., 'sap.git.inspect'). No scenarios or exclusions are mentioned.
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?
Annotations already declare readOnly, idempotent, non-destructive behaviors. The description adds only the vague phrase 'through the in-process SAP watch service', which provides no meaningful 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While the description is a single sentence, it is too brief to be informative. Important information about parameters and usage is omitted, making it under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 undocumented parameters, no usage guidance, and minimal behavioral context, the description fails to provide a complete understanding for tool selection and invocation, especially given the presence of an output schema that is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description fails to explain any of the 4 parameters (count, limit, startIndex, includeDetails), leaving the agent unable to understand their semantics or usage.
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 the action 'Read SAP Watch History' and the resource, distinguishing it from related tools by name. However, it lacks detail on what constitutes 'history' and how it differs from sibling tools like 'sap.ops.watch.watchlist.read'.
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 tool versus alternatives (e.g., sap.ops.watch.status or sap.ops.watch.watchlist.read). The agent receives no context about prerequisites or appropriate scenarios.
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?
Annotations indicate the tool is mutable, non-idempotent, and non-destructive, but the description adds no behavioral context beyond that. It does not disclose effects of enabling (e.g., error if already enabled, state changes). With annotations present, the description fails to add value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits critical information. Under-specification reduces its usefulness; it is too brief to be considered well-structured for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters with no descriptions, no output schema explanation, and no side-effect disclosure, the description is woefully incomplete. The output schema exists but is not mentioned, and the purpose is too vague for reliable tool use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema) and the tool description does not explain any of the four parameters (limit, taskId, startIndex, includeDetails). The agent receives no semantic help, making correct invocation difficult.
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 'Enable SAP Watch Task' uses a specific verb and resource, and the sibling list includes 'task.disable', which distinguishes the tool's purpose. However, it does not elaborate on what 'enable' entails (e.g., activating an existing disabled task), which slightly limits clarity.
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?
The description provides no guidance on when to use this tool versus alternatives like 'task.add' or 'task.disable'. There are no usage scenarios, prerequisites, or exclusions mentioned.
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?
Annotations provide some behavioral hints (readOnlyHint=false, etc.) but the description adds no additional detail about side effects, whether it is a one-time trigger, or how it interacts with other watch operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, but under-specified. Conciseness is not beneficial when essential information is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0% schema description coverage, and no output schema details provided, the description is grossly incomplete. It fails to inform the agent about the trigger's effect, parameter roles, or return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameters. Four parameters (limit, reason, startIndex, includeDetails) are left unexplained, leaving the agent without guidance on their usage.
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?
Description clearly states verb 'trigger' and resource 'SAP Watch', distinguishing it from sibling tools like sap.ops.watch.stop or sap.ops.watch.status. However, it does not elaborate on what triggering means in context.
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 on when to use this tool versus alternatives. Does not mention prerequisites or context for triggering SAP Watch.
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?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. However, the description adds minimal behavioral context—only that it works 'through the shared RAP generator capability.' It doesn't disclose pagination with offset/length, possible variations based on generatorId, or what 'defaults' means operationally, so the added value is low.
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 a single, short sentence and is front-loaded with the main action. It's concise with no fluff, but the extreme brevity borders on under-specification. Still, for what it contains, the structure is efficient and clear, earning a 4 rather than a 5 because it omits essential value-add information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having a complex schema with 7 parameters (4 required) and an output schema, the description provides almost no context. It fails to explain the purpose of the tool in any depth, the meaning of the parameters, or the nature of the return value. The completeness is severely lacking, making the tool nearly unusable without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description must compensate by explaining the parameters, but it does not. Parameter names like referenceObjectName and generatorId are left to guesswork, and the enum values for generatorId are undocumented. The description fails entirely to clarify any of the 7 input parameters, leaving the agent blind.
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 uses a specific verb ('Get') and resource ('RAP Defaults'), clearly indicating a retrieval operation. However, it doesn't differentiate from sibling tools like sap.rap.schema or sap.rap.generate, so while the core purpose is clear, the exact domain of 'defaults' remains ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention typical use cases, prerequisites, or why one would choose this over sap.rap.generate, sap.rap.schema, or sap.rap.preview. The phrase 'through the shared RAP generator capability' hints at a context but doesn't explain when to invoke it.
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?
Annotations indicate destructiveHint=true and readOnlyHint=false, which already communicate the mutating nature. The description adds no further behavioral disclosure, such as whether existing objects are overwritten or what side effects occur. The word 'confirmed' hints at a workflow but does not explain the destruction or confirmation requirement. This is acceptable given annotations, but minimal additional context is provided.
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 a single sentence and front-loaded, but it is too terse to be genuinely useful. While concise, it sacrifices all informative content beyond the basic action. For a complex tool with nested parameters, this level of brevity is under-specification rather than effective conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, nested objects, destructive hint, confirmation requirement, and no schema descriptions), this one-sentence description is completely inadequate. It does not explain the generation workflow, return values (output schema exists but is not referenced), or the meaning of 'confirmed preview object set'. An agent would be unable to correctly invoke this tool based on the description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of any of the 8 parameters, including the critical 'confirmation', 'content', and 'systemId' fields. The nested content object with required sub-fields is entirely undocumented. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Generate' and names the resource 'RAP preview object set', indicating the basic action. However, 'confirmed' and 'preview object set' are ambiguous, and it does not distinguish this from sibling tools like sap.rap.preview or sap.rap.validate. The purpose is clear at a high level but lacks specificity.
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 tool versus alternatives. With many sibling tools such as sap.rap.preview and sap.rap.validate, an agent has no information about prerequisites (e.g., needing a confirmed preview) or when this generation step is appropriate. The description is entirely silent on usage context.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds no additional behavioral context, such as what happens if the object is missing in one system or how results are returned. Given annotations cover safety, a score of 2 is appropriate for lack of added value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it lacks essential details. Every sentence should earn its place; this one is too generic and does not provide useful information beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite rich annotations and an output schema (not provided), the description is severely incomplete. It does not explain the comparison result format, behavior for unmatched objects, or parameter roles. With 6 parameters and 0% schema coverage, more depth is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in schema). The description does not explain any of the 6 parameters (objectName, objectType, maxPatchLines, sourceSystemId, targetSystemId, ignoreWhitespace). It fails to compensate for the lack of schema 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?
The description clearly states the action (compare) and the resource (active object across two configured SAP systems). It distinguishes from sibling tools like 'sap.transport.compare' and 'sap.repository.inspect' by specifying 'active object' and 'across two systems'. However, the term 'active' could be more precisely defined.
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 on when to use this tool versus alternatives (e.g., 'sap.repository.inspect' for single system, 'sap.transport.compare' for transports). No prerequisites or context provided.
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?
Annotations already indicate readOnlyHint=false and destructiveHint=false, which imply a non-destructive write operation. The description adds no additional behavioral context, such as side effects, error conditions, or requirements (e.g., system connection).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one short sentence) but is under-specified. It sacrifices necessary detail for brevity, making it less helpful than it could be.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (3 required) and an output schema, the description is severely incomplete. It fails to explain the creation process, required inputs, expected outputs, or any contextual dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 4 parameters (systemId, description, packageName, transportLayer) with 0% schema description coverage. The description does not explain any parameter's purpose, format, or constraints, leaving the agent to guess.
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 'Create one SAP transport request' clearly states the verb (Create) and resource (SAP transport request). It distinguishes from sibling tools that perform other transport actions like delete, release, or inspect. However, it could be more specific about the scope or context.
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?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or conditions. It does not mention when not to use it or what to do before calling this tool.
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?
The description adds no behavioral context beyond the annotations. While 'Launch' is consistent with readOnlyHint=false, it does not explain side effects, staging, or validation requirements. The phrase 'one validated SAP transaction' hints at a precondition but is unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, but this is under-specification rather than conciseness. It omits essential details, making the single sentence insufficient for correct invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 parameters, a nested object, and an output schema, this tool is moderately complex, yet the description provides no context about prerequisites, intended use cases, or operational behavior. The output schema exists, but the description fails to compensate for the lack of parameter and usage information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description provides no information about any of the three parameters (systemId, transactionCode, parameters). The description does not even hint at what these parameters mean or how to format the nested 'parameters' object, leaving agents completely in the dark.
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 the tool's action ('Launch') and resource ('SAP Transaction'), making the core purpose evident. However, it does not differentiate this from the sibling 'sap.ui.transaction_url' tool, and the phrase 'for one validated SAP transaction' adds ambiguity about what validation entails.
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 tool versus alternatives such as 'sap.ui.transaction_url' or other system tools. The description offers no prerequisites, context, or exclusions, leaving the agent without criteria for selection.
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?
Annotations indicate destructiveHint=true, but the description does not detail potential side effects or what executing a plan entails (e.g., modification of system state, data changes). The confirmation parameter hints at a safety mechanism, but no explanation is given.
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 a single concise sentence, but it is too sparse. It achieves conciseness at the cost of completeness, missing important contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 required parameters, no schema descriptions, destructive behavior, and an output schema (not detailed), the description is grossly insufficient. An agent cannot determine how to properly invoke the tool, interpret the confirmation string, or anticipate outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no detail about the parameters. planId is vaguely tied to 'plan', confirmation is mentioned but not defined, systemId is entirely unexplained. The description fails to add meaning beyond field names.
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 action ('Execute') and the resource ('confirmed ABAP application plan'). It distinguishes from siblings like sap.execution.preview (preview vs. execute) and sap.execution.health (monitoring). However, it does not clarify what 'confirmed' means or how the confirmation parameter relates.
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 explicit guidance on when to use this tool vs. alternatives (e.g., sap.execution.preview). No prerequisites or context provided. The agent must infer that a plan must exist and be confirmed, but this is not stated.
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?
The description adds minimal behavioral context beyond the annotations. While annotations indicate destructiveHint=true, the description does not explain what pull entails (e.g., merge strategy, conflict handling, impact on local environment).
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 very short (one sentence), which is concise but comes at the cost of missing essential information. It is appropriately front-loaded but too sparse to be fully useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, an output schema, and destructive side effects, the description is severely incomplete. It does not cover return values, usage context, or parameter interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage and the description does not explain any parameters. Five parameters (branch, systemId, transport, confirmation, repositoryId) are left undefined, so the agent has no guidance on what to provide.
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 the verb 'Pull' and the resource 'one confirmed abapGit repository', making the primary action clear. However, it does not differentiate from sibling tools like sap.git.push or sap.git.stage.
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 tool versus alternatives. There is no discussion of prerequisites, context, or conditions that warrant a pull versus other operations like checkout or stage.
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?
Annotations indicate this is a write operation (readOnlyHint=false) and not destructive or idempotent. The description adds only 'through the in-process SAP watch service' but does not disclose behavioral details such as uniqueness constraints, side effects on existing tasks, or required permissions.
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 a single sentence that is front-loaded with the action. However, its brevity comes at the cost of omitting essential details, making it merely concise rather than effectively structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, 1 required, no schema descriptions), the description is severely incomplete. It does not cover parameter purposes, return values (despite an output schema), or usage examples. The tool requires far more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 21 parameters. The description does not explain any parameter meaning, default behaviors, or relationships between parameters. It adds no value beyond the schema's property names and constraints.
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 uses a specific verb 'Add' and clearly identifies the resource 'SAP Watch Task'. While it distinguishes from sibling watch tools generically, it does not elaborate on the task concept, but the core purpose is clear.
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 tool versus alternatives like sap.ops.watch.task.update or sap.ops.watch.trigger. There is no mention of prerequisites, context, or exclusions.
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?
Annotations indicate readOnlyHint=false (modifies state) and destructiveHint=false. However, removing a task is inherently destructive, suggesting a contradiction. The description does not clarify the behavior or consequences of removal, nor does it address the mismatched parameters (limit, startIndex, includeDetails).
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 a single sentence, which is concise but overly brief. It lacks necessary details about parameters, return values, or behavior. It is not front-loaded with the most critical information for an agent.
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 has 4 parameters, an output schema, and a complex domain (watch tasks), the description is severely incomplete. It does not explain the role of non-required parameters, the output format, or any constraints. The description adds minimal value beyond the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, yet the description provides no parameter explanations. The presence of limit, startIndex, and includeDetails alongside a required taskId is confusing—these seem unrelated to removal. The description fails to add any meaning beyond the schema structure.
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 uses the verb 'Remove' and specifies the resource 'SAP Watch Task', clearly indicating a deletion operation. It differentiates from sibling tools like add, disable, enable, and list. However, the phrasing 'through the in-process SAP watch service' adds minor ambiguity.
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 tool over alternatives such as disable or update. There is no mention of prerequisites, side effects, or whether the removal is permanent. The description lacks context for appropriate use.
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?
Annotations (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already indicate a safe, read-only operation. The description adds no behavioral context beyond the tool name, such as error behavior or output characteristics.
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 a single sentence with no wasted words, but it is too brief and lacks important details, making it under-informative rather than appropriately concise.
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 4 parameters, an output schema, and numerous sibling tools, the description does not provide enough context about when to use this tool, what the output contains, or how it differs from other semantic tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the meaning or usage of parameters (fileUri, systemId, line, column). No value added over 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 'Read SAP ABAP language documentation' clearly states the verb (Read) and resource (SAP ABAP language documentation). However, it does not distinguish from siblings like sap.semantic.definition nor specify that it reads documentation at a specific file position.
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 on when to use this tool versus alternatives such as sap.semantic.definition or sap.source.read_batch. The description lacks context for selection.
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?
Annotations (readOnlyHint, idempotentHint, destructiveHint) already indicate safe, non-destructive read behavior. The description adds minimal behavioral context beyond 'bounded', which is not fully explained. It does not contradict annotations, but also does not enhance them meaningfully.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is concise but under-specifies the tool. For a tool with 5 parameters and an output schema, the description should be longer to include parameter roles or behavioral details. It sacrifices informativeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and multiple parameters, the description covers none of the parameter meanings, output characteristics, or usage context. It is incomplete for an agent to invoke this tool correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but fails. It mentions 'bounded' (possibly via limit or startIndex) but does not explain systemId, fileUri, severity, or startIndex. Agents have no clue how to use parameters without schema descriptions or tool description hints.
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 'Run bounded SAP syntax diagnostics for ABAP source' clearly identifies the tool's action (diagnostics) and target (ABAP source). The term 'bounded' hints at pagination or limits, distinguishing it from unbounded scans. Among siblings like sap.source.activate and sap.source.read_batch, this purpose is distinct.
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 on when to use this tool versus alternatives such as sap.quality.atc.cached or sap.system.inspect. The description lacks any context about prerequisites, excluded scenarios, or comparison with sibling diagnostic tools.
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?
Annotations already indicate readOnlyHint=false (write operation) and openWorldHint=true. The description adds no additional behavioral context, such as side effects on existing text elements, authorization needs, or impact on transport requests.
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 a single sentence, which is concise but lacks structure. It does not organize information hierarchically (e.g., purpose, usage, parameters) and misses important details about the tool's operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters and 0% schema coverage, the description is severely incomplete. It does not explain writeMode values, category enum, objectType restrictions, transport requirements, or the structure of textElements. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must compensate for parameter meaning, but it provides zero parameter information. The 7 parameters (systemId, objectName, objectType, writeMode, textElements, category, transport) are entirely undocumented.
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 specifies a clear verb-resource pair: 'Create or update one ABAP text-pool category.' It distinguishes from sibling tools like sap.text_elements.read (which reads), but the phrasing 'one ABAP text-pool category' could be misleading as the tool actually works with text elements within a category, not the category itself.
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 usage guidelines are provided. The description does not state when to use this tool versus alternatives such as sap.text_elements.read, nor does it mention prerequisites like transport order requirements or system connectivity.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, confirming the tool modifies data but is not destructive. The description adds no further behavioral details, such as required permissions, side effects, or error conditions, which are important for a write operation.
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 a single short sentence, which is concise but lacks structure. It conveys a basic idea but omits critical information, and the phrasing 'after exact confirmation' is ambiguous.
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?
With 4 required parameters and no schema descriptions, the description is far too sparse to be complete. It does not explain the output or return behavior, and the annotations only cover basic safety traits, leaving significant gaps for an 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions are provided. The description only mentions 'confirmation' implicitly but does not explain the purpose, format, or constraints of any parameter, leaving the agent with no semantic guidance beyond parameter names.
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 'Add SAP Transport User after exact confirmation' clearly states a specific action (add) and resource (SAP transport user), and distinguishes from siblings like sap.transport.object.add by focusing on users rather than objects. However, it could be more specific about what a transport user is in this context.
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?
The description provides no guidance on when to use this tool versus alternatives, such as when to add a transport user compared to adding an object or releasing a transport. It does not mention prerequisites or exclusions, leaving the agent to infer usage context.
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?
Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds little behavioral context. 'Fresh version-restore plan' implies a new restore, but no details on side effects, reversibility, or system impact beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but at the expense of completeness. It omits critical information about parameters and usage context, making it insufficiently informative.
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?
For a destructive tool with three required parameters and no parameter descriptions, the description lacks context about how to obtain a plan, what confirmation value to use, and the overall workflow. Its brevity fails to compensate for missing schema details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions in schema). The description does not explain the three required parameters (planId, systemId, confirmation), their meaning, format, or constraints, leaving the agent without essential guidance.
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?
Description states verb 'Execute' and resource 'version-restore plan' with qualifiers 'confirmed' and 'fresh'. It is specific but does not differentiate from sibling execute tools like sap.execution.execute or sap.refactor.execute, which also perform actions.
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 on when to use this tool versus alternatives, nor prerequisites such as needing a confirmed plan from a preview tool. The description does not explain what 'confirmed fresh' means or how to obtain such a plan.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description's role is reduced. It adds no behavioral context beyond what annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence is overly minimal. It is under-specification, not effective conciseness, lacking essential details.
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?
With 4 parameters and available output schema, the description fails to clarify the tool's scope or differentiate it from similar tools like sap.git.check or sap.repository.inspect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any parameters. Parameters like limit and startIndex remain unexplained, despite being crucial for pagination.
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?
Description states 'Inspect abapGit Repository' which is a specific verb+resource. However, it lacks differentiation from sibling tools like sap.git.list or sap.repository.inspect, and 'through the shared abapGit capability' adds no clarity.
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 on when to use this vs alternatives. No context or exclusions provided.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds no behavioral context beyond this, such as auth requirements, pagination via offset/length, or what response to expect.
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 extremely concise, with a single front-loaded sentence 'Inspect one RAP service binding.' No words are wasted. However, it is perhaps too sparse to fully support the tool's complexity, but conciseness itself is strong.
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 has 4 parameters and an output schema exists, the one-sentence description is insufficient. It does not clarify the purpose of offset/length, what data is returned, or how this tool relates to other RAP tools. The presence of an output schema covers return values, but other contextual gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters. Names like systemId and serviceBindingName are somewhat self-explanatory, but length and offset are completely ambiguous, and the description does not compensate for the lack of schema 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?
The description 'Inspect one RAP service binding' uses a specific verb and resource, clearly indicating a read-only examination of a single binding. It distinguishes itself from sibling tools like publish/unpublish, though it does not elaborate on what aspects of the binding are inspected.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclusions, leaving the agent to infer usage solely from the verb 'inspect'.
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?
The annotations (readOnly, idempotent, non-destructive) cover safety, but the description adds no behavioral context such as whether the schema call has side effects, pagination limits, or dependencies on the generator capability. 'Through the shared RAP generator capability' hints at an implementation detail but not a behavioral trait.
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 a single sentence with no fluff and is front-loaded with the action. However, the clause 'through the shared RAP generator capability' is somewhat unfocused but does not waste 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 (7 params, output schema, many siblings), the description is severely incomplete: it doesn't explain what a RAP schema is, how it relates to RAP generation, or what inputs are needed. The output schema covers returns, but usage context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 7 parameters (systemId, generatorId, referenceObjectName, packageName, length, offset, referenceObjectType). Parameter names are self-explanatory to some degree, but the description adds no value.
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 identifies a specific action (Get) and resource (RAP Schema), distinguishing it from sibling tools like sap.rap.generate. However, the phrase 'through the shared RAP generator capability' is vague and doesn't clarify what the schema is or its scope.
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?
The description provides no guidance on when to use this tool versus alternatives such as sap.rap.generate or sap.rap.validate. There are no prerequisites, exclusions, or context 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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description adds minimal value. It does not elaborate on what gets destroyed, side effects, or required authorizations beyond the bare fact that it executes a plan.
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 a single sentence, concise and front-loaded. However, it sacrifices completeness for brevity, omitting critical parameter and usage details.
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?
Despite having an output schema, the description is too sparse for a destructive, non-idempotent tool with two undocumented parameters. The agent lacks necessary context to use the tool correctly without additional lookup.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the 'planId' or 'confirmation' parameters. The word 'confirmed' hints at 'confirmation', but there is no format or example, leaving the agent without essential usage details.
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 the action ('execute') and resource ('refactoring plan'), but 'one confirmed fresh' is ambiguous—it doesn't explain what 'confirmed' means or how it relates to the parameters. It does not differentiate from sibling tools like sap.refactor.preview, but the purpose is generally clear.
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 on when to use this tool versus alternatives. No prerequisites or context for invocation are provided, leaving the agent to infer usage from the name and title alone.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, which covers safety. But the description adds almost no behavioral context beyond 'through SAP ADT trace services'. It does not disclose pagination behavior, error cases, or what the response contains, which is expected given the tool's complexity.
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 a single, efficient sentence with no redundant words. It is appropriately front-loaded and does not waste tokens, though it could be more informative while still being concise.
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 has 5 parameters, an output schema, and many siblings, the description is too sparse. It lacks context about what inspection returns, how pagination works, and when to use this tool over related trace tools, leaving the agent without enough information to correctly invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 5 parameters. The purposes of 'limit', 'startIndex', 'includeDetails', 'traceId', and 'systemId' are not conveyed, making it impossible for an agent to correctly set parameters without external knowledge.
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 verb 'Inspect' and resource 'ABAP Trace', which is specific and not tautological. However, it does not differentiate from sibling trace tools like sap.runtime.trace.list or sap.runtime.trace.statements, so it is clear but lacks distinction.
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?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of when to inspect a trace versus list traces, view statements, or the relationship to other SAP trace tools. This leaves the agent without selection criteria.
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?
Annotations already mark destructiveHint=true and readOnlyHint=false. The description adds minimal extra behavioral context beyond stating it replaces a fragment, missing details on side effects or authorization needs.
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?
Single sentence is concise but under-informative. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is destructive (annotations) and has 6 parameters, the description fails to provide necessary context like return values, transport handling, or activation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the 6 parameters (e.g., oldString, newString, fileUri). Users get no insight into parameter meaning.
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 ('Replace') and resource ('source fragment'), clearly distinguishing from sibling tools like sap.source.activate or sap.source.read_batch.
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 on when to use this tool vs alternatives. The phrase 'under existing write policy' is vague and doesn't clarify prerequisites or exclusions.
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?
Annotations already indicate this is a write operation (readOnlyHint: false) and not destructive (destructiveHint: false). The description adds the scope 'for one ADT source Resource', but it does not disclose other behaviors such as handling of non-existent breakpoints or whether a debug session must be active. This is minimal added 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and is to the point, making it concise and front-loaded. However, it omits important details, so it is concise but not fully informative.
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?
For a tool with four parameters, three required, and no schema descriptions, this description is insufficient. It does not cover parameter semantics, usage context, or behavioral edge cases, despite having sibling tools that would benefit from clearer separation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the four parameters (fileUri, systemId, condition, lineNumbers), and the schema contains no descriptions (0% coverage). With zero compensation from the description, the agent is left with only parameter names to infer semantics.
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 that the tool removes an ABAP debug breakpoint for one ADT source resource, using a specific verb and resource. It does not explicitly differentiate from sibling tools like sap.debug.breakpoint.set, but the verb 'Remove' and resource scope make the purpose clear.
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?
There is no guidance on when to use this tool versus alternatives like sap.debug.breakpoint.set or other debug tools. No prerequisites, context, or exclusions are provided, leaving the agent without direction for tool selection.
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?
The description minimally adds 'through the shared abapGit capability' beyond the annotations, which already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true. No contradictions, but little additional disclosure.
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 a single sentence, which is concise but excessively brief. It lacks valuable information that could be added without sacrificing conciseness.
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?
Despite having an output schema, the description lacks context about pagination, scope, or relation to other git tools. It is insufficient for agents to understand the full behavior of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain parameters but does not. It omits any details about systemId, limit, or startIndex, leaving the agent without guidance on how to use them.
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 the action 'List abapGit Repositories', which is a specific verb and resource. However, it does not differentiate from sibling tools like sap.git.inspect, which might also deal with repositories.
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?
The description provides no guidance on when to use this tool versus alternatives, such as sap.git.inspect or sap.git.check. No context for prerequisites or exclusions is given.
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?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds only 'through the in-process SAP watch service', which provides minimal extra behavioral context. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence that is front-loaded with purpose. It is efficient, though it could include more value without becoming verbose.
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 has 3 parameters and an output schema, the description lacks explanation of pagination (limit, startIndex) and the includeDetails flag. It does not describe the watchlist purpose or return content, leaving gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain any of the three parameters (limit, startIndex, includeDetails). The agent must infer meaning solely from parameter names and defaults, which is insufficient.
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 'Read SAP Watchlist' with a specific verb and resource. It distinguishes from sibling tools like sap.ops.watch.status by focusing on the watchlist itself, but lacks further differentiation context.
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 on when to use this tool versus alternatives like sap.ops.watch.status or sap.ops.watch.history. Description is a single sentence with no usage context, exclusions, or alternative references.
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?
Annotations already indicate non-readonly, non-idempotent, non-destructive. The description adds the condition 'under existing write policy,' implying a required precondition. However, lacks details on authorization, idempotency behavior, or what happens on duplicate creation.
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?
Single sentence, no wasted words, front-loaded with the action. Could be improved by adding parameter explanations without becoming verbose.
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?
Despite having an output schema and 3 parameters, the description gives minimal context. A specialized creation tool requires more detail about what a test include is, required arguments, and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter information. The three parameters (systemId, className, transport) are completely undocumented, failing to add meaning beyond 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?
Clearly states creation of a class test include, matching the tool name. The phrase 'under existing write policy' adds context, but it's slightly vague and does not strongly differentiate from other create tools like sap.repository.create.
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 on when to use this tool vs alternatives (e.g., sap.repository.create). No mention of prerequisites, scenarios, or exclusions.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false, meaning the tool is a destructive write. The description says 'Publish' which is consistent but adds no extra behavioral context, such as what specifically gets destroyed (e.g., overwrites existing published state) or any irreversible effects. The description adds no value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of 5 words, which is brief but at the cost of missing essential information. For a tool of this complexity with destructive behavior and required confirmation, more detail is needed. The conciseness is a net negative because it leaves critical gaps.
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?
The description is incomplete given the tool's complexity (destructive write with required confirmation) and the availability of an output schema. It fails to explain what happens after publishing, what the output contains, or how to interpret the parameters. The agent cannot fully understand the tool's behavior from this description alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain the three required parameters: systemId, serviceBindingName, and confirmation. However, the description only states 'Publish one confirmed RAP service binding' and provides no explanation of what each parameter represents, especially 'confirmation' which is ambiguous (e.g., confirmation token, confirmation flag). This makes it very difficult for an AI agent to correctly invoke the tool.
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 with a specific verb 'Publish' and resource 'RAP service binding'. It adds the qualifier 'confirmed' which distinguishes it from unpublish or other operations. The purpose is immediately clear and distinguishes from sibling tools like sap.rap.binding.unpublish.
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?
The description lacks any guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., binding must be confirmed), side effects, or what happens if the binding is not confirmed. The absence of usage context leaves the agent without critical decision-making information.
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?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, clearly indicating the tool is safe and non-destructive. The description adds 'bounded', hinting at constraints like depth and node limits, but doesn't elaborate further. It does not contradict annotations.
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 a single front-loaded sentence that conveys the core action. It is concise with no wasted words. However, given the complexity of the tool (8 parameters), it might benefit from slightly more detail without losing conciseness.
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?
The tool has an output schema, so return values are presumably documented. However, the description omits parameter semantics and usage context, making it incomplete for an agent to invoke correctly. The presence of 8 parameters with no description leaves significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 8 parameters with 0% description coverage. The description provides no explanation for any parameter, despite the need to compensate for the low coverage. Parameters like 'depth', 'maxNodes', and 'customOnly' remain unexplained, making it hard for an agent to use them correctly.
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 the tool builds a 'bounded where-used dependency graph' for ABAP. It uses a specific verb ('Build') and resource ('dependency graph'), and the term 'where-used' distinguishes it from other tools. However, it does not explicitly differentiate from the sibling tool 'sap.repository.where_used', which likely provides a simpler list.
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?
The description lacks any guidance on when to use this tool versus alternatives. The sibling list includes 'sap.repository.where_used', which is probably a simpler variant, but no context is given for choosing one over the other.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description's behavioral burden is lower. It adds minimal context about resolving to a canonical resource but omits details on error handling or permissions.
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 concise at 10 words, but it achieves this by omitting important details. The single sentence is front-loaded but under-specified.
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 has 4 parameters and an output schema, the description is too brief. It does not explain the meaning of 'resolve' or the parameters, leaving the agent without sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no information about the four parameters (systemId, objectName, objectType, includeSourceSummary). The description fails to compensate for the lack of schema 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?
The description clearly states the verb 'Resolve' and the resource 'ABAP object to a canonical ADT Resource'. It gives a specific purpose but does not distinguish from similar sibling tools like sap.repository.inspect.
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 on when to use this tool versus alternatives. Single sentence provides no context for usage scenarios or exclusions.
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?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds the phrase 'through SAP ADT trace services', which provides minimal additional context. It does not contradict annotations, but it adds little beyond what annotations already convey.
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 a single sentence, which is concise but lacks structure. It is front-loaded with the action, but given the complexity of the tool (5 parameters, 0% schema descriptions), more detail is needed.
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?
The description is too vague for an agent to use correctly. It does not explain the concept of a trace hit list, how to obtain a traceId, or the significance of pagination parameters. The presence of an output schema does not compensate for the lack of input context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it provides no information about any of the 5 parameters, including required fields like systemId and traceId, leaving the agent without guidance on how to fill them correctly.
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 'Read ABAP Trace Hit List', which is a specific verb and resource. It clearly indicates what the tool does, but it does not elaborate on what a hit list contains, leaving some ambiguity. It is distinct from sibling tools as no other tool reads trace hit lists.
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 tool versus alternatives. There is no mention of prerequisites, context, or exclusions. The sibling tool sap.runtime.trace.configuration is related but not referenced.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint, so the description adds no extra safety context. It does not disclose any behavioral traits beyond the schema and annotations, which is adequate but not enriching.
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 a single sentence, efficient and front-loaded. However, it is too terse and sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters (2 required) with no schema descriptions and no output schema details, the description is severely incomplete. It should explain parameter roles and return value expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage and no parameter information in the description, the agent has no guidance on what parameters like systemId, fileUri, line, column, or implementation mean. This is a critical gap.
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 uses a clear verb ('Resolve') and resource ('ABAP definition or implementation'), distinguishing it from semantic siblings like components or completion. However, it could be more specific about what 'resolve' entails.
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 on when to use this tool versus alternatives like sap.semantic.components or sap.repository.resolve. The description lacks context for appropriate usage.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the 'bounded' aspect but doesn't explain behavioral details like pagination or return structure. With annotations covering core traits, a score of 3 is appropriate.
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 a single sentence, making it extremely concise and front-loaded. However, it is almost too brief, sacrificing valuable information. Still, it earns points for lack of verbosity.
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?
With 7 parameters, no parameter descriptions, and an output schema presumed present, the description is too minimal. It fails to explain key aspects like what 'bounded' means, how results are limited, or how to interpret the output. The tool's complexity demands more completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The description does not explain any of the seven parameters (e.g., systemId, fileUri, limit, superTypes), leaving the agent with no help beyond the raw schema. This is a critical gap.
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 the tool reads an ABAP type hierarchy with a 'bounded' qualifier, differentiating it from sibling semantic tools like 'sap.semantic.components' or 'sap.semantic.definition'. However, it does not elaborate on what 'bounded' means, slightly reducing clarity.
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 tool versus alternatives (e.g., sap.semantic.components or other hierarchy tools). There is no mention of context, prerequisites, or exclusions.
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?
Annotations indicate read-only, idempotent, non-destructive. Description adds only capacity limit (up to 100), not other behavioral traits like response format or pagination.
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?
Single sentence is concise but lacks detail. Functional but minimal.
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?
Description omits critical context: requires systemId, object names, line ranges, batch limit. Not adequate given tool complexity (array of requests with defaults).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%; description does not explain any parameters (systemId, requests, objectName, startLine, lineCount). Fails to compensate for schema gaps.
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 verb (read), resource (source ranges from ABAP objects), and limit (up to 100). Distinguishes from sibling tools like sap.source.diagnose.
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 on when to use this tool versus alternatives (e.g., sap.source.diagnose for single objects or error details). No mention of prerequisites or context.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety and side effects. The description adds functional details (literal vs regex search) but does not disclose behavioral nuances like result limits, pagination, or the meaning of openWorldHint. With annotations present, this is acceptable but not enriched.
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 a single concise sentence with no fluff, front-loading the action 'Search'. It is easy to read and appropriately sized for a simple purpose, though it sacrifices informative detail for brevity.
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?
With 8 parameters, 0% schema coverage, and a complex sibling ecosystem, this minimal description is insufficient for an agent to select and invoke the tool correctly. It lacks parameter semantics, usage guidance, and behavioral context, despite the availability of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only hints at the regularExpression parameter via 'literal text or a regular expression', but does not explain limit, maxObjects, startIndex, contextLines, or their relationships. This fails to provide meaningful parameter semantics.
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 the tool's function with the specific verb 'Search' and the resource 'ABAP source', noting two modes (literal text or regular expression). It distinguishes itself from siblings by specifying the search target, but does not explicitly contrast it with similar tools like sap.repository.search.
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?
The description provides no guidance on when to use this tool versus alternatives such as sap.repository.search or sap.source.read. There is no mention of scoping, prerequisites, or exclusions, leaving the agent without decision criteria.
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?
Annotations provide some safety context (readOnlyHint=false, destructiveHint=false, idempotentHint=false). The description adds that the output is 'temporary', which is useful. However, it does not disclose side effects (e.g., whether data is stored), permissions needed, or what 'full ADT discovery data' entails. Overall, adds marginal value 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no extraneous content. However, it sacrifices necessary detail for brevity, leaving key information unstated. It is concise but not sufficiently informative.
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 simplicity (one parameter, output schema exists), the description should clarify the scope of 'ADT discovery data', the purpose of the export, and any side effects. It fails to provide enough context for an agent to understand when and how to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'systemId' with no description (schema coverage 0%). The description does not explain the parameter's meaning, format, or constraints beyond the schema's minLength. The agent must infer from the parameter name alone.
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 the verb 'export' and the resource 'full ADT discovery data' with a specific outcome 'to a temporary JSON artifact'. It distinguishes the tool's purpose from sibling tools, as no other sibling has a similar description. However, it does not explicitly differentiate itself from siblings or note uniqueness.
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?
There is no guidance on when to use this tool versus alternatives. No prerequisites, context, or exclusions are mentioned. The description lacks instructions for appropriate usage 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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat them. The description adds no behavioral context beyond the annotations, which is acceptable as annotations are 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 is extremely concise (one sentence), which is efficient. However, it could provide more actionable information without becoming verbose.
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 output schema exists (but not shown), the description does not mention return values. It lacks context about what the tool returns and any side effects. For a simple read tool, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the description does not explain any parameter's meaning or usage. The schema itself defines enums and defaults, but the description adds no value for parameter semantics. This is a significant gap.
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 'Read one ABAP text-pool category,' which clearly identifies the verb (read) and resource (ABAP text-pool category). It distinguishes from the sibling tool sap.text_elements.write, but could be more specific about what 'text-pool category' entails.
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 on when to use this tool versus alternatives (e.g., sap.text_elements.write or other read tools). There is no mention of prerequisites or contexts where this tool is appropriate.
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?
Annotations already indicate destructiveHint=true, so the description's mention of 'delete' aligns. The description adds the requirement for 'exact confirmation', which is a behavioral detail. However, it does not disclose potential side effects or prerequisites beyond confirmation.
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 very brief (only 5 words) and front-loaded. While concise, it sacrifices necessary detail, making it less informative for a tool with three required parameters and significant implications.
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 that this is a destructive operation with three required parameters, the description lacks essential context: what a transport is, prerequisites for deletion, and what happens post-deletion. Even with an output schema, the description is too sparse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain any of the three parameters (systemId, transportNumber, confirmation) beyond hinting at confirmation. With schema description coverage at 0%, the description fails to add meaning to the parameters.
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 that the tool deletes an SAP Transport and requires 'exact confirmation'. It is distinct from sibling transport tools like sap.transport.create and sap.transport.release. However, it could be more specific about what constitutes a transport in this context.
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?
The description provides a usage hint ('after exact confirmation') but does not give explicit guidance on when to use this tool versus alternatives like sap.transport.release or sap.transport.inspect. No when-not-to-use advice is present.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds no additional behavioral context beyond stating 'Read,' so it does not enhance transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence), but it is too brief and lacks structure. It could be expanded slightly to include parameter or behavioral details without losing conciseness.
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 has 6 parameters (2 required) and an output schema, the description is insufficient. It does not explain the purpose of parameters or what the output contains, relying on the output schema for return values. The description should at least mention key parameters like view and transportNumber.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no explanation of any parameters. It vaguely hints at the 'view' parameter with 'details or objects' but fails to describe the other five parameters (systemId, transportNumber, limit, startIndex, includeObjects). The description adds almost no value beyond the property names in 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 states the tool reads details or objects for a single transport request, distinguishing it from sibling tools like sap.transport.list (which lists multiple transports) and sap.transport.compare (compares transports). However, it does not explicitly differentiate or mention alternatives.
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 inspecting a specific transport but provides no explicit guidance on when to use this tool over alternatives like sap.transport.list or sap.transport.compare. No when-not-to-use or prerequisites are mentioned.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds 'bounded page' hinting at pagination, which is beyond annotations. However, it does not explain what 'bounded page' entails or any other behavioral details.
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 a single sentence, which is concise but sacrifices important detail. It is not overly long, but it lacks structure and key information.
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 (4 parameters, pagination) and lack of output schema details, the description is insufficient. It does not explain pagination, required systemId, or result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to the parameters (user, limit, systemId, startIndex). It mentions 'user transports' but does not explain how 'user' filters results or how pagination works.
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 the tool lists user transports. It uses a specific verb and resource. While it doesn't explicitly differentiate from siblings like sap.transport.inspect, the only other transport read tool is inspect, which implies detail view, so the distinction is reasonable.
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 tool versus alternatives such as sap.transport.inspect or other listing options. There is no mention of prerequisites or context.
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?
Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, so the description's main added value is the 'bounded', 'opt-in', and 'one-shot' character. These are meaningful constraints, but the description does not explain what 'bounded' means operationally, such as row limits, time limits, or required execution guards.
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 singular, compact sentence with no wasted words. Each qualifier of 'bounded, opt-in, read-only, data-preview' contributes some distinction, and the main action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 12 parameters, nested objects, an enum, a required systemId, and zero schema descriptions, the one-sentence description is severely under-specified. It leaves the agent without enough instruction to construct a query or understand how 'sql', 'data', and 'maxRows' relate to one another.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter guidance for 12 fields, including the required systemId, the nested data structure, filters, sorting, and rowRange. This is a major gap for an agent needing to construct a correct request.
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 identifies a concrete action ('Run') and a specific resource ('read-only data-preview query'). The qualifiers 'bounded, opt-in, read-only' help separate it from the broad list of sibling read/query tools, though it does not specify what data domain or entity is queried.
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?
There is no explicit guidance on when to use this tool versus alternatives such as sap.data.export, sap.source.read, or sap.classic.read. 'Bounded, opt-in' suggests constrained usage but does not state a scenario or exclusion condition.
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?
Annotations already indicate non-read-only (readOnlyHint=false) and non-idempotent (idempotentHint=false). Description adds only 'confirmed' implying a necessary confirmation, but lacks details on side effects, authentication requirements, or what happens upon creation.
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?
One short sentence that efficiently conveys the tool's action. However, it could be slightly more informative without sacrificing conciseness (e.g., hinting at parameter purpose).
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?
With 6 parameters, no schema descriptions, and no explanation of output (though output schema exists), the description is too sparse. Missing context on confirmation semantics, optional parameters, and expected usage flow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet description provides no explanation for any of the 6 parameters (systemId, repositoryUrl, packageName, confirmation, branch, transport). No parameter meanings are clarified.
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 verb 'create' and resource 'abapGit repository binding', adding 'confirmed' to indicate a required confirmation parameter. This distinguishes it from sibling tools like sap.git.list (list) and sap.git.inspect (inspect).
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 on when to use vs. alternatives (e.g., other git tools like sap.git.pull, sap.git.push). No prerequisites or usage context provided.
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?
Annotations indicate readOnlyHint=false and destructiveHint=false, which aligns with the 'Create' verb. The description adds 'bounded' implying some form of constraint, but does not elaborate on side effects, permissions, or rate limits. The behavioral transparency is adequate given annotations, but could be improved.
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 very concise at one sentence, but it fails to convey necessary details. While brevity is generally good, here it sacrifices clarity and completeness.
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 presence of an output schema and 4 parameters (2 required), the description is too sparse. It does not explain return values or how to use the parameters effectively, making it hard for an agent to invoke the tool correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist in the schema. The tool description does not explain any parameters like limit, startIndex, systemId, or repositoryId. The term 'bounded' hints at pagination but is insufficient for proper usage.
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 uses a specific verb ('Create') and a resource ('bounded abapGit staging snapshot'), which clearly indicates the tool's purpose. However, it does not differentiate from sibling tools like sap.git.push or sap.git.pull, which are also git-related.
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 tool versus alternatives such as sap.git.push or sap.git.branch.switch. There is no mention of prerequisites, context, or scenarios where this tool is appropriate.
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?
Annotations already mark destructiveHint=true and readOnlyHint=false, so the safety profile is known, but the description adds no behavioral context such as what 'unlink' does to the repository, whether it is reversible, or what confirmation entails. The word 'confirmed' hints at a requirement but does not explain the consequence. With annotations present, the burden is lower, but the description still contributes little beyond the action name.
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 a single, front-loaded sentence with no wasted words, making it very concise. However, it borders on under-specification for a destructive tool with three required parameters, so it does not earn a perfect score.
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?
Although the output schema exists and annotations mark the tool as destructive, the description is too thin for complete context. It omits parameter semantics, especially the confirmation value, and any operational detail about what unlink actually does. For a destructive action, the agent needs more than a one-sentence summary to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the three parameters (systemId, repositoryId, confirmation). The most critical parameter, 'confirmation', is left entirely unexplained—its format, source, and requirement are not stated. The description fails to compensate for the low schema coverage.
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 ('Unlink') plus a resource ('abapGit repository') and adds the qualifier 'confirmed'. It clearly distinguishes itself from sibling git tools like branch.switch, pull, push, stage, and inspect. There is no ambiguity about what action the tool performs.
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?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or related tools such as sap.git.delete or sap.repository.delete. The only implied usage is from the verb 'Unlink' itself, which is not enough for a destructive operation.
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?
Annotations indicate non-read-only, non-destructive, non-idempotent, but the description adds no behavioral detail (e.g., whether task execution stops, what side effects occur). Disabling is a state change, but no disclosure of needed permissions or impact.
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?
Single sentence, front-loaded, no redundant information. However, it is too terse, sacrificing necessary detail for brevity.
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?
Despite having an output schema, the description omits explanation of parameters and the precise effect of the disable action. It does not address the complexity of the input schema or provide enough context for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain any of the 4 parameters (taskId, limit, startIndex, includeDetails). The presence of pagination parameters for a disable action is confusing and left unexplained.
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 action ('Disable') and the resource ('SAP Watch Task'), distinguishing it from siblings like 'enable' or 'remove'. The mention of 'through the in-process SAP watch service' adds context, though somewhat redundant.
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 on when to use this tool versus alternatives (e.g., enable, remove). No description of prerequisites or typical use cases, leaving the agent to infer usage from the name alone.
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?
Annotations already communicate that this is non-read-only and non-idempotent, and the description adds the constraint that the object must be created under an existing policy. However, the description gives no detail about duplicate behavior, name collisions, what happens to existing objects, or operation-specific side effects, which limits its 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 a single, concise sentence with no filler or redundant information. It is equivalent to saying the resource and action, and adds one contextual note about an existing policy. It is shorter than it could be without losing the core message.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 9 parameters, nested options, an output schema, and strong sibling competition, but the description conveys essentially none of that context. It omits valid objectType values, packageName behavior, activation/source semantics, transport request handling, and any guidance about how to use additionalOptions. This is too little context for an agent to call the tool correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema description coverage is only 22%, leaving most required parameters like systemId, objectType, name, and parentName with no schema descriptions. The tool description provides no replacement parameter guidance, so an agent cannot determine what values are accepted or how required fields interrelate.
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 uses a specific verb (Create) and a specific resource (SAP repository object), so an agent knows what operation is performed. It stops short of a 5 because the phrase 'under existing policy' is ambiguous and the description does not explicitly distinguish this create tool from other SAP creation siblings.
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?
The description notes that the object is created 'under existing policy,' which implies a prerequisite, but gives no guidance about when to prefer this tool over alternatives, no mention of required preconditions, and no note about not using it for transports, writes, or generation. An agent is left to infer all assignment criteria.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds the qualifier 'bounded' but does not explain what that means (e.g., depth limits, scope). No additional behavioral traits like authentication needs or rate limits are disclosed.
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 a single short sentence, which is concise but at the expense of completeness. It is front-loaded with the verb and resource, but lacks any structured information about parameters or usage, making it barely adequate.
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 parameters, nested objects) and the absence of schema descriptions, the description is severely incomplete. It does not explain pagination, filtering, or the concept of 'bounded' references. The presence of an output schema does not compensate for the lack of input guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate but fails to explain any parameters. It only implies that 'objectName' identifies the object, but does not clarify systemId, filter, limit, startIndex, or other fields. The agent has insufficient information to set parameters correctly.
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 the verb 'Find' and the resource 'bounded where-used references for one ABAP object.' While specific, it does not differentiate from sibling tools like sap.repository.inspect or sap.repository.resolve, which might have overlapping functionality.
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 tool versus alternatives. There is no description of prerequisites, use cases, or situations where this tool should not be used. The agent must infer usage from the purpose alone.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description is not required to repeat safety info. It adds 'through SAP ADT trace services' for context, but no further behavioral details. 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but too brief to be useful. It lacks any structured breakdown of functionality or parameters, making it under-specified rather than concise.
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?
With four parameters (one required) and zero schema descriptions, the description fails to cover pagination, filtering, or the meaning of 'includeDetails'. An output schema exists but is not referenced. The description is incomplete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about the four parameters (systemId, limit, startIndex, includeDetails). This is a major gap; the description should explain parameter meanings and constraints.
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 action (list) and resource (ABAP Trace Configurations) with a specific context (through SAP ADT trace services). This distinguishes it from siblings like sap.runtime.trace.hit_list.
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 on when to use this tool versus alternatives. The description does not mention preconditions, side effects, or comparison with related tools like sap.runtime.trace.hit_list.
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?
Annotations already indicate readOnly, openWorld, idempotent, and non-destructive behavior. The description reinforces the read intent but adds no new behavioral context beyond stating the operation is a read.
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 a single concise sentence, but it sacrifices completeness. It could include more detail without becoming verbose.
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 7 parameters, 0% schema description coverage, and no explanation of how 'completion proposals' differ from 'element details', the description is too brief. The presence of an output schema does not excuse the lack of context for input semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description only hints at the 'elementDetails' parameter by mentioning 'element details', but 0% schema description coverage means the other 6 parameters (line, column, limit, startIndex, fileUri, systemId) are left unexplained. The description does not compensate for the lack of schema documentation.
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 that the tool reads ABAP completion proposals or element details, specifying the verb 'Read' and the resource. However, it does not differentiate from sibling tools like sap.semantic.components or sap.semantic.definition, which may also involve reading semantics.
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 tool versus its alternatives. The description neither specifies usage context nor excludes any scenarios, leaving the agent without decision support.
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?
Annotations already indicate readOnlyHint=false (write operation) and destructiveHint=false (not destructive). The description adds that the report is 'styled DOCX', implying formatting. However, it does not disclose additional behavioral traits like storage location, file size limits, or permissions required. Given the annotations, the description provides adequate but minimal added value.
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 a single sentence, which is concise but at the expense of necessary detail. It front-loads the core action but fails to include parameter explanations or usage context. The conciseness is not balanced with completeness.
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 (nested objects in scenarios, 3 parameters including a date with pattern and a report title), the description is insufficient. Although an output schema exists, the description does not mention any output behavior or default values. The agent lacks critical information to use this tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the three parameters (testDate, scenarios, reportTitle). It only mentions 'test scenarios and screenshots' which maps to the scenarios array but ignores testDate and reportTitle. This is insufficient for an agent to understand how to populate the parameters correctly.
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 action (Create), the output (styled DOCX report), and the input (test scenarios and screenshots). It is specific and distinguishes from sibling tools like sap.quality.test_include.create (creates test includes) and sap.artifact.mermaid.create (creates mermaid diagrams).
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?
The description lacks any guidance on when to use this tool versus alternatives. No context about prerequisites, when to avoid, or alternatives is provided. The agent receives no decision-making support.
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?
The description does not contradict the annotations (readOnlyHint=false, destructiveHint=true, idempotentHint=false). It adds the useful context that the underlying data source is read-only/opt-in. However, it never discloses the actual side effect — creating or overwriting a file at filePath on the target system — nor any permission or availability requirements, so the behavioral disclosure stays mostly where the annotations already left it.
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?
A single dense sentence contains the core facts: the action, the resource, and the output formats. It is front-loaded and free of filler. Minor structural awkwardness in the compound noun 'opt-in SAP read-only data query or cached data view' prevents a perfect score.
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?
Although an output schema exists, the description is too thin for a destructive, 12-parameter tool with 0% schema coverage. It omits the required systemId context, the prerequisite relationship between the query/cached view and this export, what kind of file path is expected, and the fact that the operation writes persistent files. An agent would need to reverse-engineer the semantics from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for 12 parameters, but it only hints at fileType and filePath via the 'to CSV or XLSX' phrase. It never explains the core distinction between the two input sources (inline sql/data vs a cached data view via webviewId), nor the meaning of systemId, maxRows, filters, sortColumns, resetFilters, or resetSorting. This is a significant gap for a 0%-coverage 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?
States a specific verb, resource, and format: 'Export' + 'one opt-in SAP read-only data query or cached data view' + 'to CSV or XLSX'. This scopes it away from sibling export tools like sap.source.export (source code) and sap.system.discovery.export (system discovery metadata). Docked one point because 'opt-in' is cryptic and, unlike the ideal, the description does not explicitly name the siblings it is distinct from.
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 on when to use this tool versus alternatives. The phrase 'cached data view' implies a prerequisite (the data query/view must already exist), but the description never says 'use this after X' or 'instead of Y'. With export-like siblings present and a rich 12-parameter schema, an agent is left to infer the selection context entirely.
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?
The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds 'stateful ADT debug client', which implies the tool depends on an active debug session, but it does not elaborate on behavior like error handling or prerequisites. This adds some value but not rich context.
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 concise sentence, front-loaded with the action and resource. It contains no filler or redundant information.
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?
With an output schema present, return values don't need to be described, but the tool has 3 parameters with no descriptions and no context about when it should be used or what constitutes a valid session. The description is minimal and leaves the agent without enough information to confidently invoke the tool correctly, especially given the large sibling set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the three parameters (systemId, debugUser, terminalMode). Parameter names are somewhat self-explanatory, but terminalMode is ambiguous and the description provides no additional meaning. For a tool with low schema coverage, this is a significant gap.
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 uses the specific verb 'Inspect' and identifies the resource 'ABAP Debug Session', clearly stating the tool's function. It also mentions 'stateful ADT debug client' which adds context. However, it doesn't distinguish this from sibling debug inspection tools like sap.debug.status or sap.debug.stack, so it lacks explicit differentiation.
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?
There is no guidance on when to use this tool over alternatives. The description does not mention conditions, exclusions, or compare with other debug tools. Sibling tools like sap.debug.status, sap.debug.stack, and sap.debug.variables exist but no clear context for selection is provided.
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?
Annotations already indicate the tool is not read-only and has side effects. The description adds the context 'stateful', implying persistent state, but does not disclose resource implications, authentication needs, or the need to stop the session. This is minimal added 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?
The description is a single sentence, front-loaded with the action, and contains no filler. It is appropriately concise but does not sacrifice clarity for brevity.
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?
Despite having an output schema, the description omits critical context such as prerequisites (e.g., active system, user), session lifecycle management, and relationship to other debug tools. It reads as a minimal stub for a stateful operation, leaving the agent under-informed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description offers no explanation for systemId, debugUser, or terminalMode. It fails to compensate for the schema's bare parameter names, leaving the agent without semantic understanding of the parameters.
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 specifies the action 'Start' and the resource 'ABAP Debug Session', with the mechanism 'stateful ADT debug client'. It clearly indicates what the tool does and the verb 'start' distinguishes it from sibling tools like sap.debug.session.inspect and sap.debug.session.stop, though it does not explicitly name alternatives.
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?
The description provides no guidance on when to use this tool versus debug-related alternatives. It does not mention that starting a session is a prerequisite for breakpoints or that the session should be stopped later. No when/when-not context 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?
The description adds no behavioral context beyond the annotations. It does not mention side effects on the debuggee, the need for an attached session, or the deterministic behavior of step operations. The annotations indicate mutation, but the description does not elaborate.
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 a single concise sentence with no redundant wording. However, it is under-specified, which detracts from its overall effectiveness, but it scores well on pure brevity.
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?
This is a control action with four parameters, including a conditional requirement (targetLine for jumpToLine), yet the description omits all such context. It does not explain prerequisites, execution side effects, or how to select among step types.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does not explain the stepType values beyond the generic 'continue or step', nor does it clarify that targetLine is required for jumpToLine or the role of threadId.
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 and resource: 'Continue or step an attached ABAP debuggee.' This clearly identifies the tool's function and distinguishes it from sibling debug tools like sap.debug.variables or sap.debug.stack.
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 tool versus alternatives. It does not mention prerequisites such as an active debug session, nor does it contrast with breakpoint or evaluation tools.
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?
The description adds minimal behavioral context beyond what annotations already provide. It mentions 'switch or create' but does not explain destructive implications (e.g., overwriting local changes) or authentication requirements. The annotations indicate destructiveHint=true, but the description lacks elaboration.
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 concise (one sentence) and front-loaded, but it is under-specified for a tool with five parameters and complex semantics. Every word is necessary, but the brevity undermines clarity.
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 (5 parameters, 4 required, no enums, output schema present), the description is too brief. It does not explain what 'confirmed' means, what the 'branch' parameter expects, or any additional context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter descriptions exist. The tool description does not mention or explain any of the five parameters (e.g., branch, systemId, confirmation, createBranch, repositoryId), failing to add meaning beyond the input 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 verb ('Switch or create') and the resource ('abapGit branch'), distinguishing it from sibling tools like 'sap.git.create' or 'sap.git.pull'. The qualifier 'confirmed' adds specificity.
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 switching or creating a branch but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative recommendations are given.
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?
Annotations already declare the tool as read-only, non-destructive, and idempotent, so the description does not need to repeat those facts. The description adds minimal behavioral context, only noting the system-level nature of the check. It does not explain side effects, result handling, or runtime characteristics, but given the strong annotation coverage, a neutral score is appropriate.
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 a single, tightly worded sentence with no fluff or repetition. It conveys the core purpose efficiently. While it is under-specified for a complex tool, this dimension rewards conciseness, and the sentence earns its place by clarifying the tool's scope.
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?
Despite having an output schema and relatively complete annotations, the description leaves major gaps for correct invocation. It does not explain how to specify the target object (URI vs name/type), what systemId refers to, or why limit and startIndex are needed. For a tool with six undocumented parameters, this description is incomplete for an agent to reliably decode and use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates for none of the 6 parameters. The only hint is 'one exact object,' which vaguely relates to objectUri/objectName/objectType but does not explain their format, requiredness, or interplay. Parameters like limit, startIndex, and systemId are completely undocumented in both schema and description.
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 action as running an ATC check variant for a single object. The verb 'Run' and the specific resource 'system ATC check variant' make the primary function explicit. However, it does not explicitly distinguish this from sibling tools like sap.quality.atc.cached or sap.quality.atc.documentation, though the phrase 'one exact object' partially narrows the scope.
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?
Usage context is implied by the phrase 'for one exact object,' suggesting this tool is intended for single-object analysis rather than batch or aggregate queries. There is no explicit guidance on when to choose this tool over alternatives, nor any exclusion criteria. The context is clear enough to hint at a focused invocation but lacks explicit direction.
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?
The annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the bar is lower. The description adds 'optional ADT structure' and 'bounded child-node page,' which is useful, but it does not go into details about pagination behavior, enhancements, or what happens when the optional flags are disabled. No contradiction exists.
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 a single front-loaded sentence with no filler and wastes no words. It earns its place, but it is terse enough that some required operational detail is missing, which is a structural trade-off rather than purely efficient conciseness.
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 9-parameter schema and 0% schema property coverage, this description is not complete. It describes the high-level read behavior and hints at structure and children options, but required fields and several flags like includeEnhancements and includeEnhancementSource are left unaccounted for in the natural language guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries most of the parameter-semantics burden. It only hints at includeStructure and child paging; it does not explain systemId, objectName, objectType, includeEnhancements, includeEnhancementSource, or how childLimit and childStartIndex work together.
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 and resource: it reads repository object metadata, optional ADT structure, and a bounded child-node page. This is clear enough to infer the tool's focus, but it does not explicitly differentiate from sibling tools such as sap.repository.search or sap.source.read, so it stays just short of a 5.
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?
There is no guidance about when to prefer this tool over alternatives, no exclusions, and no conditions such as 'for source code use X'. The only usage signal is inferred from the verb 'Read' and the title, which is not sufficient guidance for tool selection.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint: false, so the safe read-only nature is covered. The description adds only 'through SAP ADT trace services' as extra behavioral context, which is minimal. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff or redundancy. It is concise and front-loaded, but arguably too terse to serve as functional guidance.
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?
Despite accurate annotations and an output schema, the description lacks critical usage context. It doesn't differentiate from sibling trace tools, doesn't explain when to use it, and gives no parameter semantics. The tool's complexity demands more than one sentence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no explanations for the 5 parameters (systemId, traceId, limit, startIndex, includeDetails). The only implicit hint is that a trace is involved, but this is far from sufficient.
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 a read operation on ABAP Trace Statements via SAP ADT trace services, using a specific verb and resource. It does not explicitly distinguish from sibling trace tools like sap.runtime.trace.hit_list or sap.runtime.trace.inspect, but 'statements' is a distinct resource.
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 given on when to use this tool versus alternatives such as sap.runtime.trace.list or sap.runtime.trace.inspect. The description neither mentions prerequisites (e.g., needing a traceId) nor exclusions/alternatives.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the domain (ABAP formatting) but does not disclose additional behavioral traits such as output format, system requirements, or potential errors. Description does not contradict annotations.
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 a single sentence with no extraneous information. It is concise and front-loaded, but it sacrifices necessary detail for brevity.
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 (2 required parameters, output schema present but not described), the description is insufficient. It does not explain what the preview returns or how to interpret the results. The agent lacks context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must clarify parameters. However, the description does not explain 'fileUri' or 'systemId' beyond their names. The agent cannot infer their meaning or usage from the description alone.
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 'Preview SAP ABAP formatter changes' clearly states the verb (preview) and resource (ABAP formatter changes). It differentiates from siblings like sap.refactor.preview and sap.execution.preview by specifying ABAP formatting, though not explicitly. A more detailed purpose would be needed for full clarity.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or when not to use it. The agent has no guidance on tool selection.
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?
The description adds minimal behavioral context beyond what annotations already declare. Annotations state readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description does not disclose edge cases, pagination, or output behavior. The phrase 'one SAP repository object' is mild scope limitation but not significant.
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, focused sentence that clearly states the operation. Every word contributes value, with no redundancy or filler.
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 has 7 parameters, an output schema, and many sibling tools, the description is too sparse. It lacks parameter semantics, usage context, and any explanation of how the resolution works, making it insufficient for an agent to invoke it correctly without additional inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of any of the 7 parameters (systemId, pgmid, objectType, objectName, limit, startIndex, transportNumber). With 0% schema description coverage, the description must compensate but does not, leaving these parameters entirely undocumented.
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 'resolve' with a clear resource 'SAP repository object' and output 'transport key', distinguishing it from sibling tools like sap.transport.object.add or sap.repository.resolve. The scope of one object is also explicit.
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 usage guidance is provided. The description does not mention when to use this tool versus alternatives such as sap.transport.object.add or sap.repository.resolve, nor any preconditions, exclusions, or context for selection.
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?
Annotations indicate readOnlyHint=false, so the tool is known to mutate state. The description adds no further behavioral context, such as whether a debug session must be active, whether breakpoints persist, or what runtime effects setting a breakpoint may have. It merely restates the action without adding transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse and immediately communicates the core function. It does not waste words, though it may be too minimal, which affects other dimensions rather than conciseness.
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 (4 parameters, no parameter descriptions) and the existence of an output schema, the description is insufficiently complete. It does not explain the meaning of systemId or fileUri, the role of condition, the requirement for lineNumbers, or what the result/response signifies. It only provides basic purpose without operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (fileUri, systemId, lineNumbers, condition). It only says 'for one ADT source Resource', which does not clarify parameter meanings, formats, or relationships. The description fails to compensate for the lack of 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 'Set ABAP Debug Breakpoint for one ADT source Resource' clearly states the action (set), the resource (ABAP Debug Breakpoint), and the scope (one ADT source resource). It effectively distinguishes from sibling tools like sap.debug.breakpoint.remove and other debug tools.
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: it is used when you want to set a breakpoint on an ADT source. However, it provides no explicit guidance on when to use this tool versus alternatives such as sap.debug.breakpoint.remove or sap.debug.session.start, and there are no exclusions or alternative mentions.
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?
The description adds little beyond annotations, only noting the stateful ADT debug client mechanism. It doesn't disclose side effects such as session termination details or whether resources are released. Since readOnlyHint=false already indicates a write operation, the description provides minimal additional behavioral context.
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 a single, clear sentence with no redundant content. It's appropriately front-loaded but sacrifices detail for brevity, which is acceptable for a simple stop action yet leaves room for more informative phrasing.
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?
Despite having an output schema, the description lacks guidance on required parameters (systemId) and doesn't explain the function's effect on the debug session. In the context of many sibling debug tools, a bit more context on when to invoke stop would help, but it remains a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention any of the three parameters (systemId, debugUser, terminalMode). The tool name and description alone do not clarify parameter meaning or usage, offering no compensatory 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 clearly states a specific verb ('Stop') and resource ('ABAP Debug Session'), effectively distinguishing it from sibling debug tools like sap.debug.session.start and sap.debug.session.inspect. The addition of 'through the stateful ADT debug client' gives technical context.
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 ending a debug session but does not explicitly state when to use it versus alternatives or mention any prerequisites. With sibling tools like sap.debug.status and sap.debug.session.inspect present, explicit guidance would improve clarity.
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?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds the scope 'from one attached debug stack frame', which clarifies the operation's target. However, it does not disclose behavioral details such as pagination, filtering, or expansion options that the schema parameters imply, nor any performance or authorization considerations.
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 a single, grammatically simple sentence with no wasted words. It is front-loaded with the verb and resource. However, its extreme brevity limits its informativeness; while structurally clean, it lacks the detail needed for a tool with this many parameters.
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 (11 parameters, many sibling debug tools) and the existence of an output schema, the description is insufficient. It does not cover filtering, expansion, pagination, or use cases, and it relies entirely on the schema for parameter names without explaining behavior. The output schema clarifies return values, but the description's minimalism leaves significant gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does nothing to explain the 11 parameters. It only says 'read variables' without describing what parameters like filter, rowCount, expandTables, or scopeName do. The description fails to compensate for the schema's lack of documentation, leaving the agent to guess the meaning and relationship of the parameters.
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 action ('Read') and the resource ('variables from one attached debug stack frame'), which distinguishes it from sibling tools like sap.debug.stack (which lists frames) and sap.debug.evaluate (which evaluates expressions). It is specific and unambiguous about the tool's core purpose.
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?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. A user/agent is left to infer that this reads variables from a debug stack frame, but there is no context about typical use cases or when to prefer it over other debug tools like sap.debug.evaluate.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds 'Check' which aligns with read-only, but no additional behavioral traits beyond what annotations provide.
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?
Single sentence of 9 words, no redundancy. Could be slightly longer to add value without losing conciseness.
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?
Tool is simple with one parameter and output schema exists. Description does not explain return values or edge cases, but annotations cover safety. Adequate but leaves room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage for the only parameter systemId. Description does not explain what systemId represents or how to format it, leaving agents without sufficient context.
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?
Description clearly states verb 'Check' and resource 'configured ABAP REPL execution capability', distinguishing it from similar tools like execution.execute or execution.preview. However, 'configured ABAP REPL execution capability' is somewhat vague.
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 explicit guidance on when to use this tool versus alternatives like sap.execution.execute or sap.execution.preview. No mention of prerequisites or exclusions.
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?
Annotations already indicate destructiveHint=true and readOnlyHint=false; description adds context about 'confirmed staged', implying a safe state before destructive action. However, it does not explain consequences like overwriting remote or rollback possibilities.
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?
Single sentence is concise but lacks structure. No front-loading of key info beyond the basic action. Could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, 5 required, and no parameter descriptions in schema or description, the tool is severely underspecified. The description omits output schema details and usage flows, making it incomplete for reliable agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it mentions no parameters. The meaning of systemId, repositoryId, stageId, comment, confirmation, etc. is left entirely to the schema names, which is insufficient for an agent.
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 specifies the verb 'Push', resource 'abapGit snapshot', and condition 'confirmed staged'. This differentiates from sibling tools like sap.git.stage (staging) and sap.git.pull (pulling).
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?
Implies use after staging and confirmation ('confirmed staged'), but provides no explicit guidance on when to use vs. alternatives (e.g., sap.git.pull) or prerequisites. Lacks clear when-not-to-use instructions.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds the context 'through the in-process SAP watch service', but does not disclose any additional behavioral traits.
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 a single sentence of 11 words, achieving conciseness. It is front-loaded with the key action and resource, though it lacks structure like bullet points or additional sections.
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 has 3 parameters with no description coverage and an output schema, the description fails to explain pagination or the effects of includeDetails. The agent lacks context to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention any of the three parameters (limit, startIndex, includeDetails). The agent must infer their meaning solely from names and schema defaults, which is insufficient.
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 the verb 'List' and the resource 'SAP Watch Tasks', clearly identifying the tool's function. It distinguishes it from sibling tools like add, remove, update, etc.
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 tool versus alternatives. There is no mention of scenarios, prerequisites, or that it returns a paginated list.
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?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safe, read-only nature is clear. The description adds no extra behavioral context beyond 'Check', such as what occurs if the generator is unavailable or if the system is not configured. Given strong annotations, the bar is lower, and the description does not contradict them, so a baseline 3 is appropriate.
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, front-loaded sentence with no filler. Every word contributes to stating the action and target. It is appropriately concise for a simple check operation, though other dimensions suffer from lack of detail.
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?
The tool has only two parameters and an output schema, but the description is minimal. It doesn't explain what the result looks like (though output schema may cover that), nor does it mention error conditions, prerequisites beyond 'configured system', or how this fits into the RAP workflow. For a simple tool it might be borderline sufficient, but given the large sibling list, more context would help agents select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not. The parameter names systemId and generatorId are somewhat self-explanatory, but the enum values (uiservice, webapiservice) are not explained in either the schema or the description. No additional meaning is added beyond the schema's basic type and constraint information.
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 'Check one RAP generator on a configured SAP system' clearly identifies the action (check) and the resource (RAP generator), and distinguishes from siblings like sap.rap.generate (which generates) and sap.rap.validate (which validates). However, it could be more explicit about 'availability' as the title states, and it doesn't clarify what 'check' means in terms of output.
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?
The description provides no guidance on when to use this tool compared to alternatives. It implies a prerequisite that the system must be configured, but there is no mention of scenarios like 'use before generating' or 'if you want to check generator availability, use this instead of sap.system.capabilities.' No exclusions or alternative recommendations are given.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the tool's non-destructive nature is clear. The description adds the term 'bounded' but does not elaborate on behavior beyond what annotations 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 a single sentence with no fluff, front-loading the main action. While concise, it could benefit from brief parameter hints without becoming verbose.
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?
Despite having an output schema, the description is too sparse for a list tool with four parameters and no schema descriptions. It omits pagination details (limit, startIndex) and the meaning of 'bounded'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the four parameters (systemId, fileUri, limit, startIndex). It adds no meaning beyond the schema structure.
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 clearly identifies the resource as 'bounded ABAP class or interface components', distinguishing it from sibling tools like 'sap.semantic.definition' or 'sap.semantic.documentation'.
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 tool versus alternatives, nor any context like prerequisites or limitations. The description only states what it does.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds minimal behavioral context (e.g., 'historical revisions' implies it returns a list of past versions) but does not disclose pagination behavior, limits, or relationship to inactive versions. 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?
The description is a single, clear sentence with no filler. It is front-loaded with the verb and object, making the primary purpose immediately apparent. 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?
For a tool with 8 parameters and zero schema descriptions, the description is insufficiently complete. It does not explain how multiple pagination parameters interact, what objectType means, or how maxVersions relates to the returned list. An output schema exists but does not compensate for the lack of parameter semantics and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, placing the burden on the description. The only hint is 'for one object', which loosely maps to objectName, but the other seven parameters (limit, lineCount, startLine, objectType, startIndex, maxVersions, systemId) remain unexplained. This provides almost no semantic aid beyond the schema field names.
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 the action ('List') and the resource ('historical revisions for one object'), making the basic purpose evident. However, it does not differentiate from sibling tools like sap.version.history.read or sap.version.inactive.list, which could overlap semantically.
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?
The description provides no guidance on when to use this tool versus alternatives such as sap.version.history.read or sap.version.history.compare. There is no mention of prerequisites, exclusions, or scenarios where this tool is preferred.
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?
Annotations already declare the tool as read-only, idempotent, and non-destructive, so the bar is lower. The description adds the behavioral nuance of 'bounded' (range-limited), but does not disclose edge cases, limits, or semantics beyond the schema constraints.
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 sentence with no redundant words. It front-loads the core action and scope, making it highly efficient.
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?
For a tool with seven parameters and no schema descriptions, the one-sentence description is insufficient. It lacks context about how the range parameters interact, what 'bounded' concretely means, and how this relates to sibling tools like sap.version.inactive.list. The output schema covers return format, but usage context remains thin.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the seven parameters. 'Bounded range' vaguely implies start/limit parameters but does not clarify the roles of startLine, lineCount, limit, or startIndex, leaving the agent to infer from parameter names alone.
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 the tool reads an inactive-source range with a bounded scope, using a specific verb and resource. It distinguishes from active-source reads via 'inactive' and from full-version reads via 'bounded', though it does not explicitly name alternative tools.
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 tool versus alternatives like sap.source.read or sap.version.history.read. The description implies a specific scope but offers no contextual conditions or exclusion criteria.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description only confirms 'without changing SAP source', adding minimal value beyond annotations. No additional behavioral traits (e.g., auth needs, side effects) are disclosed.
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?
A single sentence efficiently communicates the core purpose without waste. It is front-loaded and scannable.
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?
Despite having an output schema, the description lacks parameter explanations and usage context. Given the tool's complexity (13 params, various refactoring kinds), the description is insufficient for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of parameters. With 13 parameters, the agent must rely solely on the names and types, which is inadequate for correct invocation.
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 previews an ABAP refactoring plan without changing source. The verb 'preview' and resource 'ABAP refactoring plan' are specific. It distinguishes from sibling 'sap.refactor.execute' by noting no changes.
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 previewing refactorings but does not explicitly state when to use versus alternatives like 'sap.refactor.execute'. No when-not-to-use guidance is provided.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds only the service mechanism ('ADT trace services') but no additional behavioral details like pagination limits or response structure. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is concise, but it adds only the phrase 'through SAP ADT trace services' beyond the title, which is slightly redundant. Still, it earns a high score for brevity.
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 presence of an output schema and annotations reduces the need for the description to explain return values or safety. However, the description is minimal and does not provide context on how listing works, pagination, or when to adjust parameters like limit and startIndex. It is adequate for a simple list tool but lacks richer contextual guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about any of the four parameters. Schema description coverage is 0%, so the description fails to compensate for the schema's lack of semantic context. The parameter names are self-explanatory to some degree, but the description adds zero value 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 action ('List') and the resource ('ABAP Traces'), and specifies the mechanism ('through SAP ADT trace services'). This distinguishes it from sibling trace tools like inspect, hit_list, or configuration.
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 about when to use this tool versus alternatives. It does not mention scenarios for listing traces, nor does it exclude cases better suited to other trace-related tools such as sap.runtime.trace.inspect or sap.runtime.trace.hit_list.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering safety. The description adds 'bounded non-dialog', which implies pagination (via limit/startIndex) and no interactive prompts—useful behavioral context beyond annotations. However, it does not describe response structure or error 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?
The description is a single, front-loaded sentence with no redundant words. Every word contributes: 'List' states the action, 'bounded' and 'non-dialog' add important scope, and 'SAP quick fixes' names the resource.
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?
With 6 parameters and no schema descriptions, the description is too sparse to fully guide an agent on how to use the tool. The output schema and annotations cover safety and return shape, but the description should clarify what a quick fix is and how location parameters like line, column, and startIndex relate. The qualifiers 'bounded' and 'non-dialog' are helpful but insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain any of the 6 parameters. It does not compensate for the lack of parameter descriptions in the schema. The parameter names are somewhat self-explanatory, but the description adds no meaning beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'List' and the resource 'SAP quick fixes', making the tool's purpose clear. The qualifiers 'bounded' and 'non-dialog' add scope and help distinguish it from sibling semantic tools like sap.semantic.complete or sap.semantic.documentation.
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?
There is no guidance on when to use this tool versus alternatives. It does not mention file positions, system context, or related semantic tools, leaving the agent without context for selection.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, establishing the safety profile. The description adds the concept of 'bounded change-assurance checks' and the scope of 'one transport', which provides some context beyond annotations but does not elaborate on limits, side effects, or operational nuances.
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 concise sentence with no superfluous words, immediately stating the tool's purpose and scope. It is well-structured and front-loaded, making it easy to parse quickly.
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?
Despite a complex 10-parameter schema and an output schema, the description offers only a high-level purpose. It lacks details on parameter meanings, usage scenarios, or what the checks entail, making it insufficient for an agent to fully understand the tool's capabilities and invocation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no information about any of the 10 parameters. There is no explanation of what parameters like limit, checks, maxObjects, or startIndex mean or how they relate to the checks, leaving the agent to rely solely on parameter names and defaults.
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 'Run' and identifies the resource as 'one transport', with 'bounded change-assurance checks' clearly distinguishing it from sibling tools like sap.transport.inspect or sap.transport.compare. This makes the tool's primary function immediately understandable.
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 explicit guidance is given on when to use this tool versus alternatives such as sap.quality.atc.run or sap.transport.inspect. The description does not mention any preconditions, exclusions, or scenarios where other tools would be more appropriate, leaving the agent to infer usage solely from the name and context.
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?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. However, the description adds no extra behavioral context, such as what the comparison output looks like, what happens if transport numbers are invalid, or how pagination works with limit and startIndex.
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?
A single sentence that is extremely concise and to the point, with no superfluous 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?
Despite having an output schema, the description is too minimal. It does not explain what the comparison returns (e.g., differences, list of changes) or how to interpret results, leaving the agent with insufficient context for a multi-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description should clarify each parameter. It only hints at the 'transportNumbers' array size (2 to 10) but does not explain 'systemId', 'limit', or 'startIndex' role in pagination or filtering.
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 verb 'compare' and the resource 'transport requests', specifying the range of 2 to 10, which distinguishes it from sibling transport tools like sap.transport.inspect, sap.transport.list, and sap.transport.create.
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 tool versus alternatives such as sap.repository.compare or sap.transport.inspect. There is no mention of prerequisites or when not to use it.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, which cover the safety profile. The description adds the notion of validation but offers no additional behavioral details, such as what happens on validation failure, whether it returns a report, or any side effects. It does not contradict 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and easy to read. However, given the tool's complexity, the extreme brevity borders on under-specification rather than conciseness, but it does not contain fluff.
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?
This is a complex tool with 8 parameters, nested objects, and an output schema. The description provides nearly no contextual information beyond the basic purpose. It doesn't explain what 'generated content' refers to, how validation works, or what the expected inputs and outputs are. Even with the output schema available, the description is insufficient for an agent to understand when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for explaining the parameters. It does not. The one-sentence description offers no explanation for systemId, generatorId, referenceObjectName, packageName, content, length, offset, or referenceObjectType. The nested 'content' object is especially complex and completely unexplained. Parameter names hint at some semantics, but the description adds no 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 clearly states the tool's purpose: 'Validate RAP initial inputs and optional generated content.' The verb 'Validate' is specific, and the resource is clearly identified as RAP-related inputs/content. This distinguishes it from sibling tools like sap.rap.generate and sap.rap.binding.publish.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any preconditions, typical workflows, or exclusions. For example, it doesn't say whether to use this before sap.rap.generate or after sap.rap.generate, or how it differs from sap.rap.availability.
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?
Annotations already mark it as idempotent, non-destructive, and not read-only. The description adds the constraint of same-system and the limit of 100 resources, but does not disclose further behavioral traits like activation consequences 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the key action and constraints. However, it is perhaps too terse and could benefit from a sentence about parameter semantics or usage.
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 has an output schema and two parameters with 0% schema coverage, the description fails to explain activation context, prerequisites, or distinguish among many sibling tools. Significant gaps remain for an agent to use this tool properly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so parameters are undocumented. The description partially explains 'resourceUris' by stating 'one or up to 100 ABAP Resources', but leaves 'systemId' completely unexplained. No added detail beyond the schema's structural constraints.
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 verb 'Activate' and the resource 'ABAP Resources' with constraints: 'one or up to 100' and 'same-system'. This distinguishes it from siblings like sap.source.diagnose or sap.source.read_batch, which have 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context about prerequisites or when not to use it. The description only states what it does, not when it should be chosen over other tools like sap.source.patch or sap.execution.execute.
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 meaningful context by breaking down capabilities into 'implemented, advertised, authorized, and observed,' which goes beyond what annotations provide. No contradiction is present here.
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, well-structured sentence that immediately states the verb and object. Every word earns its place, no filler, and the key qualifiers are packed efficiently.
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?
Although an output schema exists and annotations cover safety, the description fails to clarify the meaning of 'category' or the role of 'includeEvidence.' These are likely important for selecting and invoking the tool correctly. The description is adequate for the main purpose but leaves notable gaps in understanding optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameter. It only hints at 'one SAP system' for systemId but says nothing about the category enum or includeEvidence. This forces the agent to guess parameter meanings, especially includeEvidence, which is not self-explanatory.
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 is clear: 'Read implemented, advertised, authorized, and observed capabilities for one SAP system.' It uses a specific verb and identifies the resource (capabilities of one system) with useful qualifiers. It does not explicitly distinguish it from sibling tools like sap.system.inspect or sap.system.list, but the resource is sufficiently distinct.
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?
There is no guidance on when to use this tool versus alternatives. The description simply states what it reads, with no mention of scenarios, prerequisites, or exclusions. With many sibling tools available, the lack of usage direction leaves the agent to infer appropriate contexts.
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?
Annotations indicate the tool is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false). The description confirms a write operation, but provides no additional behavioral context such as idempotency, prerequisites, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no redundant information. It could be slightly more structured but remains effective and quick to parse.
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 no parameter descriptions and an output schema that is not explained, the description is insufficient for the agent to use the tool correctly. The agent lacks key context about valid input values and expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 6 parameters are required and have no descriptions in the schema (0% coverage). The description does not explain any parameter, leaving the agent to guess meanings, especially for 'pgmid' and 'confirmation'.
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 adds a confirmed repository or subobject key to a transport, using specific verbs and nouns. It distinguishes from sibling tools like transport.create or transport.delete.
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 explicit guidance on when to use this tool versus alternatives. The description only states the basic function, leaving the agent to infer context from the tool's name and 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?
Annotations already indicate write operation (readOnlyHint=false). Description adds the condition 'after exact confirmation' but does not elaborate on side effects or other behavioral traits 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action and resource. Very concise, but could benefit from slightly more detail without losing conciseness.
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?
Despite having an output schema, the description lacks essential context for correct usage (e.g., meaning of confirmation, targetUser restrictions). Not sufficient to use the tool correctly without external documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the main description provides no explanation for any parameter. The 4 required parameters (systemId, transportNumber, targetUser, confirmation) are left completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action (Set) and resource (SAP Transport Owner) with condition (after exact confirmation). Distinct from sibling tools like sap.transport.release or sap.transport.create.
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?
Implies usage after exact confirmation but does not specify when to use versus alternatives or exclude other conditions. No explicit guidance.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds that the tool builds a URL, consistent with these hints, but offers no further behavioral context (e.g., network calls, auth needs).
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?
A single, focused sentence with no filler. Every word carries meaning, and the length is appropriate for the tool's straightforward purpose.
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 is adequate for a simple URL builder, but it omits details like whether the output is a full URL, how the objectType affects the URL, or if systemId must be a known system. The presence of an output schema partially compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no elaboration on parameters. Names like systemId, objectName, and objectType are self-explanatory but the description adds no extra meaning or constraints 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 uses a specific verb 'Build', identifies the resource 'SAP WebGUI URL', and scopes to 'one ABAP object'. It clearly distinguishes the tool from siblings, which focus on other operations like activation, inspection, or transport.
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 tool versus alternatives, nor any conditions or prerequisites. The agent is left to infer the appropriate context without explicit direction.
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?
Annotations already indicate the tool is not read-only and not destructive. The description adds that it validates code before creating, which is a positive behavioral disclosure. However, it does not detail what happens on validation failure, or if the tool modifies any state beyond creating the artifact.
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 sentence with no wasted words. It conveys the core purpose efficiently.
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?
Despite having an output schema, the description is too minimalistic for a tool with 3 parameters (including enums and defaults). It does not explain the error handling (what happens if Mermaid code is invalid), nor does it clarify the relationship between parameters and the created artifact. The tool's behavior regarding file creation or overwriting is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema lacks descriptions for all 3 parameters. The description does not explain the role of the parameters (e.g., that 'code' is the Mermaid code, that 'theme' and 'diagramType' are optional with defaults). This forces the agent to infer meaning from parameter names and enums, which is insufficient.
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 validates Mermaid code and creates an interactive local HTML artifact. It uses a specific verb 'validate' and 'create' and identifies the output as an interactive local HTML artifact. Among siblings, no other tool creates Mermaid artifacts, making it distinct.
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?
The description provides no guidance on when to use this tool versus alternatives, nor any conditions or prerequisites. There is no mention of when not to use it or any context about required setup (e.g., network, permissions).
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety contract is covered. The description adds one behavioral fact beyond those: the tool operates 'through an opt-in same-origin classic bridge,' implying an enabling prerequisite — but it doesn't say the bridge must how it affects calls or error behavior when not enabled. This matches the pattern where annotations carry the safety profile and the description adds partial constraint context 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently worded sentence with the verb and resource front-loaded before the mechanism qualifier. Every phrase contributes — though being 'opt-in same-origin classic bridge' is dense, jargon-laden, and could be clearer for an agent, it is not filler. The title reinforces the artifact without duplicating the full sentence, staying tight.
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?
Given the low complexity (zero parameters), rich annotations, and presence of an output schema, the description does not need to explain return formats. But it leaves important gaps: how the tool selects which screen/GUI status to read with no parameters, what 'opt-in same-origin' requires of the caller, and how failures manifest when the bridge is unavailable. An agent could call it correctly but would be blind to the mechanism prerequisite.
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 tool has 0 parameters, so the schema provides no semantics to clarify; per the rubric, a 0-parameter tool gets a baseline of 4. The description names the target artifact types (Screen/Dynpro or GUI Status) which is the only relevant meaning an agent needs. Nothing is missing here from a parameter-class documentation it implies how the target is selected, no parameter-level deficit.
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 title and description name a specific verb ('Read') and resource ('Screen/Dynpro or full GUI Status document'), which clearly identifies a distinct artifact type on the SAP side. This artifact is not targeted by any sibling, including sap.source.read, sap.ddic.read, and sap.text_elements.read. However, the phrase 'opt-in same-origin classic bridge' is jargon that obscures what exactly is read and what the bridge is, keeping this short of a 5.
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?
The description gives no guidance on when to use this tool versus alternatives such as sap.classic.write, sap.source.read, sap.ddic.read, or sap.text_elements.read. It also never states the implied prerequisite — the opt-in bridge must be enabled — nor what context is required (the 0-parameter schema offers no selection). An agent cannot determine from this text when it is the right tool.
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?
The annotations already communicate that the tool is non-read-only and destructive; the description adds the 'optimistically' concurrency behavior and clarifies which ABAP object graph is affected. However, it does not explain conflict handling, activation side effects, or whether the previous source is preserved. The bar is lowered by the annotations, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no filler. It clearly names the action and resource types without repeating the title or generic update language. Every word carries functional meaning.
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?
For a destructive update/write tool, the description omits crucial invocation context: how the target Domain/Data Element/Table/Structure is identified when the schema has zero parameters, what prerequisites exist, what the optimistic conflict outcome is, and what the response represents. The output schema, while present, cannot compensate for missing guidance on target selection and destructive mutation behavior.
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 zero properties, and schema coverage is 100%, so there is nothing for the description to disambiguate at the parameter level. The baseline for zero parameters is 4. No parameter documentation is needed for this dimension, though the missing target-object mechanism becomes a contextual completeness concern.
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 names a concrete action ('optimistically replace') and a precise ABAP Dictionary resource set (Domain/Data Element properties or Table/Structure DDL source), which clearly separates it from sap.ddic.read. It is not a tautology or vague restatement, though it does not explicitly differentiate itself from similar write tools like sap.source.patch or repository update tools.
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?
There is no guidance on when to use this tool versus alternatives such as sap.repository.create, sap.source.patch, or sap.repository.delete. The verb 'replace' only implies updating existing objects, but no explicit conditions, exclusions, or sibling-tool references are provided. An agent must infer usage from the tool name rather than from the description.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the requirement of an 'attached debug stack frame,' which is a useful behavioral precondition, but it does not disclose what happens when no frame is attached or how the expression is evaluated (e.g., side effects on debugger state). With annotations carrying the safety burden, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loading the core action and resource. It is appropriately concise for a tool with a clear purpose, though the brevity contributes to the lack of parameter guidance.
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?
Despite the presence of an output schema and annotations, the tool has 11 parameters with zero description coverage and no usage context. The description does not explain how to obtain the required frameId, what an 'attached debug stack frame' means, or how this tool fits within the larger debug workflow (e.g., after sap.debug.stack). This is insufficient for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate, but it only implicitly references the 'expression' parameter. The other 10 parameters (systemId, frameId, filter, rowCount, etc.) are completely unexplained, leaving the agent without semantic meaning for required inputs beyond their bare schema types.
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 action ('Evaluate one expression') and the resource ('attached debug stack frame'), distinguishing it from sibling debug tools like sap.debug.variables (which lists variables) and sap.debug.stack (which shows stack frames). The verb and scope are specific and unambiguous.
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?
The description provides no guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. It does not mention that a debug session must be active or how to obtain a valid frameId, leaving the selection decision to the agent without context.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds 'bounded page' context, but does not disclose caching behavior, error handling, or ordering.
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 sentence with no filler. Every word is necessary 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 no parameter descriptions in the schema, the description should cover parameter semantics and caching context. It does neither. The output schema exists but is not referenced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain parameters. It only implies pagination via 'bounded page', but does not clarify the roles of 'limit', 'startIndex', or 'fileUri'. The parameters are left ambiguous.
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 verb 'Read' and the resource 'cached ATC findings', with 'bounded page' indicating pagination. It distinguishes this tool from siblings like 'sap.source.read_batch' and 'sap.quality.test_include.create' by focusing specifically on cached ATC findings.
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 tool versus alternatives. While the description implies it's for reading paginated cached findings, it does not explain when pagination is needed or how it compares to other read tools.
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?
Annotations already indicate destructive behavior. The description adds the 'fresh' constraint but does not expand on side effects or required authorizations beyond what annotations provide.
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?
A single sentence that is front-loaded with the core action. No extraneous words.
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?
Given the existence of an output schema and annotations, the description is minimally complete. However, it leaves ambiguity about parameter values and the 'fresh' requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description should explain parameter meaning. It loosely maps 'planId' and 'confirmation' to the plan and confirmation concept but lacks specifics on expected values (e.g., format of confirmation string).
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 the action (execute) and resource (object-deletion plan), and implicitly distinguishes from the preview sibling. However, it doesn't elaborate on what 'fresh' means.
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 that the tool should be used after previewing and confirming a plan, but it does not explicitly state when not to use it or list alternatives among 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?
Annotations already declare the tool read-only, idempotent and non-destructive, so the description does not need to restate that. 'Bounded... page' adds a small behavioral hint about pagination, but the description does not disclose feed edge semantics, ordering, or how from/to may partition pages.
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 one compact sentence with no filler and front-loads the core action. It earns its place by clarifying both the page semantics and the feed topics, even though parameter-level detail is absent.
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?
For a 7-parameter tool with zero schema descriptions and an output schema, the description is under-specified. It does not explain the pagination contract, what the returned feed records represent, or how required fields like systemId interact with feed categories.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden, but it only paraphrases the kind enum values and does not explain systemId, from, to, user, limit, or startIndex. An agent would still need to guess the meaning of the feed cursor and pagination parameters.
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 states a clear verb ('Read') and a specific resource ('bounded ADT feed page'), and explicitly enumerates the four feed categories that map directly to the kind enum. This distinguishes it from sibling runtime tools such as dump/trace read tools, whose object differs.
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?
The description gives no guidance on when to use this tool over alternatives, nor does it name any sibling tool or exclusion condition. It only implies use through the feed categories; for 7-parameter tool with many similar runtime siblings, that is too little.
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?
Annotations already indicate a destructive, non-idempotent operation, and the description doesn't contradict them, but it also doesn't detail side effects such as overwrite behavior or file system impact. With annotations present, this is acceptable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, clear sentence with no redundant information.
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?
With six parameters and no parameter documentation, the description is insufficient to understand how to use the tool fully; the output schema exists but is not referenced in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameter descriptions, and the tool description only hints at source/target semantics; systemId, objectType, overwrite, and includeFileList remain unexplained.
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 a specific action (Download) targeting an ABAP object or package to an absolute local folder, distinguishing it from sibling read/search tools.
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 choose this tool over alternatives like sap.source.read or sap.data.export; no usage context or exclusions are mentioned.
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?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds the context that the transaction must be validated, which is useful, but does not disclose error behavior, validation steps, or return format beyond what annotations provide.
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, front-loaded sentence with no extraneous words. It immediately conveys the tool's purpose and scope.
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?
Despite having rich annotations and an output schema, the description lacks critical details about parameter semantics and tool behavior in context. The nested 'parameters' object and systemId are unexplained, making the description insufficient for a tool with 0% schema coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description does not explain any of the three parameters. It only refers to the transaction implicitly, leaving the meaning of systemId and the 'parameters' object completely undocumented.
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 builds a SAP Transaction URL using the specific verb 'Build' and defines the resource and scope ('for one validated SAP transaction'). It distinguishes from sibling tools like sap.ui.transaction_launch by focusing on URL generation rather than launching.
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 the tool is used when a URL for a validated transaction is needed, but it does not explicitly mention when to prefer this tool over alternatives or include any exclusions. No alternative tools are referenced.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the 'bounded page' behavior, which is useful, but does not disclose pagination mechanics or edge cases. This is acceptable given the annotation coverage.
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 sentence that is direct and front-loaded. Every word contributes to meaning, with no redundancy or filler.
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?
Despite having an output schema and annotations, the description is too sparse for a tool with 7 parameters. It does not clarify what 'inactive objects' means, how pagination parameters relate, or when to use this over related list/read tools. The description leaves too much to be inferred.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not—only 'bounded page' hints at limit/startIndex, but filters like objectName/objectType and systemId are unexplained. The schema names are self-evident but lack semantic depth.
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 'List a bounded page of inactive objects' clearly identifies the verb (list), resource (inactive objects), and scope (bounded page/pagination). It differentiates from siblings like sap.version.inactive.read (singular read) and sap.version.history.list (history list).
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 tool versus alternatives (e.g., sap.version.inactive.read or sap.version.history.list). There are no prerequisites, exclusions, or contextual hints beyond the bare description.
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, providing strong safety guarantees. The description adds specificity about what is read (listener, debuggee, breakpoint state), which is useful 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?
The description is a single sentence that immediately conveys the tool's purpose, with no unnecessary words. It is perfectly concise.
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 covers the core purpose but lacks parameter explanation and usage context. An output schema exists but is not shown; the description does not need to detail return values, but missing parameter info leaves a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (systemId) with 0% description coverage in the schema. The description does not mention the parameter at all, leaving the agent without guidance on its meaning.
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 reads ABAP debug status, specifically listener, debuggee attachment, and breakpoint state. The title confirms 'Read ABAP Debug Status'. This distinguishes it from sibling tools like sap.execution.execute or sap.ops.watch.status which focus on execution or monitoring.
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?
The description provides no guidance on when to use this tool vs alternatives, nor any prerequisites or context. It simply states what it reads.
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?
Annotations already indicate this is a non-read-only, non-idempotent, open-world operation with no destructive potential, but the description adds minimal behavioral context. The phrase 'in-process' gives a slight hint about the execution model, but it does not explain side effects, restart behavior, or anything beyond what annotations imply.
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 a single concise sentence that is front-loaded with the essential verb and object. It is appropriately sized for a zero-parameter tool, though it could potentially add a brief note about prerequisites without becoming verbose.
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?
Given the tool's simplicity (no parameters, output schema present, annotations available), the description is somewhat complete, but it lacks context about what starting the watch entails or when it is appropriate. The presence of an output schema and safety annotations reduces the burden, yet the description still feels sparse for an operation that likely has state implications.
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 tool has zero parameters, so the baseline is 4. There is no parameter information needed, and the description correctly omits any parameter details.
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 action ('Start') and the resource ('SAP Watch'), making it specific and unambiguous. It distinguishes from sibling tools like 'stop', 'status', and 'trigger' by the explicit verb.
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?
There is no guidance on when to use this tool, prerequisites, or alternatives. It does not mention whether it should be called before checking status or stopping, nor does it refer to any sibling tool for context.
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?
Annotations already convey read-only, idempotent, non-destructive behavior, so the bar for additional transparency is lower. The description states the tool compares revisions but adds no detail on output structure, pagination, or filtering behavior. With no contradictions, a mid-range score is appropriate.
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 a single concise sentence with no filler, making it easy to parse. However, given the tool has 10 parameters and potentially detailed output, the brevity borders on under-specification. It earns a high conciseness score but not a perfect one.
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?
Despite having an output schema, the tool's complexity (10 parameters, 4 required) is not reflected in the description. There is no mention of what the comparison returns (diff, summary, etc.) or how to interpret the parameters. The description is far too sparse to provide complete operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for 10 parameters. The description only implies the role of version1, version2, and source object, leaving six optional parameters (e.g., limit, lineCount, startIndex, maxVersions, objectType, startLine) entirely unexplained. The schema names provide some hints, but the description does not compensate for the lack of parameter documentation.
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 verb 'Compare' and the resource 'historical source revisions', which directly distinguishes it from sibling tools like sap.version.history.list (list versions) and sap.version.history.read (read a single version). The purpose is specific and immediately understandable.
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?
Usage context is implied: the user would invoke this when they need to compare two historical source revisions. However, there is no explicit guidance on when to use this over alternatives, such as sap.repository.compare, or when not to use it. The description does not mislead but lacks explicit directional context.
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?
The annotations already disclose read-only, idempotent, and non-destructive behavior, so the description only needs to add behavioral constraints. It adds that only active source is read and that returns are bounded, but it does not comment on permission requirements, inactive version behavior, or error cases. It remains consistent with 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?
The description is one compact sentence, front-loaded with the core verb and resource scope. Every phrase earns its place: 'bounded', 'active', 'class method', and 'canonical ADT Resource' all communicate meaningful constraints without filler.
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?
Given the large 7-parameter schema with no parameter descriptions, a single line gives a useful but incomplete invocation model. It does not define the exact valid parameter groups or explicitly route the agent away from sibling read/search tools. The presence of an output schema reduces the need to describe return format, so the main gap is invocation conditions rather than response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The three described read modes roughly align with startLine/lineCount, methodName, and resourceUri, which gives useful orientation. However, the schema's parameter descriptions are absent, and the description does not clarify objectName/objectType/systemId relationships or which parameter combinations are valid. It partially compensates for the low coverage, but not completely.
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 uses a specific verb and resource: reading an active ABAP source range, a class method, or an ADT resource. It makes the tool's objective clear, though it does not explicitly call out sibling tools such as sap.source.read_batch to differentiate them. The 'bounded' wording does help separate it from obviously bulk operations.
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 bounded range/method/resource phrasing implies this is for targeted source reads rather than bulk or search operations, but it never explicitly says when to choose this over sap.source.read_batch, sap.source.search, or sap.classic.read. No exclusions, prerequisites, or alternative routing are stated.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the 'bounded page' behavior and the 'transport-capable' filter, which are useful but limited. It does not disclose details like ordering, default page behavior beyond schema defaults, or any 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?
The description is a single sentence that is front-loaded with the action and resource. Every word earns its place; there is no redundant information or fluff. It is appropriately concise for a simple list operation.
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 that the tool has a rich input schema with types, defaults, and constraints, plus annotations covering safety and idempotency, and an output schema exists (so return structure is already defined), the description is mostly complete. It clearly conveys the core purpose and pagination behavior. The only gap is the lack of parameter explanations, but the schema compensates with structured definitions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. The phrase 'bounded page' hints at limit/startIndex, but it does not explicitly define them or mention the required systemId. The description adds minimal value over the structured 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 action (List), the resource (transport-capable SAP users), and the pagination behavior (bounded page). It distinguishes itself from sibling tools like sap.system.list (list systems) and sap.transport.list (list transports) by specifying 'transport-capable users'.
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 tool versus alternatives. It does not mention any exclusions, prerequisites, or alternative tool names. The description only states what it does, not when to choose it.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds 'bounded source range' and 'one historical revision', which provides minor context beyond annotations, but it does not explain pagination limits, error handling, or the meaning of 'bounded' relative to parameters.
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, clean sentence with no redundant words. It immediately states the core function and adheres to a front-loaded structure, making it highly scannable.
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?
For a tool with 9 parameters and multiple closely related siblings (e.g., sap.version.history.list, sap.version.history.compare, sap.source.read), a one-sentence description is insufficient to guide correct use. The output schema exists but does not address parameter semantics or selection context, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate. 'Bounded source range' hints at startLine/limit/lineCount but does not explain their roles or relationships, nor does it address other parameters like objectType, versionNumber, or startIndex. The description adds minimal value for understanding the 9 parameters.
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 'Read a bounded source range from one historical revision' clearly identifies the action (read), the resource (source range), and the scope (one historical revision). It distinguishes itself from sibling tools like sap.version.history.list (which lists versions) and sap.source.read (likely current source).
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 reading a specific historical version's source but does not explicitly state when to use this tool over alternatives like sap.source.read or sap.version.history.compare. No when-to-use or exclusion guidance is provided, leaving the agent to infer the context.
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?
Annotations already indicate non-readOnly, non-idempotent, and destructive=false. The description only says 'Stop', which adds no behavioral context such as whether the watch service restarts later, if ongoing tasks are terminated, or if state is preserved. It does not contradict annotations but provides minimal additional insight.
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, clear sentence. It is concise and directly states the action and target. No unnecessary words or repetition.
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 zero parameters and an existing output schema (context indicates it has output schema), the description is sufficient for the simple stop operation. However, it could briefly note that it requires the watch to be running or mention potential effects, but overall it meets the needs for this straightforward 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?
The tool has zero parameters, and schema coverage is 100%. The description adds no parameter information, but in this case, none is needed. The baseline score of 4 is appropriate given no parameter details required.
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 action ('Stop SAP Watch') and the context ('through the in-process SAP watch service'). It distinctively separates this tool from siblings like sap.ops.watch.trigger, sap.ops.watch.status, etc., by specifying the stop operation.
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?
The description provides no guidance on when to use this tool, prerequisites, or alternatives. Among siblings like sap.ops.watch.task.disable or sap.ops.watch.trigger, there is no clarification on when stopping the entire watch is appropriate versus other operations.
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 the tool as read-only and idempotent, covering its safety profile. The description adds the key behavioral trait that only a bounded section is returned, implying pagination via offset and length parameters. It does not detail edge cases, but the combination with annotations is 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?
The description is a single, front-loaded sentence with no filler. It delivers the core action and scope efficiently.
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?
Given the output schema exists and annotations are rich, the description is adequate for a simple read operation. However, it lacks context on how to identify an ATC finding or the format of docUri. The bounded section behavior is present, but required parameters remain unexplained, making it a minimal viable description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. The phrase 'bounded section' hints at offset and length but does not explicitly map to the parameters or explain the semantics of systemId and docUri. This is insufficient for two required parameters.
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 states the tool reads a bounded section of documentation for an ATC finding, using a specific verb and resource. The 'ATC finding' qualifier distinguishes it from general documentation or semantic documentation tools. The scope is unambiguous and immediately conveys the tool's core function.
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?
The description offers no explicit guidance on when to use this tool versus alternatives like sap.quality.atc.cached or sap.quality.atc.run. The 'bounded section' phrase implies offset/length usage but does not serve as a clear directive. No exclusions or alternative recommendations are provided.
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?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is a safe, non-destructive operation. The description adds little beyond restating the action and scope; it does not disclose any additional behavioral traits such as how results are returned or potential side effects on the system.
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 concise sentence, front-loaded with the action and scope. Every word earns its place, with no redundancy or filler.
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?
Given the tool has an output schema and strong annotations, the description is minimally sufficient but lacks context about prerequisites (e.g., system availability) and the meaning of detailLevel. It does not explain the purpose of running unit tests or what 'one exact repository object' implies for systemId/objectName usage, leaving the agent to infer from schema names.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly relates to objectName with 'one exact repository object' but leaves systemId and detailLevel completely unexplained. The description adds minimal semantic value beyond what the schema already conveys through parameter names.
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 action ('Run') and the resource ('ABAP Unit') with a specific scope ('one exact repository object'). It distinguishes from sibling tools like sap.quality.atc.run (which runs ATC checks) by focusing on unit tests for a single object.
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 phrase 'for one exact repository object' implies a targeting restriction, suggesting it is not for batch or multi-object runs. However, it does not explicitly mention alternatives or when-not-to-use scenarios, leaving some ambiguity about when to choose this over related quality tools.
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?
Annotations already indicate destructiveHint=true, so the description's job is to add beyond that. It only notes parameter differences but does not describe effects (e.g., whether the action is reversible, impact on dependent artifacts, or auth requirements). This is minimal additional behavioral context.
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 two sentences long, front-loads the action, and contains no unnecessary words. Every sentence serves a purpose.
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?
Given the complexity (destructive action, 5 parameters), the description covers the core behavior and version-specific nuances but omits important context like what 'confirmation' is for, prerequisites, or error scenarios. An output schema exists but is not shown; the description does not leverage it. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It implicitly clarifies that serviceName and serviceVersion are only needed for V2 bindings, but does not explain the meaning of required parameters like 'confirmation'. The description adds marginal semantic value over the bare 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 verb 'Unpublish' and the resource 'one confirmed RAP service'. It distinguishes between V2 bindings (requiring serviceName and serviceVersion) and V4 bindings (unpublished as a whole), which adds specificity beyond the title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for parameter usage based on binding type (V2 vs V4), guiding the agent on when to provide certain parameters. However, it does not explicitly mention when not to use this tool or suggest alternatives like the sibling sap.rap.binding.publish.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which covers the safety profile. The description adds a little domain context by stating it searches repository objects by pattern and type, but it does not disclose wildcard semantics, case sensitivity, pagination, or broader search behavior beyond the schema.
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, direct sentence with no filler words. It front-loads the main action and target, and every word earns its place.
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 annotated read-only/idempotent behavior and the schema constraints make the tool safe and partially self-describing. However, the description alone does not explain the `systemId` semantics or how `objectTypes` filter the result, which is important for an agent running in a multi-system environment. It is adequate for selecting the tool but not fully enough for confident invocation without additional knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only paraphrases `pattern` and `objectTypes`, leaving `systemId` and `limit` without meaningful explanation or context. An agent may still infer systemId, but the description does not directly connect it to the connected systems or clarify how limit affects the search.
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 states a clear action ('Search'), a specific resource ('ABAP repository objects'), and the matching criteria ('name pattern and object type'). This distinguishes it from source-code search tools like `sap.source.search` and inspection tools like `sap.repository.inspect`.
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 when to use the tool, but does not explicitly say when to prefer it over related sibling tools or which scenarios it is not suitable for. An agent can infer the use case from the wording, but there is no explicit guidance or alternative routing.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds 'normalize' but doesn't explain what normalization entails, such as output structure or side effects. 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?
The description is a single, front-loaded sentence ('Read and normalize one ABAP runtime dump.') with no redundant words or filler.
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 is minimal but sufficient to identify its core function. However, with 7 parameters and no parameter guidance, plus no usage distinction from siblings, the definition is not fully complete for correct invocation, despite the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no parameter explanations. Parameters like 'offset' vs 'startIndex' and 'includeFullContent' remain ambiguous; the schema only lists types and defaults, leaving the description to compensate, which it fails to do.
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 specific action verbs 'Read and normalize' and identifies the resource 'one ABAP runtime dump.' It clearly distinguishes from sibling tools like sap.runtime.dump.list by focusing on a single dump.
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 inspecting a specific runtime dump but does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or when-not cases. Sibling tools like sap.runtime.dump.list are not referenced.
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 indicate destructiveHint=true, and the description adds the context of requiring exact confirmation, which goes beyond the annotations. However, it does not detail the effects of releasing a transport.
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 a single concise sentence that is front-loaded with the action. It could be slightly more structured but is efficient.
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?
For a destructive tool with five parameters and three required fields, the description is insufficient. It does not explain the role of parameters like ignoreAtc or ignoreLocks, nor does it set expectations for the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fails to explain any of the five parameters, including the critical confirmation field and optional ignoreAtc/ignoreLocks flags.
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 verb 'Release' and the resource 'SAP Transport', distinguishing it from sibling tools like create, delete, inspect, and 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 phrase 'after exact confirmation' implies a prerequisite, but there is no explicit guidance on when to use this tool versus alternatives such as sap.transport.inspect or sap.transport.create.
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?
The description adds no behavioral information beyond what the annotations already declare (readOnlyHint, idempotentHint, etc.). While it does not contradict annotations, it fails to disclose any additional traits such as rate limits, required permissions, 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?
The description is a single, concise sentence that efficiently communicates the tool's purpose and mechanism. Every word serves a purpose, and it is front-loaded with the key 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 simplicity (no parameters, no nested objects, and a provided output schema), the description is sufficient. It clearly states what the tool does, and the output schema covers return value details.
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 tool has zero parameters, and the schema coverage is 100%. The description adds no parameter-specific meaning, but with no params, the baseline score of 4 is appropriate as there is nothing more to clarify.
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 verb 'Read' and the resource 'SAP Watch Status', with the additional context of 'through the in-process SAP watch service'. This distinguishes it from sibling tools like sap.ops.watch.history, which read history rather than status.
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?
The description provides no guidance on when to use this tool versus alternatives such as sap.ops.watch.history or sap.ops.watch.watchlist.read. It does not mention prerequisites or exclusion cases, leaving the agent to infer from the name alone.
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 the tool as read-only and non-destructive. The description adds the key behavioral detail that no rendering occurs, which is useful context beyond what annotations convey. However, it doesn't disclose error handling or the effect of suppressErrors, but the output schema likely covers return details.
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, front-loaded sentence with no redundant words. It clearly and efficiently communicates the core function.
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 tool is simple and has good annotations, but the description omits parameter semantics and explicit usage guidance. With an output schema present, the return values are likely covered, yet the missing parameter details and comparative guidance reduce overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. While 'code' is inferable from context, the behavior of 'suppressErrors' is completely unexplained, leaving a significant gap for agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Parse' and resource 'Mermaid code', and explicitly clarifies that it does not render, which distinguishes it from related tools like create or detect. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a use case (validate syntax without rendering) but does not explicitly state when to use this tool versus alternatives like sap.artifact.mermaid.detect or create. No direct comparison or exclusion is provided, leaving the usage context implied rather than explicit.
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?
Description aligns with annotations (readOnlyHint, destructiveHint) and adds context about preview being safe and non-changing. It discloses behavioral traits 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?
Single sentence, front-loaded with key action and purpose. No wasted words.
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?
Given the presence of an output schema and moderate complexity (3 params), the description is overly minimal. It does not explain what the preview returns or how to identify the object, leaving gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides no information about parameters (fileUri, systemId, transport). It fails to add meaning beyond the schema, leaving the agent uninformed about how to specify the object.
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 verb 'preview' and the resource 'SAP repository object', emphasizing safety and no change. It effectively distinguishes from sibling tools like sap.repository.delete.execute.
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 implies usage before actual deletion ('Preview how to safely delete'), but does not explicitly state when not to use or mention alternative tools. However, the context of siblings provides some guidance.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the 'bounded page' behavior, indicating pagination, which goes slightly beyond annotations. It does not contradict 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?
The description is a single, front-loaded sentence with no filler or redundant content. Every word earns its place.
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 is minimally viable for a read-only list tool, especially with annotations and an output schema present. However, it does not explain the purpose of less obvious parameters like 'length' and 'includeFullContent', nor does it point to alternatives such as sap.runtime.dump.inspect for detailed inspection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for this. Parameters like 'length', 'startIndex', and 'includeFullContent' are not explained; the only hint is 'bounded page', which loosely maps to pagination-related parameters but leaves their semantics opaque.
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 uses a specific verb 'List' and clearly identifies the resource 'ABAP runtime dumps'. The qualifier 'bounded page' adds scope and distinguishes this from sibling tools such as sap.runtime.dump.inspect or sap.runtime.trace.list.
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 phrase 'List a bounded page of ABAP runtime dumps' gives clear context for when to use this tool: whenever the agent needs a paginated list of runtime dumps. It does not explicitly name alternatives or exclusions, but the purpose is direct and unambiguous.
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?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the description adds minimal behavioral context by specifying that credential availability is included. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (7 words) and directly states the purpose. Every word earns its place with 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 no parameters, a rich output schema, and strong annotations, the description adequately covers the tool's purpose. It might benefit from clarifying it lists all configured systems, but it is largely 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?
There are zero parameters, and the input schema is fully covered. The description does not need to add parameter details; existing structured data is sufficient.
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 specifies the resource 'configured SAP system IDs and local credential availability.' It clearly states what the tool returns, distinguishing it from sibling tools like sap.system.inspect that likely provide more detailed information.
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 tool versus alternatives such as sap.system.inspect or sap.system.discovery.export. The description does not mention any context or exclusions.
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, idempotentHint, and destructiveHint=false, covering safety. The description adds context that the stack belongs to the 'current attached debuggee' and that frame IDs are 'stable', which provides useful behavioral context about prerequisites and ID consistency. No contradictions 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?
The description is a single concise sentence that front-loads the key action and resource. No filler words or redundant information; every word adds value.
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 low complexity, rich annotations, and existing output schema, the description is adequate for core invocation. It clearly communicates the primary purpose and prerequisite (attached debuggee), though it could benefit from brief parameter guidance. Overall, complete enough for a simple read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the parameters systemId or threadId. An agent must infer their meaning from the schema types and names, which may not be sufficient for correct invocation. This is a significant compensation gap.
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 a specific verb ('Read') and resource ('current attached debuggee stack and stable frame IDs'). It distinguishes itself from sibling debug tools like sap.debug.variables and sap.debug.status by naming the stack specifically, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in a debugging context but does not explicitly state when to use it versus other debug tools. No alternatives or exclusions are mentioned, leaving an agent to infer that it should be used when reading the stack is needed.
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?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds behavioral value by revealing that the payload is two disjoint kinds ('properties' vs 'DDL source') and introduces an 'optimistic fingerprint' trait that is not visible in annotations. The exact meaning of 'optimistic' is left somewhat ambiguous, hence 4 rather than 5.
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, efficient sentence that leads with the action and resource, then clarifies the payload types. There is no redundant metadata or repetition of the already-clear input schema.
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 strong annotations, explicit kind semantics, and the presence of an output schema, the description provides enough information for an agent to choose and execute the tool successfully. The only missing niceties are a definition of 'optimistic fingerprint' and an explicit note that systemId identifies the SAP system, neither of which blocks correct 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?
The input schema has no descriptions and the description does not directly define the parameters. It contributes some semantic meaning by implying that 'kind' determines whether the user gets properties or DDL source, and the enum values are self-explanatory. However, 'systemId' and 'name' are not explained at all, leaving a meaningful gap beyond what the schema provides.
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 names a specific action ('read'), a specific resource (ABAP Dictionary objects), and enumerates exactly what is returned for each kind: Domain/Data Element properties or Table/Structure DDL source. It is specific enough to distinguish from generic source readers, though it does not explicitly name an alternative sibling.
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 gives clear context for when this tool applies: reading DDIC object definitions without modification. It does not mention sibling alternatives or specify conditions such as 'use sap.source.read for normal source code', so it stops short of providing explicit routing, but the scope is clear and there are no misleading exclusions.
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?
Annotations already indicate readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false. The description adds one useful piece of behavioral context: the execution plan is 'short-lived'. Still, it does not explain what side effects 'creating a plan' may have or how long the plan remains usable, leaving some uncertainty 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?
A single focused sentence that opens with the core verb and object, then scopes the resource types. No filler, no redundant restatement of the title, and every phrase adds meaning.
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?
With zero parameters, an output schema present, and annotations available, the description is largely sufficient for an agent to decide to call this tool. The remaining ambiguity is what the 'short-lived execution plan' actually contains and whether it is automatically linked to a later execute call, but the target scope is clearly defined.
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?
There are no parameters and no required inputs, so the schema description coverage is effectively complete. The description adds value by naming the accepted artifact categories, even though it does not need to explain individual parameters because none exist.
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?
States a specific verb ('Create'), a clearly scoped resource ('execution plan'), and the target input types ('class, profiled executable program, or ABAP snippet'). It naturally distinguishes from the sibling sap.execution.execute, since a plan is not the execution itself, and from other preview variants such as sap.rap.preview or sap.repository.delete.preview.
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 intended use is implied: choose this tool to preview ABAP execution before actually running it. However, the description never explicitly says when to use this tool instead of sap.execution.execute or other preview-oriented siblings, and it gives no exclusion conditions.
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 and destructiveHint=false. The description adds that the data is 'normalized' and mentions optional component metadata, which adds behavioral context. However, it does not describe error handling or return format, but the presence of an output schema reduces the burden.
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 sentence of 13 words, front-loaded with the verb 'Read'. Every word is necessary and no redundancy exists.
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 simple parameter set, comprehensive annotations, and the presence of an output schema, the description covers the key functionality. However, it could benefit from briefly mentioning that the tool is safe and idempotent, or how the normalization works.
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 0%, so the description must compensate. The description hints that includeComponents controls optional software component metadata, but systemId is not explicitly explained (though its name is clear). The description adds marginal value beyond the schema for one of two parameters.
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 ('Read') and clearly identifies the resource ('SAP system') and the attributes retrieved (client, release, timezone, optional software components). It distinguishes from sibling tools like sap.system.list (which likely lists systems) by focusing on inspection of a single system's metadata.
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 reading system metadata but provides no explicit guidance on when to use this tool versus alternatives such as sap.system.list or sap.repository.inspect. No when-not-to-use or exclusion criteria are given.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the concept of 'normalized' output, but does not disclose error handling, edge cases, or return format. With annotations present, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word adds 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?
For a simple tool with one parameter, an output schema, and strong annotations, this description is complete. It states the purpose and the meaning of the input, and nothing more is needed.
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 0%, so the description carries the burden. It clarifies that 'code' refers to Mermaid code, which is essential. However, it does not specify expected format, language version, or constraints beyond what the schema (minLength) already shows.
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 'Parse Mermaid code and detect its normalized diagram type' uses a specific verb+resource structure. It clearly states the tool's action (parse/detect) and distinguishes it from sibling tools like validate and create.
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 implies a clear use case: when you need to identify the normalized type of Mermaid code. It does not explicitly mention alternatives or exclusions, but the context is sufficiently clear for a simple detection tool.
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?
Beyond the annotations, the description explains that the tool has a preview-first confirmation flow and that execution only happens with a confirmed resubmission. It also mentions an opt-in same-origin bridge, which is useful authorization context. It does not detail exactly what destructive side effects might occur, but the annotations already signal the destructive nature and the description explains the safegating mechanism.
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 compact two-sentence explanation with no filler. It leads with the core action ('Preview or execute'), then immediately gives the operative rule for both modes. Every clause adds useful information.
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?
For a destructive, non-idempotent write tool with zero schema parameters, the description gives the essential confirmation-flow and safety mechanism. An output schema exists, so the return format does not have to be repeated. It could be more complete with an explicit statement of what kinds of requests belong to this tool and what conditions should prevent execution, but the core flow is present.
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 no properties, so the description carries the burden of explaining how the tool is controlled. It says to omit confirmation for a preview and resubmit the returned exact value for execution, which is helpful operational guidance for a parameterless interface. It does not specify the actual write-payload format, preventing a higher score.
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 the tool performs a preview or execute action on a Classic ABAP Screen/Dynpro or GUI Status write, which is a specific verb+resource combination. It is not a tautology and can be told apart from sap.classic.read and other sibling write tools, though it does not explicitly contrast itself with another sibling.
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 gives an explicit usage protocol: omit confirmation to preview, then resubmit the returned value to confirm/execute. This tells the agent when each mode of the tool should be used. It does not name alternatives or exclusions, but the two-phase preview/execute context is unusually 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?
Annotations already declare the tool is read-only, non-destructive, idempotent, and open-world. The description adds that it reads 'summary or full' data, which provides useful context beyond the schema. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 14 words, every word informs. It is appropriately concise and front-loaded with the action and scope.
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 read-only operation, existing annotations, and available output schema, the description is sufficient. It covers the core action and key parameter semantics without needing to explain return values (covered by output schema).
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?
With 0% schema description coverage, the description compensates by indicating that 'summary or full' corresponds to detailLevel and 'one configured SAP system' corresponds to systemId. It doesn't explain ADT discovery jargon but provides enough linking to the parameters.
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 ('Read') and resource ('ADT discovery data') and scopes it to 'one configured SAP system'. It clearly distinguishes from siblings like sap.system.inspect (inspect system) and sap.system.discovery.export (export data).
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 clearly implies usage: reading discovery data for a specified system. It doesn't explicitly name alternatives or exclusions, but the context is unambiguous. It's not misleading.
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:

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

Score Badge

Copy to your README.md:

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

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