Check API Release State

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

Annotations already declare readOnly/openWorld/idempotent/non-destructive, so the bar is lower, but the description adds substantial value beyond them: the underlying resource, on-premise upgrade-stability semantics, and — most importantly — which outcomes are expected rather than failures (releasable=false for programs/includes, NOT_RELEASED on Z objects as the normal state). The return JSON shape and the full state enum are enumerated, giving the agent a complete behavioral model.

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?

Well organized with clear sections (purpose, supply modes, args, returns, examples, notes) and front-loaded with the core purpose and distinguishing behavior. There is mild redundancy — the C1 contract is explained twice and the Args block restates the either/or rule — but the length is largely justified by the tool's conceptual nuance and the absence of an output 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?

Since no output schema exists, the description fully carries the return-value documentation, including the JSON shape and every state enum value. It covers both input modes, the response_format switch, edge-case semantics for non-releasable types, and points to the sibling alternative for the same data. Nothing an agent needs to invoke it 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 baseline is 3; the description adds a real layer on top by grouping the five parameters into two mutually exclusive supply modes (object_uri OR object_type+object_name with conditional function_group), noting the URI provenance from sap_search_objects, and mapping natural-language queries to concrete parameter values in the examples. It complements rather than repeats the schema.

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 action ('Check whether an ABAP object is a released API') against a concrete resource (the ADT apireleases resource), and explains the C1 compatibility contract in the opening sentence. It differentiates from siblings by noting the endpoint resolves object URIs and non-releasable types itself, unlike sap_read_table on ARS_W_API_STATE. An agent can separate this from its 48 siblings 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?

Provides concrete usage triggers via three natural-language examples ('Is IF_OO_ADT_CLASSRUN a released API?', 'Can I use CL_GUI_ALV_GRID in cloud development?'), which helps an agent recognize when the tool applies. It explicitly names the alternative (sap_read_table on ARS_W_API_STATE) and states when this endpoint is preferred, plus gives the decision rule between object_uri and object_type+object_name. It also sets expectations on which outcomes are normal rather than errors.

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