RuntimeListFeeds

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

With no annotations at all, the description carries the full burden and does: it marks itself read-only, discloses that it runs on its own ABAP session, explains exactly what happens when timeout fires (read cancelled, session logged off, system unchanged), describes ordering (newest first), pagination via next_to, the incomplete_second overflow case, and the recordable batch-mode behavior where a call answers with empty content and is read later by number.

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?

Nearly all content is substantive, but it is delivered as one long run-on block rather than front-loaded clauses or bullets, which makes the critical routing information (feed types, pagination, batch caveat) harder to scan. The timeout paragraph is also duplicated almost word-for-word from the input schema, which is wasted space.

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 12-parameter, no-annotation, no-output-schema tool, it covers the essentials: filtering semantics, ordering, pagination continuation, overflow handling and batch recording. What it omits is the shape of non-dump entries (system_messages, gateway_errors, descriptors/variants), so an agent knows a dump's dump_id but not what fields other feeds return.

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 nonetheless adds value by explaining parameter *interactions* the schema does not: feed_type vs feed_types as mutually exclusive alternatives, that next_to should be passed back as `to`, and that a missing feed_type reads as descriptors. It does repeat the timeout text nearly verbatim from the schema, which caps this below a 5.

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 and resource ('Reads the ADT runtime feed named by feed_type') and then enumerates each of the five feed types with what it returns, so an agent can map a task (dumps vs system messages vs feed discovery) to the right mode without opening the schema. It also effectively distinguishes itself from siblings like RuntimeListSystemMessages and RuntimeGetGatewayErrorLog by showing those are feed types of this tool.

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 concrete selection rules: default is 'descriptors' when feed_type is absent, and feed_types is the alternative when several feeds share filters (with an explicit per-feed error shape). It also prescribes setting timeout below the client's request limit and warns that a client cancel does not stop SAP. It never states when *not* to use this tool or names a sibling to prefer instead, 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.