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

With no annotations, the description carries the full burden, and it does disclose one important behavioural trait: that '*' returns SAP sample charts (noise) and should only be used when explicitly asked. It implicitly reads as a read-only configuration lookup but never says so, and it omits whether results come from a live SAP system, whether they are cached, and how large the output can get when '*' is used.

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?

The purpose is front-loaded in the first clause, followed by key examples and then scope rules — a sensible order with little filler. The parenthetical SAP acronyms are dense but genuinely load-bearing for a domain agent, though the run-on parameter sentence could be split for readability.

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 the description rightly avoids explaining return values while still noting that G/L names are included. Given six optional parameters and no annotations, the main residual gap is that nothing states the read-only nature of the call or what an empty result means.

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 0%, so the description must supply all parameter meaning, and it does for five of six: transaction with five concrete key examples (WRX, BSX, GBB, PRD, KDM), chart_of_accounts empty-vs-wildcard semantics, and the SAP field mappings for valuation_class (BKLAS), account_modifier (KOMOK) and valuation_modifier (BWMOD). Only 'language' is left unexplained (it has a default of 'E'), and the accepted value format for the modifier fields is not illustrated.

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 the specific resource (MM account determination, OBYC/T030) and the key value-add (G/L account names), which is precise enough for a domain agent to know what it retrieves. It does not explicitly differentiate itself from near-neighbours such as grir_differences or condition_types, so an agent must infer the boundary from the domain terms alone.

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?

Usage guidance is present but parameter-scoped rather than task-scoped: 'chart_of_accounts: empty = the configured chart(s); "*" = all incl. SAP sample charts (only if asked)' tells the agent when to expand scope and when not to. There is no explicit statement of when to call this vs. grir_differences or condition_types, nor any prerequisite such as needing an SAP session first.

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 no annotations, the description carries the burden and does disclose meaningful behavior: result column naming (SUM_HSL, ROW_COUNT, COUNTD_BELNR), that empty group_by collapses to a single row, and that top is capped at 1000. It does not mention connection/auth prerequisites or how invalid field names are reported, and an output schema already covers the return shape.

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?

Dense but front-loaded: the purpose leads, then each parameter is dispatched in a short clause, then a worked example. The telegraphic style ('E.g. TB:', 'comma list of') is efficient but occasionally terse enough to require a second read.

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 six-parameter aggregation tool with an output schema already defined, the description supplies the query grammar, limits, and a full example, which is what an agent needs to construct a correct call. Remaining gaps are environmental (SAP connection state, error semantics) rather than call-construction gaps.

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%, so the description must carry all parameter meaning, and it does: the allowed measure grammar (SUM/AVG/MIN/MAX/COUNT/COUNTD with field suffix), group_by semantics including the empty case, where as ABAP Open SQL, order_by referencing result columns with a concrete 'SUM_HSL DESC' with top=20 pairing, and the top ceiling. Only 'table' is left implicit, which is acceptable given the example.

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+resource: SAP-side totals ('Totals computed in SAP') and contrasts with row-by-row retrieval ('one call instead of paging rows'), which implicitly separates it from read_sap_table. It never names the sibling explicitly, so the differentiation is inferred rather than stated.

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?

The 'one call instead of paging rows' framing tells the agent this is for aggregation rather than raw row extraction, and the worked TB/ACDOCA example shows a realistic invocation. It stops short of explicit when-not guidance (e.g., use read_sap_table when you need individual rows or columns not covered by measures).

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?

No annotations are supplied, so the description carries the full behavioral burden. It discloses worthwhile traits: paging via limit/offset, a performance caveat that the sales set is ~1000 rows, and that supplying condition_type switches to a full-field single-record view. It does not state read-only semantics, auth requirements, or what the paginated results contain beyond what the output schema covers.

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?

Dense and front-loaded: purpose first, then behavioral branches, then parameter semantics. Nearly every clause earns its place, though the telegraphic style ('application: V sales, M purchasing, TX tax') borders on cryptic for an unfamiliar agent.

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 an output schema present, return values need no elaboration, and the description covers the main behavioral modes and the bulk of the 7 parameters. Remaining gaps are minor: search semantics and the meaning of the defaults are unstated.

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%, so the description must compensate, and it largely does: it explains the condition_type on/off branching, limit/offset paging, the application codes (V sales, M purchasing, TX tax), that usage A means pricing, and that language is a 1-letter key. Only 'search' is left unexplained as to what fields it matches, and defaults are never restated.

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 names a specific resource ('Pricing condition types') and pins down the underlying SAP tables (T685/T685T/T685A) plus the payload ('texts, access sequence and control data'). It is clearly distinct from siblings such as pricing_procedure or read_sap_table, though it never explicitly contrasts itself with them.

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 does branch on usage ('No condition_type: paged list ... prefer search, sales has ~1000'; 'with one: all filled fields'), which is genuinely useful routing guidance. But there is no guidance on when to pick this over the sibling pricing_procedure or read_sap_table tools, so selection among alternatives is left to inference.

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 no annotations supplied, the description does carry the load and it discloses one important trait: results are cached for 7 days and refresh re-reads from SAP. That is genuinely useful. It does not state the operation is read-only, whether the refresh invalidates the cache for all callers, or what happens when the table does not exist.

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 dense sentences with no filler, and the returned-field list is front-loaded before the parameter notes. The telegraphic, semicolon-heavy style is slightly harder to parse than plain prose, which keeps it off a 5.

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 simple 3-parameter lookup tool with an output schema that already documents the return shape, this covers the essentials: what comes back, cache behavior, and both optional switches. Only the missing read-only/nonexistent-table behavior and sibling routing leave a gap.

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 0%, so the description must compensate and it largely does: 'search filters by name or description' clarifies the matching semantics that the bare string type does not, and 'refresh re-reads from SAP' explains the boolean's effect. The required 'table' parameter is left implicit but is self-evident from the tool name and first clause.

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?

Names the resource precisely and enumerates what comes back for each field (name, type, length, key, description), which makes it distinguishable from data-returning siblings like read_sap_table and aggregate_sap_table. The verb is only implied by the tool name, but the payload description removes any real ambiguity.

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 what the search and refresh switches do, which implies the two usage modes (look up a subset by name/description, or force a re-read), but it never states when to prefer this over read_sap_table or get_service_metadata. No exclusions or prerequisites are given.

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 no annotations supplied, the description carries the full burden. It does disclose useful behavior: computation happens in SAP, results are ordered most frequent first, the `top` cap is 1000, and `min_count` defaults to 2. It does not state that this is a read-only operation, whether it is expensive against large tables, or what happens when no group meets min_count.

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?

The definition is short and front-loaded, leading with the grouping semantics before the example and parameter notes. It is telegraphic in places, especially the fragment 'where: ABAP Open SQL', but every clause carries information and none is 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?

An output schema exists, so the ordering and return shape need not be re-explained. However, for a five-parameter query tool with zero annotation coverage, the description omits read-only/safety context, any performance or cost warning about scanning large SAP tables, and a precise relationship between `min_count` and `top`.

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%, so the description must compensate, and it largely does: `fields` is a comma list, `where` uses ABAP Open SQL syntax, `min_count` defaults to 2, and `top` is capped at 1000. Only `table` itself is left to the example rather than described, and the schema's default of 200 for `top` is not reconciled with the stated maximum.

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: grouping rows that share identical values on a comma-separated `fields` list, with results ordered most-frequent-first. The concrete invoice-duplicate example (table=RBKP, fields=LIFNR,XBLNR,RMWWR) makes the operation unambiguous. It doesn't explicitly name how it differs from siblings like aggregate_sap_table, so the differentiation is inferential rather than stated.

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?

Usage is implied through the worked example of finding duplicate invoices, which shows a realistic when-to-use context. There is no explicit statement of when not to use it, when to prefer aggregate_sap_table or read_sap_table instead, or any prerequisite about the SAP table needing to exist.

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?

No annotations exist, so the description carries the full burden. It does disclose the shape of returned records (program names, transaction codes, titles), which is genuinely useful, but says nothing about the result cap, wildcard/case-sensitivity semantics, or auth/environment requirements.

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?

One sentence, front-loaded with the verb and resource, with the parenthetical and examples earning their place by clarifying output content and pattern syntax. No waste.

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?

Hmm, adjust: an output schema exists, so return-value explanation is not required, and the description still sketches the record fields. What is missing is result-limit behavior and sibling routing, which keeps it from being complete for a search tool with an undocumented `top` parameter.

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 0% for both parameters. The description adds real meaning for `pattern` by showing wildcard examples like "ZFI*" and "*AGEING*", including leading-wildcard behavior, but the `top` parameter and its default of 200 are never mentioned anywhere.

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 (Find) and resource (reports), and even defines what a report record contains (programs, transaction codes, titles). It implicitly separates itself from run_sap_report and sap_report_info by being a name-pattern lookup, but never names those siblings explicitly.

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?

Usage is only implied: the wildcard examples make clear this is a discovery/lookup step, presumably before run_sap_report. There is no explicit when-to-use vs. sap_report_info, no statement about prerequisites (login/environment), and no exclusion guidance.

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 no annotations, the description carries the full burden and does disclose the critical side effect: files are written to 'Downloads/SAP attachments' and must be opened rather than read from the response. It omits whether existing files are overwritten, what permissions are needed, and how errors surface, which are real gaps for a tool that writes to disk.

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?

Three dense sentences, the core fact (files are saved, content not returned) front-loaded before the parameter rules. The kind-to-required-field mapping is compact and scannable, with 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?

An output schema exists, so return values need not be explained, and the write-to-disk behavior plus the list-only mode are covered. Missing is any statement about the 'folder'/'number' inputs and about what list results look like when download=false, which leaves a small ambiguity for an 8-parameter tool.

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 0%, so the description must explain all 8 parameters, and it covers kind, year, company_code, object_type, object_key, and download well, including a concrete example (BUS2091). However, 'folder' and 'number' are never mentioned anywhere, leaving two of the eight inputs entirely undefined.

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 pair and resource ('GOS attachments of an SAP document: lists them and saves the files') and immediately clarifies the scope boundary that content is never returned. No sibling tool in the list touches SAP attachments, so an agent can route here unambiguously.

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 among the parameter strategies: kind=invoice/material_doc/po/fi with the required companion fields (year, company_code), or the raw object_type + object_key alternative, plus the 'download=false only lists' switch. It does not say when to prefer the kind route over the raw route or what happens if all parameters are omitted.

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?

The description carries the full burden here because no annotations exist, and it discloses genuinely useful behavior: results are cached for 7 days, raw=true returns a very large EDMX payload (a performance warning), and refresh forces re-download. It does not say whether this is read-only, what auth is required, or how caching interacts with refresh. This is good but incomplete disclosure for an unannotated tool.

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?

Compressed into roughly three short clauses that are front-loaded with the return shape, followed by the important warnings about raw and refresh. No filler, though the fragmentary telegraphic style (no verb in the opening clause) costs some readability.

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 need not be explained, and the description usefully covers caching and the raw mode. However, for a four-parameter tool with zero schema documentation, the description leaves the required service identifier and the entity format unspecified, which an agent needs in order to call it 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 0%, so all four parameters rely entirely on the description. raw, refresh, and (partially) entity get meaning, but the required 'service' parameter is never explained: it is unclear whether it takes a service name from list_services or a URL or path. The accepted format for entity is also unstated. Half the parameters remain ambiguous.

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 names the resource (OData service structure) and its two modes of return: entity sets for the whole service, or keys and fields for a single entity. The verb is implied rather than stated (it is a fragment, not a sentence), but an agent can still tell it apart from list_services and describe_sap_table. It is specific enough to select correctly.

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 clear guidance on two parameters: use raw=true only if you need the full EDMX, but avoid it because the result is very large, and refresh re-downloads. There is no explicit statement of when to use this rather than list_services (which presumably yields the valid 'service' values) or describe_sap_table, so the routing guidance is implied and not stated.

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 no annotations, the description carries the full burden, and it does disclose real behavior: the source table (EKBE), the mismatch-only filter, the key_date default of today, and the hard cap of 1000 rows on top. It does not state that the operation is read-only, whether top truncates silently, or what permissions/company-code scoping are needed, so the behavioral picture is only partly filled in.

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 dense sentences, front-loaded with what is computed and what is returned, followed by the optional filters and limits. No filler and nothing that restates the title.

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 need not be described, and the description covers source, grain, filter, defaults and limits. The remaining gap is that the single required parameter (company_code) is undocumented, which matters for a SAP-domain tool that will otherwise fail on invocation.

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 0%, so the description must compensate, and it does for four of five parameters: it supplies the key_date format (YYYY-MM-DD), clarifies that the default is today (the schema's empty-string default is otherwise meaningless), and adds the 1000 cap on top that the schema does not express. The required company_code is never explained anywhere, which is the one real gap.

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 resource and scope: GR/IR differences per PO item, GR vs IR quantity and value, mismatches only, sourced from EKBE. That is far more informative than the sibling names (open_items_ageing, trial_balance_by_period) require, but it never explicitly contrasts itself with those adjacent reconciliation tools.

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?

"only mismatches" implicitly tells the agent this is a reconciliation-exception tool rather than a full ledger dump, which is genuine usage guidance. However, there is no explicit when-to-use/when-not statement, no prerequisites (SAP login/company code selection), and no named alternative for the full-population case.

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 no annotations, the description carries the full burden, and 'No SAP call' is a genuinely useful disclosure: the tool makes no remote SAP request, so there is no auth requirement or latency concern. That said, it says nothing about whether the result is cached or how login status is determined, and the safety profile must be inferred.

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?

Three short fragments with zero filler, and the resource is named first. It is telegraphic to the point of reading like a caption rather than a description, but nothing is wasted.

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 need not be explained, and with no parameters the calling contract is trivial. Still, for a discovery tool that gates all other SAP operations, the absence of any guidance about when to invoke it leaves a meaningful gap.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline is 4 for a no-argument tool; the description does not complicate or misrepresent the calling contract.

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 names the resource (SAP systems/environments) and specifies exactly what is reported: availability, which one is active, and login status. It omits an explicit verb like 'list', but the content is specific enough that an agent can distinguish this from switch_environment and sap_login, which act on a single environment rather than enumerating them.

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 statement of when to call this versus siblings such as switch_environment, whoami, or list_services. The phrase 'No SAP call' hints that it is a cheap local check, but the description never tells the agent to use it before initiating SAP operations or to discover valid environment names.

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 no annotations, the description carries the full burden. It discloses the matching semantics (substring on name/title) and implies a read-only catalog lookup, but says nothing about whether results are environment-scoped, case sensitivity, default result caps, or what happens when the search term is empty.

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 short sentences with zero padding, leading with the core action and following with the one behavioral preference. Nothing is wasted.

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-value explanation is unnecessary, and the tool is simple. Still, the description omits environment context and leaves two of three parameters undocumented, which is a meaningful gap for an agent operating in a multi-environment SAP toolset.

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%, so the description must compensate for all three parameters. It only clarifies 'search' as a name/title substring match; 'limit' and 'offset' are left entirely undefined in both schema and description, and their interaction with the 'prefer search over paging' advice is unstated.

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: search the Gateway catalog for OData services, with the matching dimension (name/title substring) spelled out. It is clearly distinct from siblings such as get_service_metadata or query_entity, though it never acknowledges the name's 'list' framing versus its search behavior.

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?

'Prefer a search term over paging' gives genuine usage guidance for choosing between parameters. However, there is no guidance on when to call this versus get_service_metadata or query_entity, nor whether an environment must be selected first given the presence of list_environments/switch_environment siblings.

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?

No annotations are supplied, so the description carries the full behavioral burden. It does disclose two useful constraints beyond the schema: the date format and default for key_date, and the hard cap 'top max 1000'. However, it never states that this is a read-only reporting call, what permissions/company-code scope are required, or how results are paginated or grouped — gaps that matter for a 5-param SAP report.

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 dense sentence that is front-loaded with the resource and computation, then appends parameter hints with no filler. It is slightly over-compressed ('top max 1000', the trailing 'with names') at the cost of a little readability, but no sentence is wasted.

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 the bucket and name return values need not be re-explained. For a 5-parameter report tool the description covers the essential computation and most parameters; the remaining shortfall is the undocumented required company_code and the ambiguous partner semantics.

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%, so the description must define all five parameters, and it only partly does. key_date gets a format and default, account_type gets its two values, and top gets a maximum — but the required company_code is never mentioned at all, and 'per partner' leaves the partner parameter ambiguous (filter vs. grouping dimension) while top's default of 500 is omitted.

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 resource and computation: 'Vendor/customer ageing computed in SAP: open items at key_date ... per partner in buckets by days past net due', and even enumerates the bucket boundaries. The ageing-over-open-items framing is inherently distinguishable from sibling report tools like trial_balance_by_period or glir_differences without needing to name them.

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?

Usage is only implied: an agent infers 'use this when you need AR/AP ageing buckets'. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative (e.g., trial_balance_by_period for ledger balances vs this for open-item ageing).

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?

No annotations exist, so the description carries the full burden, and it does disclose meaningful output behavior: only filled fields are returned and field_legend explains the columns, which prepares the agent for sparse, legend-driven output. It says nothing about permissions, read-only nature, or row limits, which is a gap for a zero-annotation tool.

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 dense, front-loaded sentences with no filler; the resource and table identifier come first, followed by parameter hints. The semicolon-separated style is terse but readable for a domain expert.

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 need not be spelled out, and the field_legend note is a useful addition. Still, for a four-parameter tool with no schema descriptions and no annotations, the undocumented required `name` argument and unspecified `language` behavior leave the definition short of complete.

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%, so the description must compensate, and it partially does: accepted application values (V/M/TX or empty for all) and the usage default (A = pricing) are explained. However, the required `name` parameter and the `language` parameter are never mentioned, leaving half the inputs — including the mandatory one — without meaning.

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 names the specific resource and SAP table: steps of a pricing procedure from T683S, comparable to standard procedures V/08 and M/08, returned with texts. An agent can distinguish this from generic siblings like read_sap_table or condition_types. It lacks an explicit verb (get/list), but the retrieval intent is unambiguous.

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?

Usage is only implied: the tool is clearly for inspecting pricing procedure steps, and the application/usage value hints (V/M/TX, A = pricing) steer invocation context. There is no explicit statement of when to prefer this over read_sap_table, nor any precondition or exclusion.

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?

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing beyond the implied read semantics of 'query'. It says nothing about permission/auth requirements, server-side limits on $top, paging behavior of $skip, throttling, or what happens on invalid filter syntax.

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 the resource scope first and the accepted options in a compact parenthetical. No filler, no restatement of the tool name, nothing to trim.

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 eight parameters, zero schema description coverage, and no annotations, this definition is thin for the tool's complexity. An output schema exists so return values need not be explained, but the description should still cover filter/host syntax, service and entity_set identification, and pagination semantics.

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%, so the description must compensate, and it partially does by mapping six of the eight parameters to their OData system options ($select/$filter/$orderby/$top/$skip/$expand). However, it gives no syntax examples for filter/orderby, no guidance on expand navigation-property naming, and leaves service and entity_set undocumented. Partial compensation only.

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 concrete verb (query) and resource (a service's entity set) and enumerates the OData v2 system query options it supports. An agent can tell this is a generic OData read against an arbitrary entity set, though it never explicitly contrasts itself with siblings like read_sap_table or aggregate_sap_table.

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 mention of when this is the wrong choice (e.g. versus read_sap_table or aggregate_sap_table), and no stated prerequisites such as login or environment selection. The agent must infer usage entirely from the name and the OData vocabulary.

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 no annotations, the description carries the burden and does well: it discloses the 1000-row cap, the skip-based pagination and that the answer returns next_skip, that keys are always included, that wide tables return large payloads, and what drop_empty does. It does not mention authorization requirements or the cost/latency of wide reads, which keeps it below a 5.

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-loaded with the purpose and routing advice, then dense parameter guidance with no filler. The telegraphic style ('where: ABAP Open SQL', 'top max 1000') is efficient for an expert but slightly clipped for readability.

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 need not be explained, and the description still mentions the next_skip field for pagination. For a six-parameter read tool with no annotations, it covers dialect, formats, limits, and pagination – everything needed to call it 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 0%, so the description must compensate, and it does: it specifies the where clause dialect (ABAP Open SQL, not OData), quoting rules, internal date and leading-zero formats with a worked example, the fields comma-list semantics with implicit key inclusion, top's maximum, and skip/drop_empty behavior. Only the 'table' parameter is left implicit, which is self-evident.

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 ('Read rows of any SAP table or DB view') with an SE16 analogy, then explicitly claims primacy as 'FIRST CHOICE for SAP data', which separates it from the many sibling SAP tools. An agent can identify the tool's role 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?

Names both alternatives and the exact conditions that route to them: totals go to aggregate_sap_table, unknown field names go to describe_sap_table. This is explicit when-to-use and when-to-use-something-else guidance rather than implied usage.

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 no annotations, the description carries the full burden and does well: it discloses that output is written to files under Downloads/SAP reports, that the response is only a path/columns/preview, the 5000-row cap, the ~55 s completion budget, and that no popups are handled. It omits auth expectations (sap_login) and what occurs on timeout or failed report selection.

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?

The most important facts (what it does, where output goes, ask-user-first warning) are front-loaded, and the param notes follow in a compact order. The telegraphic fragment style and inline JSON example make it dense, but nearly every clause carries information.

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 five-parameter tool with an output schema and nested selections object, the description covers execution semantics, output location, row limits and the safety precondition, so an agent can call it correctly. Residual gaps are the undocumented `folder` parameter and error/timeout behavior, which matter because a 55 s cap is stated but its failure mode is not.

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 0%, yet the description explains the two most complex parameters in depth: variant as a saved variant and selections with a concrete example showing single values, multi-value lists, and low/high ranges in internal formats, plus the max_rows ceiling of 5000. The `folder` parameter and the exact form of `report` (tcode vs program name) remain unexplained.

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 ("Run an SAP GUI report (tcode or program) and save its output") plus the output artifact (ALV to Excel, classic lists to text). It is clearly distinguishable from siblings like find_sap_reports (discovery), sap_report_info (metadata) and read_sap_table (raw table reads).

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 concrete execution guidance: use a saved variant as the easiest path, use selections to override it, and ask the user first for any report that may post, change or send. It does not explicitly name sibling tools or say when to prefer find_sap_reports/sap_report_info instead, so routing is implied rather than spelled out.

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?

No annotations exist, so the description carries the full burden and does most of it: it discloses that this is an interactive UI popup on the user's screen, that the password is never passed through chat but stored in the OS keychain, and that the call blocks for up to 10 minutes. It stops short of saying what happens on timeout or user cancellation.

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?

Three short sentences, front-loaded with what happens on screen, then the invocation trigger, then the env values and blocking limit. No filler; every clause carries information an agent needs.

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 tool with an output schema, the description covers purpose, trigger, credential security model, environment values, and blocking duration. Nothing needed to decide whether and how to call it 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 0%, but the description compensates by enumerating the only meaningful values ('prod (default) | dev') for the single env parameter, which the bare string schema does not. That is exactly the semantic gap the description needs to fill.

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 concrete verb and resource: opens a login window on the user's own screen for their SAP user. That is immediately distinguishable from every sibling (all data/report tools), and the parenthetical clarifies the credential handling model.

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 an explicit trigger: call it when another tool reports missing or rejected credentials, or when the user asks. That is clear context for invocation, but there are no exclusions (e.g., don't call if already authenticated) and no alternative paths mentioned.

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?

No annotations are supplied, so the description carries the full burden. It implicitly conveys a read-only inspection ('info', 'selection fields and saved variants') and a prerequisite relationship, but says nothing about behavior for unknown/invalid report names, auth needs, or whether variants are truncated. The presence of an output schema reduces the need to describe the return shape.

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, zero filler, with the resource definition first and the sequencing constraint second. Nothing could be removed without losing information.

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 lookup with an output schema, the definition covers purpose, parameter format, and call ordering. It could add a note on error behavior or whether variants require authorization, but no critical calling information 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 0%, so the description must compensate for the undocumented 'report' parameter. It does so meaningfully by defining that the value is a tcode or program name, which is the key piece of information the bare string schema lacks.

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 resource ('a report's selection fields and saved variants') and clarifies the identifier format (tcode or program). It is not a clean verb+resource phrase, but an agent can still tell exactly what this retrieves and how it differs from run_sap_report.

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?

'Call before run_sap_report' gives an explicit ordering constraint that routes the agent to the correct sibling workflow. It doesn't state when not to use it (e.g., when selection fields are already known), but the positive guidance is concrete.

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 no annotations, the description carries the full burden and does substantial work: it discloses the blast radius (all SAP tools), session scoping, the _sap_env marker on non-prod answers, and the instruction never to present non-prod data as live books. It also notes that re-selecting the same env reloads the login. It omits validation/error behavior and whether the switch is reversible or persisted.

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?

Three short sentences with the core action front-loaded and no filler. The phrasing is telegraphic ('Same env = reload login'), which is compact but costs a little readability.

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 need not be explained, and the description covers the essentials an agent needs: scope, accepted values, and the non-prod data caveat. Gaps remain around invalid-input handling and the interaction with sap_login, but they are minor for a one-parameter switch.

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 0% and the single parameter has no enum, so the description compensates by enumerating accepted forms: prod, dev, production, development, test, and SID. That is real added meaning beyond the bare string type. It does not specify case sensitivity or what a SID string looks like.

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 action and scope: 'Point all SAP tools at prod or dev ... for this session.' That clearly distinguishes it from siblings like list_environments (which reads) and sap_login (which authenticates). It stops short of naming those siblings explicitly, so the differentiation is inferable rather than stated.

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?

Usage context is implied by 'for this session' and the accepted value list, so an agent can infer this is a session-scoped switch. There is no explicit when-not guidance, no mention of how this relates to list_environments or sap_login, and no statement about what happens on an invalid value.

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 no annotations, the description carries the full burden and does volunteer two real behavioral facts: it performs no SAP call (so it incurs no data cost), and reset=true opens a window that asks the USER for more allowance (a user-facing side effect, not a silent config change). It still omits whether the reset is immediate or requires approval and what the budget scope is.

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?

It is short with no wasted padding, and the parameter note is placed last where it belongs. However, the telegraphic sentence fragments ('SAP data pulled in this conversation, per tool, and the limits') make the first sentence slower to parse than a single well-formed clause would be.

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 need no explanation, and the description covers the essential 'no SAP call' and 'reset prompts the user' facts. Still missing for a 1-param budget tool: what the limits are measured in (tokens vs calls) and whether the budget is per conversation or global.

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 0% for the single boolean 'reset' parameter, and the description does compensate partway by explaining that reset=true asks the USER in a window for more allowance. It does not state what reset=false (the default) does or the consequence of declining the prompt, so the meaning is only half-specified.

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 conveys the subject (SAP data consumed in this conversation, per tool, plus limits) but is a noun fragment rather than a verb+resource statement, so an agent must infer that this is a read-only budget/usage status tool. 'No SAP call' usefully separates it from data-querying siblings, but the core action is never named.

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?

Implied usage is clear enough: call it to check consumption against limits, and set reset=true to request more allowance. There is no explicit statement of when not to use it or which sibling to prefer, but the 'No SAP call' clause implicitly routes agents elsewhere for actual data retrieval.

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 no annotations, the description carries the full behavioral burden. It does disclose two genuinely useful traits beyond the schema: computation happens server-side in SAP rather than via table reads, and full-year results are written to an Excel file as a side effect. It says nothing about read-only safety, permissions, runtime, or whether the Excel write can be suppressed, which leaves real gaps for a report of this weight.

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 clauses, each carrying distinct information: what is computed, how periods define opening, the optional filters, and the Excel side effect. The output structure is front-loaded and nothing is repeated from the schema or title.

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 need not be described, and the description instead covers computation source, period semantics, and the Excel artifact. What remains unaddressed is authentication and whether this is a safe read, which matters given the absence of annotations on a 7-parameter report tool.

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%, so the description must compensate and largely does: it explains that periods run 1-16, that opening balance equals all periods before period_from (a semantic the schema cannot express), that the account range is optional, and that ledger defaults to 0L. Only company_code and fiscal_year are left to inference, and both are self-evident from their names.

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 names a specific report (trial balance), its source table (ACDOCA), the engine (SAP), and the exact columns produced: opening incl. carry-forward, period debit/credit, closing, with names. That is far more specific than the name alone and clearly separates it from siblings like open_items_ageing or read_sap_table. It stops short of explicitly naming which sibling to use instead, so a 4 rather than a 5.

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?

Usage is only implied: the reader can infer this is the tool for period-based trial balances and that account range is optional, but there is no statement of when to prefer it over grir_differences, open_items_ageing, or run_sap_report, nor any prerequisite such as required SAP login. Guidance is present but must be reconstructed from the parameter hints.

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?

No annotations are provided, so the description carries the whole burden, and it discloses almost nothing behavioral: it does not say whether the call is read-only (implied but unstated), whether it requires an existing session, what happens if unauthenticated, or whether it can trigger a login. The content it does give is essentially a return-value summary, which duplicates the output schema rather than adding 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.

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

At seven words it is certainly concise and front-loaded, but conciseness here tips into under-specification: a bare noun phrase with no verb leaves the action ambiguous. No words are wasted, but the words present do not do enough work for an agent to be confident about the tool's effect.

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 zero-parameter informational tool with an output schema, the description need not explain return values, and the schema plus the field list cover that half of the picture. What is missing is the operational context that matters for a session-scoped call: whether a logged-in session is required and how this differs from the environment/login siblings. Adequate but with clear gaps.

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?

The tool takes zero parameters, so per the baseline this scores 4; there is no parameter meaning the description could add. Nothing in the description misrepresents the argument surface, and the empty schema is consistent with a no-argument context lookup.

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 is a noun fragment ('Active SAP system, host, client and user') that reads like a list of return fields rather than a statement of what the tool does. Combined with the name whoami, an agent can infer it reports the current session's identity and environment, but the description never supplies a verb or states that this is a session-context read. It does implicitly distinguish itself from mutating siblings such as switch_environment and sap_login, but only by omission.

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 at all: nothing tells the agent to call this to confirm which system/client/user is active before running reports or queries. No contrast is drawn with adjacent siblings like list_environments, switch_environment, or sap_login, which an agent could easily confuse with a session-identity check. Usage must be fully inferred.

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