sap.capability.invoke_readInvoke a read capability for SAP ABAP objects by passing its name, schemaHash, and arguments. Enables AI assistants to retrieve ABAP data via ADT HTTP without SAP GUI.
Invoke a read capability with its described schemaHash and arguments.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| arguments | No | ||
| schemaHash | Yes |
Changes observed during successful MCP inspections.
v1.7.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds nothing beyond the schema: no error behavior, no hash-mismatch semantics, no note that the capability is dispatched by name from an open-world catalog.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the invocation and its two key inputs lead the sentence. It is efficient, though its brevity comes at the cost of specification rather than being a model of tightness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a generic dispatcher for an open-world capability catalog with no output schema and zero parameter documentation, so the description carries a heavy burden. It omits how to discover valid 'name' values, how to obtain the required 64-hex schemaHash, and what failure modes exist, leaving an agent unable to call it reliably without trial and error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across three parameters (two required), and the description only names 'schemaHash' and 'arguments' without explaining format, origin, or how the arguments object must match the target capability's schema. The phrase 'described schemaHash' hints at provenance but does not compensate for the total absence of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('invoke a read capability'), and the 'read' qualifier separates it from sibling tools invoke_write and invoke_destructive without the agent needing to open those schemas. However, it never explains what a 'capability' is in this system, leaving the resource concept abstract.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no exclusions, and no mention of the alternative siblings (search, describe, invoke_write). The word 'described' weakly implies the schemaHash must first be obtained elsewhere, likely via sap.capability.describe, but this prerequisite is never stated explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.