Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description adds substantial behavior beyond them: the policy gate that can reject write mode, the fact that a write returns a transaction_id tied to a SAP LUW, and that writes are never auto-committed. Missing only error/failure semantics or what happens on an invalid function name.

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?

Four tight sentences, front-loaded with the core action and prerequisite, then the write-policy constraint, then the transaction lifecycle. No filler and no repetition of schema text.

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?

Output schema exists so return-value explanation is not needed; the description otherwise covers invocation, prerequisite, permission gating, transaction grouping, and finalization path. An agent has everything required to call this correctly on a first attempt.

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 coverage is 100%, so the baseline is 3, but the description compensates for the weakest documented field by explaining mode's policy-check behavior and transaction_id's reuse semantics across related writes. It goes beyond restating the schema by framing the LUW grouping model.

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?

Starts with a specific verb+resource ('Invoke a SAP RFC-enabled function module with JSON parameters') and immediately distinguishes itself from siblings by naming get_rfc_function_interface, commit_rfc_transaction, and rollback_rfc_transaction. An agent can tell exactly what this tool does and how it fits in the lifecycle without opening the schema.

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?

Explicitly states the prerequisite ('Call get_rfc_function_interface first'), the condition for write mode ('required for functions classified as mutating... rejected unless the server's policy explicitly allows writes'), and the follow-up routing ('pass it to commit_rfc_transaction or rollback_rfc_transaction'). When-to-use and when-not is fully covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructive, non-idempotent, and open-world behavior, so the bar is lower, and the description still adds real value: the underlying BAPI, that it persists (rather than reads) staged state, and the read_write policy precondition. It stops short of describing post-commit transaction state or error semantics, which the output schema may partly cover.

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?

Two tight sentences with the core action front-loaded and the operational precondition appended. No redundant restatement of the tool name or schema.

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?

With a 2-parameter schema at full coverage, rich annotations, and an output schema, the description covers the essential workflow and availability constraint. The main minor gap is that it doesn't discuss rollback behavior or failure handling, but the structured fields carry most of that.

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 100%, so transaction_id and wait are already fully documented in the schema. The description adds no format detail or usage nuance for either parameter, making the baseline 3 appropriate.

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?

States a specific verb (persist/commit) and resource (staged changes in the identified SAP transaction), and grounds it in the wrapping BAPI_TRANSACTION_COMMIT. It also references call_rfc_function as the operation whose changes it commits, distinguishing it clearly from rollback_rfc_transaction.

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?

Explains the workflow context ('changes staged by prior write call_rfc_function calls') and adds an explicit availability constraint ('only available when server policy mode is read_write'). It does not explicitly route the agent to rollback_rfc_transaction for the failure case, so an alternative-selection sentence is missing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint and openWorldHint already declared, the description adds useful behavioral context: it returns resolved structure fields and documented exceptions, and it is framed as a prerequisite step. It does not elaborate on remote-system behavior, authentication, or rate limits, but the annotations already cover the safety profile.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the return content, followed by an imperative usage rule. Every sentence carries value and there is no filler.

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?

For a one-parameter introspection tool with a 100%-covered schema, annotations, and an output schema, the description is sufficiently complete. It tells the agent what is returned, why the tool matters relative to call_rfc_function, and does not need to spell out return values because the output schema does that.

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 100%, so the single function_name parameter is already clearly documented. The description does not add syntax, naming rules, or formatting details beyond saying the tool operates on a function module, so the baseline of 3 applies.

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: return the full parameter interface and documented exceptions for a function module. It distinguishes itself from the adjacent invocation tool by explaining that it must be called before call_rfc_function.

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?

It gives a clear usage rule: always call this before call_rfc_function to know required parameters and their shapes. It does not state when not to use it or name any alternative introspection path, so it falls short of the full when/when-not/alternatives standard.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/openWorld annotations by disclosing the ADT-first / RFC-fallback strategy, that the fallback triggers on live ADT failures (not just disablement), that classes need several RFC calls otherwise, and that the returned `via` field reports the actual transport used. This is exactly the behavioral detail an agent needs.

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?

Front-loads the purpose before the transport mechanics, and the multi-clause explanation is informative rather than padded. Slightly long for the payload, but each sentence carries real information about fallback behavior.

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?

An output schema exists, so return values don't need spelling out; the description instead covers the tricky behavioral aspect (transport selection and the `via` field). Nothing an agent needs in order to call this correctly is missing.

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 coverage is 100%, so the schema already documents all three parameters. The one clause about function_group being required for function_module merely restates the schema's own description, adding no new meaning. Baseline 3 applies.

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?

States a specific verb (Read) and resource (full ABAP source of a program, class, or function module), with the object scope enumerated. This is clearly distinguishable from the RFC-function siblings (search_rfc_functions, call_rfc_function, etc.), none of which read source.

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?

Gives strong context for invoking it: the transport choice is automatic and the agent 'never need[s] to choose the transport yourself.' However, it offers no explicit when-not-to-use guidance or comparison against sibling tools for cases where an agent might reach for an RFC reader instead.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so safety is covered. The description adds real value beyond them: the policy-mode gate and the fact that it acts on state created by earlier call_rfc_function writes, which an agent could not infer from the annotations alone.

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?

Two tightly written sentences with the effect front-loaded and the availability constraint second; no filler and nothing repeated from structured fields.

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?

For a single-required-param destructive tool with an output schema, the description covers the effect, the precondition, and the linkage to prior writes. Return values are covered by the output schema, so nothing needed for correct invocation is missing.

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 coverage is 100% and the single transaction_id parameter is already documented as an opaque ID returned by the write call. The description adds only that the ID identifies a SAP transaction, so the schema does the heavy lifting and the baseline of 3 applies.

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?

Specific verb+resource: it discards changes staged by prior write call_rfc_function calls and names the underlying BAPI_TRANSACTION_ROLLBACK. An agent can immediately distinguish it from commit_rfc_transaction without opening either schema.

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?

States the precondition 'Only available when the server policy mode is read_write' and scopes the tool to changes staged by prior write calls, which implicitly routes the agent away from commit_rfc_transaction. It never names the alternative sibling or the inverse-condition explicitly, so it stops short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is well covered by structured data. The description adds workflow context ("call this first") but says nothing about result truncation, the effect of the limit, or search cost against a live SAP system. Useful but not rich 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tight sentences: the capability and its syntax come first, followed by the workflow-positioning instruction. Every clause carries information and nothing is padded.

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?

An output schema exists, so return format need not be described. Combined with 100% parameter coverage and explicit routing to sibling tools, an agent has everything required to call this correctly.

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 100%, so all three parameters (pattern, group, limit) are already documented in the schema. The description restates the wildcard syntax for pattern but adds no meaning for group or limit. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (search) and resource (remote-enabled function modules / BAPIs / RFCs) plus the search key (name pattern). The distinction from get_rfc_function_interface and call_rfc_function is clear because the description frames this as the discovery step.

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?

Explicitly says "Call this first to discover available functions before get_rfc_function_interface or call_rfc_function," naming both alternatives and the order in which to invoke them. An agent has no ambiguity about when to reach for this tool versus its siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.