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

With no annotations, the description carries the full burden of behavioral disclosure. It does frame the tool as analytical and non-mutating by saying it 'examines your query and returns' guidance rather than executing anything. However, it does not explicitly state read-only behavior, metadata-fetching behavior beyond the fetch_metadata parameter, or any limitations or failure traits.

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 description is well structured: a lead sentence, a bulleted return-value list, and a clear usage call-out. It is slightly redundant ('Analyze... return' and 'This tool examines... and returns' say the same thing), but every section earns its place and the information is easy to scan.

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 there is no output schema, the description compensates by listing the major output categories an agent can expect. It also gives an ordering hint ('USE THIS FIRST') that orients the agent in the broader workflow. It does not fully specify the exact result structure or route to related tools like sap_smart_table_query, but it is sufficient for invoking this tool 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 the schema already documents both parameters (query and fetch_metadata). The description adds little beyond the schema: it references natural-language queries generally but does not explain fetch_metadata or how parameters affect the returned guidance. Baseline 3 applies due to high schema coverage.

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 clearly names the action ('Analyze a natural language query') and the resource (the query), then enumerates specific outputs: candidate tables, query type, date ranges, aggregation hints, and field recommendations. It does not explicitly contrast itself with similar sibling tools like sap_smart_table_query, but the purpose 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?

The description provides an explicit usage directive: 'USE THIS FIRST before building complex queries to get field guidance!' This tells an agent when to invoke it. It does not, however, name alternative tools or state when not to use it, so it lacks complete routing/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 must carry the behavioral disclosure burden, and it does so well. It reveals that the tool is a composite, classifies each note via the /classify_note_v2 gateway endpoint, aggregates results, and explains an important edge case around notes not downloaded into SNOTE. It stops short of describing the full result shape or potential dependencies, but the disclosed behavior is substantive.

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 description is front-loaded with the primary purpose, followed by the internal mechanism and the critical caveat with follow-up instructions. Every sentence contributes distinct value, and there is no filler or repetition.

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 composite tool without an output schema, the description covers purpose, internal behavior, aggregation behavior, and an important edge-case condition with recommended next steps. It does not fully enumerate the result fields beyond needs_download, but it provides enough context for an agent to understand what the tool does and how to act on its output.

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% and the single parameter note_ids is already well described with an example format. The description adds context that multiple notes can be checked and that notes are classified individually, but this is not essential beyond the schema, so the baseline score 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 uses a specific verb and resource: 'Check relevancy of one or more SAP Note numbers against this system' with concrete dimensions such as component/SP levels, download state, and implementation readiness. This clearly distinguishes it from siblings like sap_scan_security_notes, which focuses on security scanning rather than per-note relevancy classification.

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 description explicitly gives conditional follow-up guidance: notes never downloaded into SNOTE are reported with needs_download=true, and the agent should 'run sap_download_note_v2 (requires OSS connectivity) or sap_upload_note_v2 first for a definitive verdict.' This names specific alternatives and the exact condition under which to use them, providing actionable usage 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 behavioral disclosure burden. It reveals that STRU is not queryable and cannot be SELECTed from, and marks TABL and VIEW as queryable, which is valuable runtime behavior. It does not state what happens when the type does not exist or whether authorization is needed, but the core behavior is well covered.

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 description front-loads the core purpose, then gives a compact but complete explanation of return values and queryability. The type_kind list is lengthy but necessary because there is no output schema to carry that 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 simple one-parameter existence check, the description covers the return semantics, the queryable/non-queryable distinction, and the intended use case before read/count tools. The main missing detail is the behavior when the type does not exist, but overall the tool is sufficiently specified.

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%: type_name already has a description and an example, so the parameter is fully documented. The description adds no additional syntax or formatting guidance beyond what the schema provides, so the baseline score of 3 is 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 and resource: it checks whether a type exists in the SAP Data Dictionary and returns its kind. The description goes further by enumerating the kind values and their queryability, which clearly distinguishes this tool from the many read/search siblings.

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 to use this tool to verify whether an object is a real database table before attempting sap_read_table_data or sap_count_rows. It does not explicitly state when not to use it or name alternative type-lookup tools, but the intended context is clear.

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 provided, the description carries the full behavioral burden. It discloses that the count is estimated, that the tool returns a recommendation, and that it is intended as a pre-fetch check. It could add caveats about estimation accuracy, but the core behavioral traits are clear.

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 description is three short sentences with no filler. Purpose, usage context, output, and priority guidance are all front-loaded, and every sentence earns its place.

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 preflight tool, the description covers what it does, when to use it, what it returns, and concrete table examples. The only notable gap is that it never clarifies how the target table is identified given the empty input schema, but the rest is self-contained.

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?

There are zero parameters, so the baseline of 4 applies. The description adds meaning by explaining what the tool does with the underlying table, even though the input schema has no formal parameters to document.

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 uses a specific verb and resource: 'Estimate row count for a table' before fetching data. It clearly distinguishes this from data-retrieval siblings by emphasizing it returns a count and a recommendation rather than table contents.

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 description explicitly says to use this before querying large tables like BKPF, EKKO, and VBAK without date filters, and to check for oversized result sets. It does not explicitly name sibling tools to use instead, but the recommendation values (direct_read, use_pagination, use_streaming) imply the follow-up decision.

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 full burden. The numbered steps disclose exactly what the tool does (T100 lookup, source location, enhancement check) and explicitly states that it returns a structured diagnosis with root-cause analysis and fix suggestions. It does not mention failure modes or side-effect/read-only status, but the steps clearly imply analysis.

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 description is longer than average but highly organized: a lead-in use case, a numbered diagnostic chain, and an INPUT section. Each sentence adds information, and the all-caps 'USE THIS' and 'INPUT' signposts make it scannable.

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 tool with no output schema, it sufficiently describes the return (structured diagnosis with root cause and fixes) and covers the full workflow including fallback from text to T100. Gaps like behavior when no message is found or requiring permissions are minor given the detailed input guidance.

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 baseline is 3. The description adds valuable input-combination semantics: 'Provide EITHER message_id + message_number ... OR message_text', and clarifies transaction/program_name as optional scoping, which helps the agent choose valid parameter groups beyond the individual schema descriptions.

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 opens with 'Diagnose a SAP error/warning/info message end-to-end', naming a specific verb, resource, and scope. The numbered diagnostic chain (resolve message class/number, locate source, read surrounding code, check enhancements) clearly separates it from siblings like sap_lookup_t100 or sap_read_code, which perform only sub-steps.

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 explicitly states 'USE THIS when a user shares a SAP message — whether as a screenshot, text, or message ID', giving a clear trigger condition. It defines the input alternatives (message_id+number vs message_text) and optional scoping params, but does not name sibling alternatives or give when-not-to-use exclusions.

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 behavioral disclosure burden. It indicates this is a read-style lookup against TCDOB and that the result is an OBJECTCLAS, but it does not mention what happens when no object class is found, output formatting, or prerequisites.

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 description is two sentences with no wasted words. The core action is front-loaded in the first sentence, and the second sentence adds a useful usage condition.

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-parameter lookup tool with no output schema, the description sufficiently conveys what is returned conceptually and when the tool is appropriate. It could mention edge cases like an unknown table name, but the simple scope makes the definition adequate for 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 description coverage is 100%: the only parameter, table_name, already has a clear Data Dictionary table description and an example. The description adds context about finding the change document object class, but this contributes more to purpose than to parameter-level semantics.

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 uses a specific verb ('Find'), identifies the exact resource ('change document OBJECTCLAS for a table'), and names the underlying lookup mechanism (querying TCDOB). This clearly distinguishes it from sibling tools like sap_read_change_docs that actually read change documents.

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 description explicitly states when to use this tool: before querying change documents when the object class is unknown. It does not explicitly name the alternative tools or state when not to use it, so it falls just short of a perfect score.

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 safety/disclosure burden. It discloses that the call lists all enhancements, that the program is resolved automatically from a transaction, and the exact fields per entry (type, name, implementation, active status, program, include name). It could go slightly further (e.g., stating read-only/no side effects), but 'List' plus the output inventory is strong for a read-oriented 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?

The core action is front-loaded and every sentence carries information; the keyword list and table-name exclusions are useful, not fluff. It is slightly verbose due to the repeated examples, but remains efficiently scannable.

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 two-optional-parameter tool with no output schema, the description covers the return shape, parameter examples, and scope. It does not explicitly describe error behavior when neither parameter is supplied, but the schema description covers the 'at least one' requirement.

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 adds genuine value by giving concrete examples for both parameters ('BP', 'VA01', 'XD01', 'SAPMV45A') and explaining that program resolution is automatic. It also reinforces the 'at least one required' constraint from 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?

The first sentence states a specific verb ('List') and resource ('enhancements for a SAP transaction or program'), and enumerates the exact artifact types returned (BAdIs, customer exits, enhancement spots, BTEs). This clearly differentiates it from sibling tools like sap_read_code or sap_read_where_used.

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?

Contains an explicit 'USE THIS when' clause listing trigger keywords (BAdIs, SMOD/CMOD, SE18/SE19, BTEs, etc.) and an explicit 'DO NOT' instruction to avoid manual table queries. That is direct selection guidance rather than leaving usage 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 provided, the description carries the behavioral disclosure burden. It explains what the tool returns: field classifications, currency mappings, customer-role distinctions, status/flag filter recommendations, date fields, and currency fields. This goes beyond the name and schema, though it does not discuss side effects, auth, or rate limits; for a metadata lookup these are less critical.

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 description is dense and well-organized: a lead sentence, a scannable list of return categories, a bolded usage directive, and a clarifying example. Every sentence earns its place with no filler or repetition.

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 tool with no parameters and no output schema, the description covers what is returned and when to use it. The only ambiguity is that it doesn't state how the target SAP table is determined (e.g., explicitly vs. a currently selected context), but the rest of the guidance is sufficient for an agent to invoke 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?

The input schema is empty with zero parameters, and schema coverage is 100%, so there are no parameter semantics to clarify. The baseline for a zero-parameter tool is 4; the description adds useful context about how the returned metadata should influence query construction.

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-action ('Get enriched metadata') and a precise resource ('SAP table fields'), then details semantic classifications. The example ('use KUNAG not KUNRG') clearly distinguishes this tool from generic table-reading or structure-reading siblings.

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 explicit usage timing: 'USE THIS BEFORE building queries to understand which fields to use!' and a concrete example showing how to pick the correct field by role. However, it does not explicitly name alternatives or state when not to use this tool, so it falls 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?

With no annotations, the description carries the full burden. It clearly discloses the core behavior: comparing field domains and suggesting join keys with confidence levels. It does not explicitly state whether this is a read-only analysis or what side effects, if any, may occur, nor does it describe the output format beyond 'confidence levels'. This is adequate but incomplete.

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 description is two sentences with no fluff, and the primary purpose is front-loaded. There is slight redundancy between 'based on domain matching' and 'compares field domains', but overall it is concise and scannable.

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 tool with no output schema, the description should explain what the caller receives beyond 'join keys with confidence levels'. It does not state whether multiple candidate keys are returned, how confidence is represented, or whether the tool reads table metadata vs. actual data. Given the tool's moderate complexity and missing output schema, this is a noticeable gap, but the basic invocation parameters are clear.

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 both parameters have descriptions and examples ('EKKO', 'EKPO'). The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 applies. It does not clarify naming conventions or accepted formats, but the schema already handles the basics.

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 ('detect') and resource ('join keys between two tables'), and clarifies the method ('based on domain matching'), which distinguishes it from siblings like sap_read_foreign_keys that read actual foreign keys. However, it does not explicitly name or differentiate itself from any sibling tool, so it stops short of 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?

The description implies the tool should be used when join keys between two tables need to be inferred, but it provides no explicit when-to-use, when-not-to-use, or alternative tool guidance. Siblings like sap_read_foreign_keys or sap_analyze_query could serve related purposes, and no routing information is 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, the description carries the behavioral disclosure burden. It discloses meaningful behaviors: results are grouped by object type, wildcard package names are supported, and sub-packages can be included. It does not mention error behavior or explicitly confirm read-only semantics, but the 'List' framing and return-oriented language make the operation's nature clear.

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 concise sentences front-load the core action and output grouping, then provide use cases and advanced invocation guidance. There is no filler or redundant restatement of the schema, though the sentence listing many object types is slightly dense.

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 there is no output schema, the description appropriately explains the grouping and categories of returned objects. However, it omits the exact fields returned per object, pagination or result-limit behavior, and error handling for invalid or non-existent packages, which matters for a potentially large inventory operation.

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 parameters are already documented. The description adds some extra meaning, especially the include_subpackages=true recommendation for custom namespace codebases and wildcard examples, but it does not substantially enhance the schema's explanation of object_type_filter.

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?

Clearly identifies the verb and resource: 'List all ABAP repository objects in a development package (DEVCLASS)' and distinguishes itself as a package-level inventory tool. The use-case sentence reinforces that this is for discovery and codebase inventory, which separates it from sibling read/search tools focused on individual objects or data.

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 explicit contexts: 'discover and inventory a codebase for documentation, migration analysis, or code review' plus concrete guidance for custom namespaces using include_subpackages=true. It does not explicitly contrast with alternatives like sap_read_code or sap_read_object_details, 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?

With no annotations, the description carries the behavioral burden and does substantial work: it discloses multi-source aggregation, the S-user prerequisite for SAP Notes, and ranked output with documentation links. It omits latency/cost implications of fanning out to web search and any privacy implication of sending error text to external services, but the core behavior is transparent.

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 compact sentences, each earning its place: purpose, source list, usage timing, and return behavior. The most decision-relevant constraint ('Use this AFTER getting dump/syslog data') is front-loaded, and the prose contains no filler or redundancy.

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?

The description covers what it does, the implied input context (dump/syslog), and the return shape ('ranked results with links to documentation') in the absence of an output schema. It does not specify no-result behavior or failure modes when a source is unavailable, which would make it fully 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 coverage is 100% with well-documented parameters (including the sources enum values and the 'ME 003' error_message example), so the baseline is 3. The description reinforces source semantics by listing the same five sources and ties the context parameter to 'dump/syslog data,' but adds no syntax or format detail beyond what the schema already provides.

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 verb-resource pair ('Analyze a SAP error message') and enumerates the exact knowledge sources (T100, SAP Help Portal, web search, SAP Notes, learned patterns), making the tool's scope concrete. It further distinguishes itself from sibling data-acquisition tools by stating it is used 'AFTER getting dump/syslog data,' separating it from tools like sap_read_dumps and sap_lookup_t100.

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 explicit timing guidance ('Use this AFTER getting dump/syslog data to understand root cause'), giving an agent a clear trigger condition for when this tool is the right choice. However, it does not name exclusions or direct the agent to a specific alternative when this tool is not appropriate, stopping just short of fully explicit routing.

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 full behavioral burden. It clearly implies a read-only lookup and discloses the return content: 'full message text with placeholder descriptions.' It does not describe not-found behavior or language fallback, but for a simple lookup tool this is a minor gap.

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 description is three concise sentences, each adding distinct value: the operation, the trigger scenario, and the expected return. It is front-loaded with the primary purpose and contains no filler or redundant phrasing.

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 three-parameter lookup tool with no annotations and no output schema, the description is nearly complete: it answers what the tool does, when to use it, and what it returns. The missing pieces are explicit sibling differentiation and behavior when the message is not found, but these are relatively small given the tool's simplicity.

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 schema already covers all three parameters with descriptions, patterns, and constraints (100% coverage). The description adds useful examples of message codes and identifies the two key parameters, but it does not provide substantial semantic value beyond what the schema already documents, so the baseline score of 3 is 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?

The description clearly states the action ('Look up a specific SAP T100 message') and the identifying fields (message class and number), with concrete examples. It is specific about the resource, but it does not explicitly differentiate from sibling tools like sap_lookup_error or sap_diagnose_message, so the agent must infer the distinction.

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 description gives explicit trigger conditions: use when a message code like 'ME 003' or 'MM 001' appears in error messages, dumps, or syslog entries. It does not mention alternative tools or state when not to use this tool, but the guidance is clear and contextually sufficient.

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 provided, the description carries the full burden, and it delivers: it discloses the requires_confirmation flow for >1000 rows, the timeout risk of querying full master tables without depends_on, and that fields are validated against table structure. It even warns against a common failure mode (KNA1 returning 100K+ customers) and prescribes the behavior of asking the user before showing large results.

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 description is long but densely packed and clearly marked (SUPPORTS AGGREGATION, IMPORTANT, CRITICAL, NOTE, Example), front-loading the purpose before operational warnings. Nearly every section earns its place given the tool's complexity, though the aggregation intro slightly duplicates what the schema already documents.

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 highly complex tool with nested query_plan objects and no output schema, the description thoroughly covers query planning pitfalls, confirmation behavior, and field discovery. The main gap is that it never describes the successful response format (structure of merged results), and it doesn't differentiate itself from the similarly named sap_smart_table_query sibling — though the coverage of operational essentials is strong enough that agents can 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 coverage is 100%, so the baseline is 3, but the description adds strategic meaning beyond the schema's parameter docs: it explains why depends_on/filter_field exist (avoiding timeouts) with a concrete KNA1 example, clarifies when confirmed should be set (only after user consent), and shows the sort_by+sort_order+limit pattern for recency queries. This elevates it to 4, though individual parameter details still live mostly in 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?

The description states a specific verb-resource pair ('Execute a multi-table query with proper joins and optional aggregation') and a crisp scope criterion ('data from 2+ tables that must be merged'). It explicitly differentiates from the key sibling tool: 'Use this instead of multiple sap_read_table_data calls when you need joined data!'

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 explicit when-to-use guidance ('Use this when you need data from 2+ tables that must be merged'), names the alternative (sap_read_table_data), and gives conditional routing rules: use aggregation for 'top N' queries, use depends_on/filter_field for master data lookups, and use sort_by+sort_order+limit instead of confirmed=true for 'last N' requests. No ambiguity about when this tool applies.

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 delivers: it discloses the read-source, patch, write-back flow, the exact-match requirement, and the automatic application of ECC 6.0 auto-fixes and comment stripping. A minor gap is that it describes the tool as working on 'existing' objects while the schema's short_text parameter hints at creation for non-existent objects, and it does not specify failure behavior when old_text is not found.

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, followed by scope, mechanics, and a critical warning. There is minor redundancy between 'Reads the current source, applies search/replace operations, and writes back only the changes' and 'The source is read from SAP, patched in Python, and written back via the gateway,' but every sentence contributes useful context.

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 mutation tool with no output schema, the description covers the core workflow, supported object types, replacement semantics, and prerequisites. It leaves some ambiguity around non-existent object handling and what happens if an old_text match fails, but the guidance to read source first mitigates that risk.

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 meaningful parameter semantics by explaining that replacements are old_text/new_text pairs requiring exact matching, and it provides class-specific examples (replace method implementations, add methods, change definitions). This materially helps an agent construct valid replacements.

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 ('Apply delta modifications'), a clear resource ('existing ABAP programs or classes'), and an explicit scope ('PROG, INCL, and CLAS'). It differentiates itself from siblings by emphasizing 'without sending full source', which positions it against sap_write_code and sap_write_code_safe.

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 clearly indicates when to use the tool: for targeted modifications rather than full rewrites, and it explicitly instructs to use sap_read_code first to obtain exact source. It does not state when not to use it or name alternatives for full writes, but the context is otherwise strong.

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 behavioral burden. It discloses the read-only nature ('Query'), the source tables (CDHDR/CDPOS), and the output intent ('who changed what data and when'), but omits authorization requirements, response shape, and edge-case behavior. The absence of annotations makes these gaps notable, though the tool's safe read intent is at least implied.

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, no filler: the first front-loads the verb, resource, and output value, and the second gives a clear prerequisite. Every sentence earns its place.

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 7-parameter, no-output-schema tool with no annotations, the description covers the core purpose, source tables, return concept, and a mandatory-looking prerequisite. It doesn't explain the difference from sap_read_change_docs_v2 or discuss what happens when no object_class is supplied, but the schema already documents parameter details.

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 value by telling the agent to use sap_discover_change_object to obtain the correct OBJECTCLAS, which directly aids the object_class parameter; it also suggests the broader table context for object_id and object_class.

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 opens with a specific verb+resource: 'Query change documents from CDHDR/CDPOS tables', and clarifies the value with 'Shows who changed what data and when.' It is clearly not a tautology and easily tells the agent what the tool does, though it does not explicitly differentiate from the sibling sap_read_change_docs_v2.

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 explicitly instructs 'Use sap_discover_change_object first to find the correct OBJECTCLAS', giving actionable workflow guidance and naming a related tool. It does not, however, state when this tool is preferable to sap_read_change_docs_v2 or list exclusions.

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 full burden. It only says 'query using function modules' and 'optimized,' which implies a read operation and some performance benefit, but does not disclose return shape, side effects, authorization needs, or limits beyond what the schema shows. This is minimal for a tool with no annotation support.

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 short sentence with front-loaded verb and resource, then a differentiator and a preference. No filler; every phrase earns its place.

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 an 8-parameter tool with no output schema, the description is functionally complete for selection but thin on what the returned data looks like. The schema fills parameter details, and the purpose/preference are clear, so it is adequate but leaves return-structure guessing.

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 baseline is 3. The description adds emphasis on tabname filtering, but does not enrich parameter semantics beyond what the schema already provides.

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 ('query') and resource ('change document') and explicitly positions itself as the optimized/preferred variant over the legacy endpoint, which distinguishes it from sibling sap_read_change_docs. The mention of 'using function modules' and 'additional filtering by table name' further clarifies scope.

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 'Preferred over legacy endpoint,' telling the agent to choose this over the older change-doc endpoint. It also highlights the additional table-name filter as a selection factor. It does not name the legacy sibling or give exclusion conditions, so not 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?

No annotations are provided, so the description carries the full behavioral transparency burden. It explicitly discloses conditional behavior: requesting INACTIVE falls back to ACTIVE with fallback_reason='no_inactive_version', and the response includes a version field. This is non-obvious and valuable.

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 description is three sentences, tightly focused, and front-loaded with the main purpose. Each subsequent sentence adds meaningful behavioral detail without redundancy or fluff.

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?

Given there is no output schema, the description usefully mentions the version field in the response but does not specify other return fields such as the actual source code field. For a read-only tool with simple object identification, this is nearly complete, but a bit more return-structure detail would make it fully self-contained.

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 schema already documents all three parameters with 100% coverage, including enums, defaults, examples, and detailed fallback behavior. The description largely restates the version semantics rather than adding new parameter meaning, so 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?

The description clearly states a specific verb and resource: 'Retrieves the source code of an ABAP object', and enumerates the object types (program, class, function group). It distinguishes itself from other read tools by focusing specifically on source code rather than metadata, objects, or data.

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 description makes the tool's context clear: when you need ABAP source code, and it explains version selection semantics. It does not explicitly name alternative tools (e.g., sap_read_object_details) or provide when-not-to-use guidance, but the context is evident enough for an agent.

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 burden for behavioral disclosure. 'Retrieves' conveys a read-only intent, but the description does not mention output shape, empty-result behavior, error handling, or any prerequisites beyond the domain name. Basic behavior is present, but detail is limited.

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 description is two sentences with no filler. The first sentence front-loads the action, and the second adds practical use-case context without repeating schema information. Every sentence earns its place.

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 one-parameter read tool, the description is mostly sufficient, but the sibling tool sap_read_field_domain_values creates ambiguity that this description does not resolve. There is also no output schema, and the description does not clarify exactly what the returned fixed values look like or whether an invalid domain causes an error.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes domain_name fully, including an example value (MTART), so schema coverage is 100%. The description adds no extra parameter-level guidance beyond the schema, 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?

The description states a specific verb and resource: it retrieves fixed values defined for a domain, and gives concrete examples like material type and document type. However, it does not differentiate this tool from the similarly named sibling sap_read_field_domain_values, so it is clear but not fully distinguishing.

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 description explicitly frames when the tool is useful: understanding valid values for fields such as material type or document type. It does not name alternatives or exclusions, so it stops short of a 5, but the usage context is clear rather than merely implied.

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 full burden. It discloses what the tool returns (full error texts, cause, solution) and implies a read-only drill-down operation. However, it does not mention side effects, auth requirements, failure behavior, or what happens when no matching dump is found.

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 with no waste. The first sentence front-loads the tool's purpose and return content; the second provides actionable usage guidance. Every sentence earns its place.

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 tool with no output schema and no annotations, the description covers the key operational needs: what it does, what it returns, when to use it, and how to source parameters. It is slightly incomplete around edge cases like missing dumps or language fallback behavior, but overall an agent can select and invoke 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?

The input schema already documents all six parameters with examples and source references, giving a baseline of 3. The description adds value by telling the agent to pass date, time, user, server, and error_id directly from sap_read_dumps results, clarifying that these are pass-through values rather than independently constructed inputs.

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 resource: 'Get detailed information for a specific short dump including full error texts, cause, and solution.' It explicitly frames this as a drill-down after sap_read_dumps, distinguishing it from sibling list/search 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?

It clearly says to use this after sap_read_dumps to drill into a specific dump and instructs the agent to pass parameters directly from sap_read_dumps results. It does not name alternative error-handling tools like sap_lookup_error, but the sequencing guidance is clear enough for correct selection.

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 provided, the description carries the burden of behavioral disclosure. 'Query' implies a read operation, and the listed return fields provide useful context. However, it does not disclose potential limitations, authentication needs, result ordering, or behavior around the optional date/max_rows parameters.

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 description is two sentences with no filler. It front-loads the primary action and source system, then lists the key returned fields. Every sentence earns its place.

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 read-only query with four optional parameters and no output schema, the description gives a reasonable overview and lists return fields. Still, it omits usage guidance and any behavioral caveats, and the existence of sap_read_dump_details suggests a distinction that is not clarified.

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 four parameters are already documented in the input schema. The description adds general output context but does not explain parameter semantics beyond what the schema already provides, so the baseline 3 is 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?

The description clearly states the tool queries ABAP runtime errors (short dumps) from SAP's ST22 transaction, with a specific verb and resource. However, it does not explicitly differentiate itself from the sibling sap_read_dump_details, so the distinction between listing dumps and reading dump details is left to inference.

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 description explains what the tool does but gives no guidance on when to use it instead of related tools such as sap_read_dump_details or sap_lookup_error. No when-to-use or when-not-to-use conditions are provided.

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 burden of behavioral disclosure. It clearly indicates a read-only retrieval operation and states the output includes field lists, but it does not describe the response format, potential size, or any edge cases. For a simple read tool this is minimally adequate, but it lacks richer 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?

The description is a single sentence with the action and primary object front-loaded, and it contains no filler or redundant details. It earns its place as an efficient summary for a simple tool.

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?

The tool has no output schema and no annotations, so the description must carry more weight. It gives a basic summary of what is retrieved but omits usage context, distinction from sibling read tools, and any indication of the returned structure beyond 'field lists'. It is usable but thin.

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 schema already documents object_name and object_type. The description adds no parameter-level detail beyond what the schema provides; it only loosely says 'program' even though object_type allows PROG, CLAS, and FUGR, which the schema clarifies.

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 uses a specific verb ('Retrieves') and names a distinct resource ('screen definitions for a program including field lists'), so an agent can tell it returns dynpro screen metadata rather than code or table data. It does not explicitly contrast it with sibling tools like sap_get_field_metadata, but the resource is clear enough.

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 intended use is implied by the description—use it to get screen definitions—but there is no explicit guidance about when to prefer it over alternatives or when not to use it. No exclusions, prerequisites, or sibling comparisons are provided.

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 behavioral disclosure burden. It clearly conveys the key behavior: the tool resolves the domain automatically rather than requiring it as input. It does not discuss edge cases such as fields without domains or fixed values, but for a read-only lookup the core behavior is adequately disclosed.

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 description is two sentences with no filler. The primary purpose is front-loaded, and the differentiating detail about automatic domain discovery is placed in the second sentence. Every word earns its place.

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 two-required-parameter read tool, the description is nearly complete: it explains what the tool returns, the input context, and how it differs from its nearest alternative. It does not specify the exact output shape or empty/error behavior, but 'domain fixed values' and the tool name provide sufficient context for 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 100%, so the baseline is 3. The description adds the semantic link that field_name is used to discover the domain automatically, which enriches the terse schema descriptions, but it does not provide additional format, casing, or constraint details beyond the schema and examples.

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 ('Get domain fixed values') and a specific resource ('a specific table field'). It also explicitly distinguishes itself from the sibling sap_read_domain_values by noting that this tool finds the domain automatically from the field, so the agent can tell them apart.

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 description explicitly frames when to use this tool: when you have a table field and want its domain fixed values, versus the alternative that requires the domain name. This gives clear selection criteria relative to the most similar sibling.

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 full burden of behavioral disclosure. It identifies the source (DD08L) and the outcome, but it does not describe response format, error behavior, permissions needed, or whether the returned relationships include field-level details. This leaves a meaningful gap for a tool whose behavior the agent cannot infer from 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?

The description is two short sentences with no filler. The core action and source are stated up front, and the value ('shows which tables are related and can be joined') follows directly. Every phrase earns its place.

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 one-parameter read-only tool with no output schema, the description is largely complete: it names the input, the source dictionary table, and the resulting information. It would benefit from a brief note on what the output contains (e.g., 'returns related table names and field pairs'), but the current level is adequate for tool selection and 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 100%, including an example ('MARA') and a description ('Data Dictionary table name'), so the schema already documents the only parameter. The description adds a small amount of context by connecting the parameter to foreign-key-relationship lookup, but does not need to compensate for any missing schema information.

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 clearly states a specific verb ('Read') and resource ('foreign key relationships for a table from Data Dictionary (DD08L)'). It also explains the practical purpose—showing which tables are related and joinable—which distinguishes it from sibling tools like sap_read_table_structure or sap_infer_joins.

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 description implies the tool is appropriate when an agent needs to discover related tables or determine joinability, but it does not explicitly state when to use this tool versus alternatives such as sap_infer_joins or sap_get_field_metadata. There is no whether-not guidance, so the usage context is only inferred rather than explicit.

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 provided, the description carries the full burden. It clearly indicates a read-only retrieval of source code but adds little beyond that: it does not clarify whether includes are listed by name, whether source is returned in full, or whether nested include chains are included. The verb 'Retrieves' is transparent enough to avoid confusion, but only minimally.

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 description is a single, front-loaded sentence with no filler. It conveys the core operation and the returned content efficiently.

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 two-parameter read tool with full schema coverage, the description is nearly complete: it names the resource and the returned source code. The main gap is not clarifying how the object_type values map to the term 'program', but this is a minor omission given the schema enum.

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 schema already documents both parameters fully. The description does not add parameter-specific meaning beyond the schema, which keeps it at the baseline 3.

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 clear action ('Retrieves') on a specific resource ('all include files... with their source code'), which differentiates it from sibling tools like sap_read_code. However, it refers to 'a program' while object_type allows CLAS and FUGR, introducing slight ambiguity for those object kinds.

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 description gives no guidance on when to prefer this tool over alternatives such as sap_read_code or sap_read_object_details, and it does not mention exclusions or prerequisites. Usage context must be inferred entirely from the tool name and resource phrasing.

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 provided, the description carries the burden of behavioral disclosure. 'Query' and 'Returns' clearly signal a read-only operation and indicate that no mutation is involved. It does not mention authorization or rate limits, but these are less critical for a query tool with obvious read semantics.

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 description is two tight sentences with no wasted words. The action and source are front-loaded, followed by a concise statement of what the tool returns.

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 an optional-parameter read tool with a fully documented schema, the description provides sufficient context about the tool's purpose and output. It does not go deep into edge-case behavior or explicitly compare against sibling tools, but nothing critical is missing for selecting and invoking the 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?

The input schema already provides 100% coverage, including descriptions, examples, defaults, and an enum for status. The description adds high-level context about returned job information but does not need to restate parameter details because the schema fully documents them.

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 clearly identifies the operation as querying background job information from SAP's SM37 transaction. It names the specific resource and the types of data returned, so an agent can distinguish it from general table-read and diagnostic 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?

The description makes the context obvious: use this tool when background job information is needed, such as job status, execution times, or scheduling details. It does not explicitly name alternatives or exclusions, but the purpose is specific enough to guide selection among the many sibling SAP tools.

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 full behavioral disclosure burden. It states that the tool returns structured data including descriptions, field definitions, relationships, and metadata, which is useful. However, it does not mention permissions, failure behavior, output size, or the read-only nature beyond the tool 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?

The description is dense but every sentence earns its place: a clear opening, a complete list of supported types, and an explicit routing to sap_read_code. It could be slightly better structured with bullets, but it is not padded or redundant.

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?

Given there is no output schema, the description reasonably explains the return categories and per-type behavior. It is sufficient for an agent to call the tool with the required object_type and object_name, though it does not fully specify response shape or edge cases.

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 schema already covers both parameters at 100%, but the description adds meaningful context by explaining what each object type offers, such as domains with fixed values, transactions with linked programs, and message classes with all messages. This goes beyond the bare enum values and helps an agent select the right object type.

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 clearly states the tool reads comprehensive details about SAP repository/DDIC objects and enumerates exactly which object types are supported. It also explicitly differentiates itself from sap_read_code for source code objects, so an agent can distinguish it from closely related siblings.

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 description gives explicit guidance for source code objects: use sap_read_code instead. It also implies when this tool is appropriate by listing all supported object types. However, it does not address potential overlap with other metadata-reading siblings such as sap_read_object_info or sap_read_table_structure.

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 verb 'Get' and the listed metadata fields signal a read-only lookup and give a preview of the output content. However, annotations are absent, so the description carries the full burden and does not address not-found behavior, authorization requirements, or response format.

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 description is a single, front-loaded sentence with no filler. Every phrase earns its place, naming both the operation and the key output 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 simple two-parameter tool with full schema coverage, this is mostly adequate, and it lists the salient return fields despite having no output schema. It is incomplete only in that it does not disambiguate from sap_read_object_details or describe behavior when the object is missing or inaccessible.

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?

Both parameters are fully documented in the schema, including the object_type enum and object_name's example and case-insensitivity. The description adds no parameter-level meaning beyond the generic phrase 'ABAP object,' so it meets the schema-coverage baseline without exceeding it.

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 clear verb-resource pair ('Get metadata about an ABAP object') and names specific returned fields (creation date, last changed date, author, package). It does not differentiate from the similarly named sibling sap_read_object_details, which could plausibly overlap in intent.

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?

No guidance is given on when to use this tool versus alternatives. With sap_read_object_details and other read tools among the siblings, an agent must rely on name inference rather than explicit usage direction.

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 behavioral disclosure burden. It conveys a non-destructive read operation through 'Query' and 'Shows', and specifies the type of entries returned. However, it does not mention authentication needs, date-range behavior, pagination, max_rows enforcement, or whether the log is system-wide, though the lack of mutation makes this less critical.

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 description is two short sentences with no filler. It front-loads the core action and resource, then adds relevant output content. Every word earns its place.

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?

The description plus a fully documented optional-parameter schema is enough to make a basic call, but there is no output schema and no guidance on return format, limits, or when to prefer this over similar read tools. In a large sibling set, the lack of routing and return-shape context leaves the description only minimally 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 100%, with each parameter having a clear description, example, and defaults where applicable. The tool description itself adds no parameter-level detail, but does not need to because the schema already provides sufficient semantic context.

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 explicitly states the verb 'Query', the resource 'system log entries', and the source transaction 'SM21'. It also indicates the result content ('system events, warnings, and errors'), making it clearly distinguishable from sibling tools like sap_read_dumps or sap_read_jobs.

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 description gives no guidance on when to use this tool versus the many sibling read/query tools. It does not mention alternatives, exclusions, or conditions such as 'use read_dumps for short dumps'. Usage context is only implied by the resource being queried.

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?

There are no annotations, so the description carries the full behavioral burden. It discloses the non-obvious confirmation flow: >1000 rows returns 'requires_confirmation' with a preview and requires a follow-up call with confirmed=true. It also signals read-only semantics via 'Reads,' though it does not describe return structure or pagination.

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 paragraphs are tightly scoped: purpose and size guidance first, followed by the critical confirmation rule. Every sentence earns its place, and there is no redundant 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 read tool with six parameters, no annotations, and no output schema, the description covers the key operational nuance: the 1000-row confirmation contract. It would be slightly stronger if it explicitly pointed to paginated or streaming siblings for large datasets, but the provided guidance is adequate for correct 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 description coverage is 100%, so the schema already documents all six parameters. The description adds only high-level mention of WHERE filtering and metadata inclusion, which overlaps with the schema rather than adding deeper parameter semantics.

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?

'Reads actual data from a SAP table' pairs a precise verb with a concrete resource and clearly states optional filtering and metadata behavior. The 'small to medium datasets' scope differentiates it from larger-volume siblings like sap_read_table_paginated and sap_stream_table_data.

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 description gives an explicit use condition ('small to medium datasets, up to a few thousand rows') and a required workflow for >1000-row results. It does not name alternative sibling tools for larger datasets, so the when-not-to-use guidance is only implied rather than explicit.

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 behavioral burden and does reasonably well: it discloses ABAP WHERE syntax support, field validation against table structure, and the audit_mode all-records behavior. It leaves out pagination/default row limits and return shape, but those gaps are less critical for a clearly read-oriented query 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?

The description is compact, front-loaded with the core action, and every sentence earns its place: examples, syntax support, audit behavior, validation, and a field-discovery prerequisite. There is no filler or repetition.

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 table-read tool with no output schema and no annotations, it covers a lot: what kinds of data, filter syntax, validation, and audit mode. It is incomplete because it does not route the agent among the similar sibling read tools, nor reconcile the missing parameter schema, so the agent still needs external help 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?

The description adds meaning by naming audit_mode=true and field_list/WHERE clause behavior, but the input schema is literally empty, so none of these are expressed as callable properties and no table-name parameter is defined. An agent reading this description could guess the intent but cannot construct a valid invocation from the definition.

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 opens with a clear verb+resource ('Query data from an SAP table') and adds concrete SAP table examples, so an agent knows what it operates on. It does not explicitly contrast itself with sibling tools such as sap_read_table_data or sap_read_table_paginated, so it stops short of a full 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?

It gives useful usage context: optional WHERE filtering, audit_mode for ALL records, and a recommendation to call sap_get_field_metadata or sap_read_table_structure first. It never states when this enhanced read should be chosen over the many sibling table-read tools or when it should not be used.

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 discloses meaningful behavior: pagination via offset and limit, validation of fields against table structure, and row-count recommendations. Since no annotations are provided, the description carries the full burden, but it omits error behavior, response format, and potential rate/auth limitations, so it is only partially transparent.

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 description is compact, front-loaded with the core purpose, and every sentence adds useful information: pagination mechanics, row-count recommendation, streaming alternative, field validation, and discovery prerequisites. There is no filler or redundancy.

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?

Despite good purpose and usage guidance, the description is not complete enough for reliable invocation: the input schema defines zero parameters while the description references offset, limit, WHERE clause, and field_list, leaving an unresolved contract gap. There is also no output schema or description of the paginated response shape, so the agent cannot fully anticipate the tool's behavior.

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 input schema is empty, so the description carries the entire parameter burden and does name the key parameters: offset, limit, WHERE clause, and field_list. It explains their high-level purpose but does not specify types, requiredness, or exact syntax, which prevents a higher score.

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 clearly states a specific action ('Read table data with pagination support') and a resource, and it distinguishes this tool from streaming alternatives by recommending it for tables with 500-5000 rows. The large-result-set scope and pagination focus make it easy to tell apart from sibling tools like sap_stream_table_data.

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 description gives explicit selection guidance: it is recommended for 500-5000 rows, and larger tables should consider streaming. It also advises using sap_get_field_metadata or sap_read_table_structure first, which is a useful prerequisite. However, it does not explicitly say when to choose this over the other non-streaming table-read 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 provided, so the description carries the full burden of behavioral disclosure. It communicates that the tool retrieves metadata, but it does not explicitly state whether this is read-only, whether special authorizations are required, or any other operational characteristics such as errors or limits.

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 description is a single focused sentence with no filler. It front-loads the core purpose and immediately lists the useful contents of the response, making it easy for an agent to understand.

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 one-parameter metadata retrieval tool without an output schema, the description is reasonably complete: it names the resource and enumerates the key return elements. It does not discuss error cases or permissions, but these are not critical for such a straightforward read operation.

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 schema already fully documents the single parameter, table_name, including its type, example, and description. The tool description adds no extra parameter-level meaning, so the schema coverage 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 ('Retrieves') and resource ('metadata of a Data Dictionary table'), and enumerates the returned content: field definitions, data types, keys, and descriptions. This clearly differentiates it from data-reading siblings like sap_read_table_data by focusing on metadata only.

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 description implies the tool is for inspecting the metadata/structure of a table rather than reading its rows, which provides some usage context. However, it does not explicitly mention alternatives such as sap_get_field_metadata or sap_read_table_data, nor any when-not-to-use 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?

No annotations are provided, so the description carries the disclosure burden. 'Retrieves' clearly signals a non-mutating read, and the parenthetical tells the agent what kind of data is returned. Still, it does not mention permissions, language behavior, output shape, or how CLAS/FUGR objects are handled despite the 'program' framing.

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 description is a single front-loaded sentence with no filler. The parenthetical adds specificity about text element subtypes without bloating the 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?

For a two-parameter tool with full schema coverage, the core operation is clear. However, there is no output schema and the description does not explain what the result contains or how to interpret text elements, and the 'program' wording conflicts with the broader object_type enum. Some ambiguity remains for an agent deciding whether this fits the task.

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 input schema already documents both parameters and the enum for object_type. The description adds no additional parameter-level meaning, such as clarifying that CLAS and FUGR are also valid despite the word 'program.' Baseline 3 is appropriate given the rich 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?

The description uses a specific verb ('Retrieves') and names the concrete resource ('text elements'), with the parenthetical clarifying sub-types (selection texts, text symbols). However, it says 'for a program' even though the schema allows CLAS and FUGR, and it does not explicitly distinguish this from the many sibling read 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?

No guidance is given on when to use this tool versus alternatives such as sap_read_translations, sap_read_code, or sap_read_dynpros. The intended use is only implicit from the description, with no stated exclusions or selection criteria.

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 provided, the description carries the behavioral disclosure burden. It clearly states the operation is a read, explains the optional target-language behavior, and lists the return contents (text IDs, source texts, existing target translations, max lengths). It could mention absence of mutation or error behavior, but for a read tool this is reasonably transparent.

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 description is information-dense without redundancy. It front-loads the core purpose, follows with the SE63 equivalence, lists supported types compactly, and closes with return value details. Every sentence contributes useful selection or invocation guidance.

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?

Given there is no output schema and no annotations, the description compensates well by covering purpose, supported object types, optional target language behavior, and return values. It could be slightly more complete by noting what happens when no translations exist or whether the operation is strictly read-only, but the essentials are present.

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 parameters are already documented well. The description adds value beyond the schema by detailing what each object_type semantically covers (e.g., PROG text pool, CLAS descriptions plus text pool, CUAD function texts/titles/menus), helping agents choose appropriate object types.

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 ('Reads translatable texts from a SAP object'), names the resource, and adds a useful analogy to SE63. It enumerates supported object types with concrete meanings, so an agent can immediately understand scope and distinguish it from broader read 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?

The description implies usage context: reading source and optional target translations from known SAP object types. However, it does not explicitly say when to prefer this tool over sibling tools like sap_read_texts, sap_translate, or sap_write_translations, nor does it provide exclusions or alternative conditions.

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 disclosure burden. It states the source table and the output content ('which users are locked and their last login information'), and 'Query' implies read-only. However, it does not mention output format, defaults, or caveats.

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 description is a single sentence with no filler. It front-loads the action and clearly states what the tool returns.

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 read tool with three well-documented optional parameters, this is adequate but not complete. There is no output schema, and the description only partially explains return information, nor does it help the agent choose between this and sibling read tools in a clear usage context.

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%, with each parameter having a meaningful description and example. The tool description adds no parameter-specific semantics, so the 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?

Description uses a specific verb 'Query' and a specific resource 'user lock status from USR02 table'. It clearly differentiates this tool from generic siblings like sap_read_table_data or sap_read_syslog.

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?

No explicit guidance is given about when to use this tool versus alternatives such as sap_read_table_data or sap_diagnose_message. The purpose is implied, but there are no when/when-not statements or alternative routing.

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 provided, the description carries the full behavioral burden. It discloses the underlying tables, the forward/inverse behavior, and the 'Where-Used List' equivalence. The explicit warning about timeouts on tables like MARA, KNA1, and LFA1 adds valuable performance context. It does not detail return format or pagination, but the query nature is clear.

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 plus a critical warning, with no redundancy. The core purpose and direction semantics are front-loaded, and the timeout warning is placed at the end where it serves as an actionable note. Every sentence earns its place.

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?

Given there is no output schema and no annotations, the description provides enough context to understand what the tool does and how to avoid common failures. It explains the result concept ('what objects use a given object' or 'what a given object uses') and covers the important performance caveat. It could be more complete with explicit return-value or pagination details, but the current coverage is adequate.

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 input schema covers all five parameters with descriptions and examples, so baseline is 3. The description adds value beyond the schema by explicitly warning that name_filter should be used for heavily-used tables like MARA to avoid timeouts, which is non-obvious operational guidance.

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 verb ('Queries'), a resource (SAP's cross-reference tables WBCROSSGT/WBCROSSI), and a well-known SAP concept ('Where-Used List'). It clearly defines forward vs inverse semantics, making it easy to distinguish from generic SAP read tools like sap_read_object_details or sap_search_tables.

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 description implies when to use the tool by explaining it queries cross-reference tables and provides a timeout-avoidance guideline for heavy tables. However, it does not explicitly state when not to use it or compare it with sibling tools, so the agent has to infer the boundary from the function name and description.

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 so impressively. It discloses the extended timeout, the automatic fallback to an SM37 background job, the polling behavior, and the critical caveat that the fallback returns only the job's final status, not output. It also surfaces the selection-parameter limitation. This is far beyond typical behavioral disclosure.

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 description is well-structured and front-loaded with the core purpose. The timeout/fallback behavior, parameter notes, and limitation are each relevant. Some parameter explanations are redundant with the schema, but the overall length remains reasonable and every sentence contributes to safe invocation.

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 tool with no output schema, the description explains the normal return type (text lines) and the fallback return behavior (job status only). It also notes that spool output must be read separately. It could be slightly more explicit about how to retrieve the spool output or about potential side effects, but given the tool's complexity, it is substantially 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 coverage is 100%, so the baseline is 3. The description adds value by explicitly explaining the variant-only execution model and the implication that individual selection parameters cannot be supplied. It repeats a bit of what the schema already says about 'report' and 'variant', but the limitation note meaningfully enhances understanding.

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 ('Execute an ABAP report program (SUBMIT)') and a specific outcome ('return its list output as text lines'). It clearly distinguishes this from the many read-centric siblings and from sap_run_transaction, making the tool's purpose immediately identifiable.

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 description gives clear context for when to use the tool: to run an ABAP report and get its list output. It also notes an important limitation (cannot pass individual selection parameters, only variant-based execution). However, it does not explicitly mention alternatives or when not to use it, such as pointing to sap_run_transaction for transaction execution.

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 behavioral disclosure burden and does it well. It discloses the TSTC resolution mechanism, extended timeout with background-job fallback, list output, and the important limitation that only report transactions are supported. It does not detail error behavior or side effects of running arbitrary reports, but it provides meaningful 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?

The description is reasonably sized and front-loaded with the core behavior, followed by mechanism, parameters, and the limitation. The parameter explanations are slightly redundant with the schema, but they are concise and the limitation is clearly separated, so 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?

Given no annotations and no output schema, the description covers the key operational context: what it runs, how it resolves the transaction, the fallback behavior, the variant prerequisite, and the limitation on transaction types. It is complete enough for an agent to decide whether and how to invoke it, though exact output structure is not specified.

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 baseline is 3, but the description adds value beyond the schema. It clarifies that tcode is required, explains that variant is a selection-screen variant for programs with mandatory fields, and links variant creation to sap_save_variant. max_output_lines is not repeated in the description, but the schema already covers it adequately.

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 opens with a specific verb and resource: 'Run the ABAP report behind a report transaction code... and return its list output.' It clearly distinguishes this tool from sap_run_program by explaining that it resolves the transaction to its program via TSTC and then runs it like sap_run_program.

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 description gives clear context: report transactions can be run headlessly, pure dialog transactions are not supported, and variants should be created with sap_save_variant for mandatory fields. It does not explicitly state 'use sap_run_program instead when you already have a program name,' but the relationship to sap_run_program and the limitation on transaction types provide strong usage direction.

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 provided, the description carries the full behavioral burden. It explicitly discloses the overwrite-capable side effect, the optional environment default, and related read/delete operations. It does not mention permissions or failure modes, but the core mutation behavior is clearly stated.

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 description is dense but well organized: purpose first, then parameter list, then related operations. It repeats some schema details, but every section earns its place and there is no fluff.

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?

Given the absence of annotations and output schema, the description covers the key aspects: creation/overwrite semantics, required vs optional parameters, parameter structure, default values, and how to read/delete variants afterward. It omits return-value details, but the tool is primarily a write operation.

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 schema already documents every parameter and nested key. The description largely restates this information, adding only light context about being selection values and reuse. Since the schema does the heavy lifting, a baseline of 3 is 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?

The description states a specific action ('Create or overwrite an ABAP selection-screen VARIANT') on a concrete resource, and immediately ties it to reuse by sap_run_program. This clearly distinguishes it from the large set of sap_* siblings, most of which are read/query 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?

It explains when this tool is relevant: for reports whose selection screen has mandatory fields and for use with sap_run_program, performance traces, or headless runs. It also gives alternatives for reading and deleting variants, though those are via sap_call_function rather than a listed sibling.

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 provided, the description carries the full burden, and it does a solid job: it discloses that the tool fetches an external public GitHub policy, compares against installed components (CVERS), and invokes /classify_note_v2 for affected notes. It also explains priority semantics and the default month. It does not mention potential side effects or external network dependency, but for a scanning/read-oriented tool this is reasonably transparent.

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 description is dense but well-structured: it opens with the core purpose, then explains the underlying process, then clarifies parameter behavior. Every sentence adds useful information and there is no filler or repetition of the tool name.

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?

Given there is no output schema, the description does not fully specify the return format, but it does say the notes are ranked by relevancy and classified, which gives a reasonable expectation. The tool is moderately complex (external fetch, cross-system comparison, classification), and the description covers the main steps and user-facing parameters. It is not missing any critical invocation information.

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 input schema already covers all three parameters with descriptions and defaults, so the baseline is 3. The description mostly restates the schema's parameter meanings, adding only a light clarification of the priority range (1=HotNews .. 4=Low). It does not add new semantic detail beyond what the schema provides.

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 clearly states a specific verb ('Discover ... and rank') and a concrete resource ('ABAP Security/HotNews notes for a SAP patch-day month'). It also explains the mechanism (fetching a public policy, comparing fixed-in levels to CVERS, classifying via /classify_note_v2), which gives a precise sense of scope. It does not explicitly contrast with the sibling sap_check_notes_relevancy, but the purpose is unambiguous on its own.

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 description makes the intended use case clear: scanning a patch-day month and ranking security notes by relevance to the current system. It also explains parameter-driven behavior such as min_priority and month defaults. It does not explicitly say when to prefer this over sap_check_notes_relevancy or list exclusions, but the context is strong enough for an agent to select it appropriately.

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 behavioral disclosure burden. It usefully reveals that the tool queries SAP Help Portal and public community sources, which implies a read-oriented external search. However, it does not mention what the response contains, whether there are rate limits, whether authentication is needed, or any other operational caveats.

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 description is compact and front-loaded: the first sentence states the action, the second adds specific sources, the third gives use cases, and the fourth provides the crucial distinction from sap_lookup_error. Every sentence earns its place 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?

For a two-parameter search tool with no output schema, the description covers purpose, sources, use cases, and exclusion criteria well. The only notable omission is the shape or format of returned results, but the description is otherwise sufficient for an agent to decide whether and how to invoke the 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 100%, with clear descriptions and examples for both query and max_results. The description adds no new parameter-level detail, but none is needed because the schema already documents meanings, defaults, and constraints.

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 opens with a specific verb and resource: 'Search SAP documentation and community for information on any SAP topic.' It names concrete sources and explicitly contrasts itself with sap_lookup_error, making the tool's identity and scope immediately clear.

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 description states when to use it ('research SAP concepts, find best practices, or look up configuration guides') and when not to use it ('not specific error messages'), directly naming the sibling alternative sap_lookup_error. This gives an agent strong selection 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 behavioral disclosure burden. It clearly indicates a search operation returning metadata (names and descriptions), but does not disclose search matching semantics, case-sensitivity, or default result limiting behavior (max_results is left to the schema).

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 no filler; action and output are front-loaded. Every word earns its place.

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 two-parameter search tool with a fully documented schema, the description provides the essential outcome (table names and descriptions). It stops short of naming alternatives or search edge cases, but the core context an agent needs to call the tool is present.

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 both keyword and max_results are already defined. The description only echoes the keyword concept without adding format, syntax, or additional behavioral meaning, so it stays at the baseline.

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 Data Dictionary for tables matching a keyword.' It also describes the return type ('table names and descriptions'), making the tool's purpose distinct from data-reading and field-metadata siblings.

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 description implies usage context: use when you have a keyword and need to locate dictionary tables, rather than when you already know the table name or need to read data. However, it does not explicitly discuss when-not-to-use or name alternative sibling tools.

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 provided, the description carries the full burden of behavioral disclosure, and it does so fairly well by enumerating internal steps: metadata fetch, field classification, currency/status recommendations, wrong-customer-field warnings, and field validation. It does not mention potential side effects, authentication requirements, or rate limits, but as a query tool the described behavior is reasonably transparent and not misleading.

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 description is well-structured: a one-sentence summary followed by a numbered list of distinct behaviors, ending with a direct usage recommendation. Every sentence adds information, and the structure makes the tool's enhanced behavior easy to parse.

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?

Although the description explains the tool's internal behaviors well, it is incomplete for actual invocation. There is no output schema, no parameters, and no explanation of how the query is provided to the tool. It also only distinguishes itself from one of many sibling table-reading tools, leaving ambiguity in a large sibling set. An agent cannot reliably call this tool based on the current definition.

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 input schema has zero properties, yet the description promises to 'Execute a table query' and references fields, currency filtering, status exclusion, and customer fields. There is no explanation of how the agent should specify the table name, query conditions, or field selections. Even with the '0 params = baseline 4' heuristic, this tool clearly requires inputs, and the description does not compensate for the empty schema at all.

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 clearly states the tool 'Execute a table query with automatic metadata-driven enhancements' and lists four concrete behaviors: metadata fetching, field classification, recommendations, warnings, and validation. It also explicitly differentiates itself from sap_read_table_data by saying to use this tool instead when intelligent guidance is wanted.

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 description provides an explicit alternative and a usage condition: 'Use this instead of sap_read_table_data when you want intelligent guidance!' This gives an agent a clear signal for when to select this tool over a key sibling. However, it does not articulate any when-not conditions or contrast with other sibling tools like sap_read_table_data_enhanced or sap_multi_table_query.

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 provided, the description carries the burden. It implies read-only behavior and notes the large-data context, but does not explicitly state that it avoids modifications, nor does it disclose potential performance impacts or rate limits. It is not misleading, but lacks depth.

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 description is two sentences with no filler. It front-loads the primary purpose and immediately provides usage guidance, keeping it efficient and focused.

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?

Given the tool's simplicity and absence of an output schema, the description conveys the essential context: it is a streaming/pagination mechanism for large tables. It does not mention error conditions or consistency concerns, but these are not critical for this straightforward operation.

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 schema already fully describes all three parameters with clear descriptions. The tool description adds no extra parameter-level insight or examples beyond what is in the schema, so it meets the baseline exactly.

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 clearly states the action ('Streams'), the resource ('large table data'), and the method ('offset-based pagination'). It differentiates itself from siblings like sap_read_table_data and sap_read_table_paginated by emphasizing suitability for very large tables.

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 explicitly suggests when to use the tool ('Ideal for tables with millions of rows') and instructs how to use it ('Call repeatedly with increasing offset'). However, it does not compare against specific alternatives or state when NOT to use it.

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 of behavioral disclosure. It explicitly states the tool does not create or activate code, which is a meaningful non-destructive behavioral trait. It does not describe output format or potential failure modes, but the core side-effect profile is transparent.

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 sentence that is front-loaded with the key purpose and immediately clarifies the non-destructive nature. Every word earns its place; there is no waste or irrelevant detail.

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 validation tool with only two parameters and no output schema, the description is mostly complete. It clearly states what code is checked and that nothing is created or activated. The main gap is not describing the shape of the validation result, but the purpose strongly implies a syntax-error response.

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 schema already documents both parameters. The description does not add additional meaning about the source array or program_name beyond what the schema provides, which meets the baseline.

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 specifies a precise action ('Validates ABAP source code for syntax errors') on a clear resource. It distinguishes itself from siblings like sap_read_code and sap_write_code by focusing purely on validation rather than reading or writing code.

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 phrase 'without creating or activating it' clearly implies this is a safe validation step, likely before activation or program creation. It does not explicitly name alternative tools or state when not to use it, but the usage context is clear enough.

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 provided, the description carries the full burden and does well: it discloses the composite multi-step behavior, the conditional write via auto_deploy, preservation of placeholders, and max_length constraint handling. It could add permission or side-effect detail, but the essential behavioral traits are visible.

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 description is compact and well-structured: a front-loaded summary sentence, a numbered workflow, then two short lines for constraints and supported types. Every sentence contributes distinct information 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?

For a composite tool with five parameters and no output schema, the description provides the workflow, input requirements, and important constraints. It stops short of describing the exact shape of the returned translations, which would be useful given there is no output schema, but it is enough for an agent to call the tool 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?

The input schema already documents all five parameters at 100% coverage. The description adds meaningful semantics beyond the schema by explaining the workflow, the auto_deploy gate, placeholder preservation, and supported object types, which helps an agent understand how the parameters interact.

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 clearly states the tool's function: it reads translatable texts from a SAP object, translates them with AI, and optionally writes them back. It also enumerates supported object types, making its scope concrete and distinguishing it from nearby read-only or write-only siblings like sap_read_texts and sap_write_translations.

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 workflow and auto_deploy behavior make the intended usage clear: use this when you need AI-driven translation of SAP object texts, with an option to review before writing. It doesn't explicitly name sibling alternatives or state when not to use it, but the composite read-translate-write framing provides strong context.

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 provided, the description carries the full behavioral burden. It discloses that this is a raw, low-level endpoint lacking the safe path's automatic handling, that it is restricted to specific object types on ECC, and that CLAS calls get redirected. This adds valuable context beyond the schema, though it stops short of mentioning side effects, permissions, or what happens on overwrite.

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 tightly written sentences with no filler. The core purpose is front-loaded, the alternative is stated second, and the final sentence provides scope and redirection behavior. Every sentence earns its place.

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?

The description excels at routing and scope definition, but since there are no annotations and no output schema, it leaves some gaps: it doesn't describe the return format, error behavior, or whether the operation overwrites existing code objects. For a mutation tool, a bit more behavioral context would make it fully 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 100%, so the baseline is 3. The description adds meaningful behavioral context for the object_type parameter by specifying which types are accepted and that CLAS is redirected to the safe path. Other parameters like package, fugr_name, and transport are left to the schema, which already documents them adequately.

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 identifies a specific verb and resource ('Low-level ABAP write endpoint') and clearly distinguishes itself from sap_write_code_safe. It also enumerates the exact object types it supports (PROG, INCL, FUGR, FUNC) and notes CLAS behavior, leaving no doubt about what the tool does.

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 description explicitly tells the agent to use sap_write_code_safe instead for most cases, naming the conditions the safe path handles (ECC 6.0 compatibility, class patching, syntax validation). It also states the raw endpoint's scope and the CLAS auto-redirect, giving clear when-to-use and when-not-to-use 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 transparency burden and succeeds: it reveals ECC auto-fixing behavior, S/4HANA ADT routing, syntax checking with retry, quote-stripping/truncation hazards for classes, automatic include-marker stripping, and create-vs-update semantics. This is unusually detailed and honest about side effects.

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 description is long and dense, but nearly every sentence carries operational value for a high-risk code-writing tool. It front-loads the core purpose before layering warnings and rules. Structure could be tightened with clearer section separation, but the length is largely justified by the complexity.

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?

Given the high complexity, no annotations, and no output schema, the description covers the important contextual bases: platform differences, class-modification hazards, required pre-reading, type correctness, and expected handling of class updates. It is complete enough for an agent to invoke the tool with meaningful confidence.

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 input schema has zero named parameters, so the description is the only guide to what must be provided. It supplies essential content-level semantics: full class source format, SE24/SE37 type rules, SALV text length constraints, and system-specific ABAP syntax limitations. This far exceeds what an empty schema could convey.

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 action ('Write ABAP code to SAP') and explicit targets ('programs, includes, and function modules'), and it clarifies where the tool is and is not appropriate by routing ECC class modifications to dedicated patch tools. This clearly distinguishes it from the broader write/patch sibling family.

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 explicitly says 'Use this tool for creating/updating programs, includes, and function modules' and gives an explicit when-not-to-use rule for ECC classes, with named alternatives. It also instructs the agent to read abap://syntax-rules before writing, which is strong contextual direction.

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 of behavioral disclosure. It explicitly indicates a persistent save operation ('Equivalent to saving translations in SE63') and implies updating existing text entries via text_id. However, it does not mention permissions, whether existing translations are overwritten, reversibility, or failure behavior.

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 short sentences, each adding value: purpose, SE63 equivalence, payload guidance, and supported object types. The main action is front-loaded 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?

The description covers purpose, payload, and supported object types well, but for a mutation tool with no output schema and no annotations it should also mention what happens on success, whether writes overwrite existing translations, and any permission expectations. Those gaps leave it slightly incomplete.

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 baseline is 3. The description's mention of text_id from sap_read_translations and translated_text mostly echoes the schema's own property descriptions. It adds little beyond restating the array-of-translations shape.

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 clearly states the action ('Writes translated texts back to a SAP object') and the resource, then reinforces it with the SE63 saving analogy and the list of supported object types. This makes it easy to distinguish from write-code siblings because the scope is specifically translation texts.

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 description gives clear workflow context: text_id comes from sap_read_translations, so an agent can infer this is the write-back counterpart to the translation-reading flow. It does not explicitly name alternatives or say when not to use it, but the provided context is strong enough for correct routing.

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