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

No annotations exist, so the description carries the full burden. It does disclose the write permission requirement and the need for confirm=true, both important for a cancellation operation. However, it stops short of explaining consequences such as irreversibility or side effects on stored message data.

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?

Single sentence that is efficiently front-loaded with action, example, and requirement. Every phrase adds value, with no memory waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation tool with no annotations or output schema, the description provides the core use case and safety requirements, but omits details about return values, failure conditions, and irreversibility. The messageGuid parameter also lacks context, leaving some gaps for the agent.

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 only 50%; description adds no new meaning for messageGuid, which is the required parameter and remains undocumented. The confirm parameter is described in the schema and the description merely repeats 'confirm=true' without adding insights.

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 specific verb 'Cancel' and identifies the resource as 'a currently processing/retrying message' with an explicit example of a stuck JMS or scheduled message. It clearly distinguishes this mutating tool from the many get/list 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?

Description states the intended scenario (processing/retrying/stuck messages) and prerequisites (ALLOW_WRITE, confirm=true). It does not explicitly mention alternatives or when not to use, but the context makes the use case clear and differentiates it from 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, the description carries the full burden. It discloses a key requirement ('Requires ALLOW_WRITE') and the verb 'copy' implies the source remains unchanged. However, it does not describe what happens if a package with the same ID already exists, whether the operation is idempotent, or the response format after copying.

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 and front-loaded with the action. Every word earns its place: the first sentence states purpose, the second states a permission prerequisite. No redundant 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?

Given the tool's simplicity (2 parameters, no output schema, no annotations), the description provides sufficient context: what the tool does, where from, where to, and a permission requirement. It does not describe the return value, but none is required for invoking this copy operation; the confirm parameter is documented in the schema.

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 only a small amount of domain context (e.g., 'standard/partner package') that helps interpret packageId, but it does not explain the confirm parameter's role beyond what the schema already states.

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 ('Copy'), the resource ('a standard/partner package'), and the destination ('into the design workspace'). It also gives an example source ('from the Discover catalog'), which distinguishes it from sibling tools like create, delete, or list integration packages.

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 use case: bringing a package from the Hub/Discover catalog into the design workspace. It does not explicitly mention alternatives or exclusion criteria, but the context is clear enough for an agent to know when to select this tool over its 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?

With no annotations provided, the description carries the full transparency burden. It clearly states what the tool returns (a list of OData entity sets and function imports) and implicitly indicates it is a read-only discovery operation. It adds useful context about how the catalog relates to other tools, though it doesn't explicitly mention pagination, required auth, or exact 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 exactly two sentences, front-loaded with the primary action and scope, followed by actionable usage guidance. Every word earns its place; there is no redundancy or 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 tool is simple (one optional parameter, no output schema) and the description fully explains its role in the broader workflow by naming the dependent tools. It is complete enough for an agent to understand what to expect and when to use it, given the context of sibling tools.

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 the optional 'filter' parameter clearly described as a case-insensitive substring filter. Since the schema already fully documents the parameter, the description need not add more. The baseline of 3 applies here; no additional semantic information is provided or necessary.

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 lists every OData entity set and function import for the CPI tenant. It explicitly distinguishes itself from siblings by mentioning it enables discovery of targets for cpi_query, cpi_get_entity, cpi_invoke_function, and cpi_write, making its purpose specific and non-overlapping.

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 explicit usage guidance: 'Use this to discover what cpi_query / cpi_get_entity / cpi_invoke_function / cpi_write can target.' This tells the agent exactly when to invoke this tool, setting it as a discovery prerequisite for those other tools, which effectively defines both when and how 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. It adds useful behavioral context: the distinction between single and composite keys, the raw flag for /$value endpoints, and the optional navigation follow. It implies a read-only operation ('Get'), which is accurate. It doesn't describe error handling or auth, but for a simple getter, the transparency is adequate.

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

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

Two sentences, front-loaded with the core purpose. Every word earns its place, providing examples and key distinctions without verbosity.

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 5 parameters, one required, no output schema. The description covers the key/keys distinction, raw behavior, and navigation, making the tool usable. It could mention error cases or return format, but these are not critical for a straightforward getter and the schema covers most 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 description coverage is 80%, so baseline is 3. The description adds value beyond the schema by explaining when to use 'key' vs 'keys' with concrete examples, and clarifying the navigation parameter's purpose. It doesn't describe entitySet, but that is arguably self-evident from the tool name.

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 gets a single entity by key, which is a specific verb and resource. It distinguishes itself from siblings by focusing on key-based retrieval and optional navigation, though it doesn't explicitly name alternative tools for comparison.

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 clear usage context: use 'key' for single-key entities and 'keys' for composite keys, and optionally follow navigation. It doesn't explicitly state when not to use this tool or name alternatives, but the guidance is unambiguous and practical.

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 reveals that string parameters are auto-quoted, that ALLOW_WRITE is required, and that most function imports change tenant state. This goes beyond the schema and gives important side-effect and prerequisite info, though it does not mention return format or error 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?

The description is three concise sentences, front-loaded with the purpose, then a key parameter behavior, then a critical permission/safety warning. Every sentence adds value 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?

For a generic function-import invocation tool with no output schema, the description is reasonably complete but lacks guidance on what the response will look like or how to handle errors. The reference to cpi_api_catalog helps, but given the complexity of 'any operation', more context about expected return values or limitations would be beneficial.

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 only 25% (only confirm has a description). The description adds meaning for the params object ('String parameters are auto-quoted') and hints at a permission requirement, but it does not explain method, functionName, or confirm in detail. The auto-quoting note is useful, but the description only partially compensates for the low 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 states a specific verb and resource: 'Invoke any OData function import'. It clearly distinguishes this tool from siblings like cpi_query or cpi_write by focusing on function imports, and the reference to cpi_api_catalog provides a complementary lookup resource.

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: it is used to invoke any OData function import, with a pointer to cpi_api_catalog for available functions. It also warns about the ALLOW_WRITE requirement and tenant state changes, which helps the agent decide when to use it, but it does not explicitly state exclusions or alternative 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, the description carries full burden. It clearly labels the operation as a 'read query,' indicating non-destructive behavior, but it does not elaborate on pagination behavior (despite top/skip params), response format, or access requirements. The phrase 'standard OData options' is generic and does not disclose edge-case behaviors.

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 exactly two sentences: the first states the core purpose, the second gives a compact example. Every word earns its place, and the most important information (generic read query) is front-loaded.

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 generic nature (any entity set) and lack of output schema, the description does not explain what the response looks like or how to discover valid entity sets. It also omits guidance on using pagination or select/expand options. However, the example and schema partially mitigate this by clarifying input usage.

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 meaningful parameter context beyond the schema by providing a concrete example showing how to format entitySet, filter, and orderby. This clarifies usage for the less-documented parameters (e.g., orderby has no schema description). The example compensates for the 57% 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 states a specific verb ('Run a read query'), a clear resource ('ANY CPI OData entity set'), and scope ('standard OData options'). It distinguishes this generic query tool from siblings like get_mpl_details or search_message_processing_logs by emphasizing its applicability to any entity set.

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 use for any OData entity set but does not explicitly state when to prefer this over dedicated siblings or when not to use it. No exclusionary guidance is given, but the example provides a concrete use case that hints at typical query scenarios.

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?

In absence of annotations, the description carries full burden. It discloses permission requirements (ALLOW_WRITE) and a special condition (confirm for DELETE), but does not mention potential side effects, error scenarios, or rate limits for this potentially dangerous write operation.

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, zero wasted words. Front-loads purpose and immediately provides key constraints. 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 the tool's low-level nature and lack of output schema, the description covers core functionality, prerequisites, and path formatting. Could mention return values or idempotency, but still sufficient for agent 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?

The description adds meaning beyond the input schema by clarifying path format with an example and noting the ALLOW_WRITE requirement (not in schema). With 75% schema coverage, it compensates well for the undocumented aspects.

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 'Low-level create/update/delete against any CPI OData path', uses specific verbs (create/update/delete) and resource (CPI OData path), and distinguishes itself from sibling tools that target specific entities (e.g., create_integration_package).

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 prerequisites ('Requires ALLOW_WRITE', 'DELETE requires confirm=true') and path format guidance. However, it lacks explicit direction on when to use this low-level tool versus the many sibling tools that offer specific operations on particular entities.

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. It discloses the 'empty' nature, version 1.0.0, and the ALLOW_WRITE requirement. However, it does not mention side effects, return values, or failure modes like duplicate IDs, which are important for a create operation.

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, well-structured sentence that front-loads the verb and object. It includes key facts (empty, version, editor, permission) without unnecessary fluff 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?

The description gives sufficient context for the tool's main purpose and distinguishes it from siblings, but it lacks important operational details such as parameter semantics, expected outcomes, and error scenarios. Given the absence of an output schema and annotations, a more complete description would be needed for a 4.

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 only 40%, and the description adds little beyond schema: it implies packageId via 'in a package' but does not explain name, description, or confirm. The confirm parameter is critical but not mentioned in the description, so the description fails to compensate for the schema gaps.

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 specifies the action ('Create'), the resource ('integration flow'), and the context ('in a package', 'empty flow', 'version 1.0.0'). It distinguishes this tool from siblings like create_integration_package and save_integration_flow_as_version by focusing on the initial empty flow creation.

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 clear context for when to use this tool: creating a new empty flow that will be edited later in the web editor. However, it does not explicitly mention alternatives or when not to use it, so it does not fully meet the 'explicit when/when-not' bar.

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

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

With no annotations, the description carries the full burden. It discloses the ALLOW_WRITE permission requirement, which is a valuable behavioral constraint. However, it doesn't mention idempotency, response behavior, or what happens if the id already exists. The permission note adds some context but the disclosure is minimal.

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 concise: two short sentences with the purpose front-loaded. It avoids unnecessary words and is 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?

With 5 parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain the confirm requirement, field semantics, or what to expect on success (e.g., a return value). The minimal text leaves significant gaps for a creation 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 only 40%, and the description adds no parameter details beyond what the schema provides. It doesn't explain the meaning of 'name', 'shortText', 'description', or the 'confirm' flag. Since coverage is low, the description should compensate but does not.

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 'Create a new integration package' with a specific verb and resource, distinguishing it from sibling tools like list, get, delete, and copy. This unambiguously communicates the tool's function.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. The verb 'create' implies use for new packages, but there are no exclusions, prerequisites (beyond ALLOW_WRITE), or references to alternative 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, the description must carry the burden of behavioral disclosure. It only mentions the ALLOW_WRITE permission, but does not describe side effects, return values, or other behavioral traits beyond the obvious creation operation.

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 concise single sentence that efficiently states the tool's purpose and a key requirement. It avoids redundancy and is well-structured.

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 complexity of 8 parameters, no output schema, and no annotations, the description is severely incomplete. It omits parameter meanings, usage context, and expected return, making it inadequate for an agent to use 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 only 13% (only 'confirm' has a description). The description does not explain any of the eight parameters, such as name, rotate, minValue, or maxValue, and thus fails to compensate for the low 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 states 'Create a number range object' with a specific verb and resource. It is unambiguous but does not differentiate from sibling tools like create_integration_package or list_number_ranges.

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 no guidance on when to use this tool versus alternatives. It only mentions the ALLOW_WRITE permission requirement, which is a prerequisite, not usage context or 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?

With no annotations provided, the description carries the full burden. It discloses destructive behavior (deletes package and artifacts), permission requirement (ALLOW_WRITE), and a mandatory confirmation flag (confirm=true). While it does not mention reversibility or dependent artifacts, it covers the key safety-critical 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 one sentence that front-loads the action, scope, and prerequisites. Every word contributes value; there is no redundancy or padding.

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 delete tool with 2 parameters and no output schema, the description covers the essential aspects: what it deletes, the scope (all artifacts), the permission needed, and the confirm flag. It lacks details on errors or irreversibility but is adequately complete for the given complexity.

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 has zero description coverage, so the description must compensate. It clarifies that confirm must be set to true, but does not elaborate on packageId beyond its name. The parameter semantics are only partially addressed, leaving some ambiguity about packageId format or the need to confirm for the operation to succeed.

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 (Delete) and resource (integration package) and clearly distinguishes from siblings by adding 'all its artifacts', making it the only destructive operation among get/list/create/copy tools. 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?

It gives clear context for use: delete requires ALLOW_WRITE permission and confirm=true. It does not explicitly name alternatives or when-not conditions, but the deletion scope and prerequisites are clearly stated, which is more than minimal 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 present, the description carries the full burden of disclosing behavior. It reveals that the operation requires ALLOW_WRITE, is asynchronous, and provides two specific status-check tools for follow-up. This goes beyond the schema. However, it does not mention whether deployment overwrites existing artifacts or what happens on failure, missing some depth for a mutation 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 three concise sentences, each earning its place: purpose, type selection, and permission/async guidance. No fluff or repetition. It is front-loaded with the core action and provides actionable follow-up without verbosity.

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 deployment tool with no output schema and low parameter documentation, the description covers the essential asynchronous nature and permission requirement, and points to status tools. However, it omits the confirm parameter's role, version semantics, and any notion of operation IDs or failure behavior. It is adequate but leaves clear gaps for a tool of this complexity.

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 only 25% (only 'confirm' has a schema description). The description adds meaning only for the 'type' parameter via 'Choose the artifact type.' It does not explain artifactId (required), version (defaults to 'active'), or that confirm must be true. Additionally, the description mentions 'Requires ALLOW_WRITE' but does not mention the confirm flag, which is a critical parameter for execution. This is insufficient for a low-coverage 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 and resource: 'Deploy a design-time artifact to the runtime.' This clearly distinguishes the tool from siblings like 'undeploy_artifact', 'get_deployed_artifact_status', and 'get_build_and_deploy_status'. The action is unambiguous and matches the tool name.

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 this tool: whenever you need to deploy an artifact to the runtime. It also provides follow-up guidance by mentioning status-check alternatives after asynchronous deployment. However, it does not explicitly state when not to use it or contrast with alternatives like 'save_integration_flow_as_version' or 'create_integration_flow', so it stops short of full 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?

No annotations are provided, so the description carries the full burden. It discloses two key behavioral traits: the need for ALLOW_WRITE permission and that the secret is write-only and cannot be read back. This goes beyond the schema and is valuable for safe agent usage.

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 brief and front-loaded: it opens with the purpose, then immediately states the permission requirement and the critical write-only caveat. Every sentence adds value with no redundant or irrelevant content.

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 the essential permission and write-only behavior, but it omits details about overwriting existing credentials, async deployment, or return values. Since there is no output schema, this leaves some ambiguity, though the schema documents the 'confirm' 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 description coverage is only 17% (only 'confirm' is described in the schema). The description adds minimal parameter insight—it only hints that the password is secret. Parameters like 'kind', 'description', and the meaning of 'name'/'user' are not explained, leaving the agent to infer from names.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Create/deploy') and resource ('User Credential security artifact'), distinguishing it from generic deploy_artifact and the list_user_credentials sibling.

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 a write operation via 'Requires ALLOW_WRITE' and notes the write-only nature, but it does not explicitly mention when to use this tool versus alternatives like deploy_artifact or list_user_credentials. No when-not-to-use guidance 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?

Without annotations, the description carries the burden of behavioral disclosure. It does reveal that the output is a base64-encoded zip, which is valuable. But it does not mention authentication needs, error handling, or how the 'version' parameter affects the download, leaving gaps in transparency.

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, front-loaded with the action and output format. Every word adds value, and there is no redundancy with the schema or title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple download operation, the description adequately conveys the output format. However, it lacks parameter semantics and differentiation from sibling tools, and with no output schema or annotations, the overall completeness is only minimally viable.

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

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

Schema description coverage is 0%, and the description does not compensate by explaining the parameters. It only refers to 'integration flow content' without clarifying that artifactId is required or what version means. The parameters remain effectively undocumented.

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 action: downloading integration flow content as a base64-encoded zip. It uses a specific verb and resource, and the title reinforces the purpose. This distinguishes it from sibling tools like get_integration_flow, which likely retrieve metadata rather than content.

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 mentions 'Useful for backup/transport,' providing a clear general context for when to use the tool. However, it does not explicitly say when not to use it or name alternative tools for related tasks, leaving some ambiguity among the many 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?

No annotations are provided, so the description carries the burden. It adds the key behavior 'asynchronous' and implies a read-only status check via 'check', but does not disclose return format, error handling, or side effects. Some context is provided, but not comprehensive.

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?

Single sentence of ~14 words, front-loaded with the action, no redundant phrasing. All information is useful.

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 a single parameter, no output schema, and no annotations, the description is mostly sufficient, but it lacks detail on what the status response looks like. However, the core purpose and input are clear, making it fairly 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 a clear description for taskId ('returned by deploy_artifact'). The description's phrase 'returned as a task id' reinforces this but adds no new information beyond 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?

Description states 'Check the asynchronous build/deploy task status for a deployment' with a clear verb ('Check'), resource ('build/deploy task status'), and context ('async', 'returned as a task id'). It is distinct from sibling get_deployed_artifact_status by focusing on task status rather than artifact status.

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 when/when-not or alternative tools are mentioned. The description implies usage after initiating a deployment via 'returned as a task id' and 'asynchronous', but does not reference deploy_artifact or contrast with get_deployed_artifact_status.

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 indicates a read-only operation via 'List', but does not mention side effects, output format, or parameter behaviors like the 'top' limit or 'type' selection. The integrationFlow clarification adds some value, but significant behavioral gaps remain.

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 concise sentences. The main action is front-loaded, and the second sentence adds critical parameter context without redundancy. 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?

Given no output schema, no annotations, and 0% schema description coverage, the description is incomplete. It fails to describe the required parameter 'dataStoreName' and the optional parameters 'top' and 'type'. The tool is simple, yet the description leaves important usage details undisclosed, making full autonomous invocation difficult.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters. Only 'integrationFlow' is clarified ('empty for a global store'). The required 'dataStoreName' is not mentioned, and 'top' and 'type' are left unexplained. This is insufficient for the 4 parameters.

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: 'List the entries in a specific data store.' It uses a specific verb ('List'), identifies the resource ('data store entries'), and adds a scoping detail about integrationFlow for global vs. flow-specific stores. This distinguishes it from the sibling tool 'get_message_store_entries' by focusing on data stores, not message stores.

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 it: to list data store entries, and gives a usage hint about the integrationFlow parameter ('empty for a global store'). It does not explicitly state exclusions or alternatives, but the clarification about global vs. flow-specific stores provides enough context for when to set the parameter.

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. It adds that error details are returned if failed, which is useful. However, it doesn't explicitly state read-only behavior, permissions, or failure modes for non-existent artifacts, though the 'Get' verb implies safety.

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 with no filler. It conveys the verb, resource, and an additional detail concisely. Every word is functional.

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 2-parameter read tool, the description gives the core purpose and an extra behavior, but with no output schema it doesn't describe the response structure or possible status values. It is sufficient for a minimal understanding but lacks return 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 description coverage is 0%, and the description does not explain either parameter. It mentions 'error details if failed' but doesn't map to includeErrorDetails. artifactId is completely unexplained beyond its name, so the description fails to compensate for the absence of 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 clearly states a specific verb ('Get') and resource ('deployment status of one runtime artifact'), and adds scope ('one') and an additional detail ('plus error details if failed'). This distinguishes it from sibling tools like list_deployed_artifacts (list all) and get_build_and_deploy_status (process status).

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 for a single artifact's deployment status, but offers no explicit when-to-use vs alternatives or when-not-to-use. The singular 'one runtime artifact' provides context, but no sibling differentiation or exclusion is stated.

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

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

With no annotations provided, the description carries the full burden but only states the aggregation function. It does not disclose whether the operation is read-only, what the output contains (counts, lists), or any side effects, leaving a significant transparency 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 a single sentence that conveys the core idea efficiently with 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 lack of output schema and annotations, the description should explain the return format and how this tool relates to error-focused siblings, but it only provides a high-level summary without those 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 0% and the description does not mention the 'top' or 'hoursBack' parameters. While 'hoursBack' is vaguely implied by 'recent window', 'top' is entirely unexplained, so the description adds little semantic value.

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 the specific verb 'Aggregate' and identifies the resource ('failed/escalated messages') plus the grouping key ('integration flow'), making it distinct from sibling tools that retrieve individual error details.

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 a summary use case but does not explicitly state when to prefer this tool over siblings like get_mpl_error_information or search_message_processing_logs, nor does it mention any exclusions or alternatives.

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 disclose behavioral traits itself. It reveals the content returned but does not state that the operation is read-only, describe the return shape, mention the active-version default, or address error conditions. This is a significant gap for an unannotated tool.

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

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

The description is a single, front-loaded sentence with no filler. It states the verb, resource, and examples in 17 words, earning every word.

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 annotations, no output schema, and many sibling getters, this description is too thin. It does not explain the version semantics, output format, or relationship to related flow tools, leaving the agent without enough context to invoke it with 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?

Schema description coverage is 0%, so the description must compensate, but it only loosely ties artifactId to 'an integration flow' and says nothing about the version parameter or its 'active' default. Some meaning is added by explaining what externalized parameters are, but not enough to fully document the two parameters.

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 ('Get') and names a clear resource: externalized configuration parameters of an integration flow, with useful examples ('endpoints, credentials names, etc.'). It is clear enough to distinguish the tool from most siblings, though it does not explicitly call out a sibling alternative, so it falls just 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 only states what the tool does and gives no when-to-use guidance, prerequisites, or alternatives. It does not mention when to choose this over get_flow_resources or update_flow_configuration, leaving the agent to infer usage from the name and schema.

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 full responsibility for behavioral disclosure. It only states a read-only list operation and gives examples of returned resource types, but does not explain the return structure, potential errors, pagination, authentication needs, or how version affects the result. This is a significant gap for a tool with no structured safety hints.

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 fronts the main verb and object, with a parenthetical list of examples. It is compact and readable, but the structure is flat with no separators or additional context, so it earns a high but not top score.

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 only two sparse parameters, the description should compensate by explaining the returned data shape, the meaning of artifactId and version, and how this tool relates to similar ones. It only provides the basic 'list resources' idea, leaving too much unsaid for reliable 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?

The schema has two parameters (artifactId, version) with zero description coverage. The tool description adds no meaning to either parameter, leaving artifactId and version undefined. The agent must guess what 'active' means as a default and what an artifactId refers to, making parameter usage highly ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'List' and identifies the resource type (resources inside an integration flow) plus enumerates concrete examples (scripts, XSDs, WSDLs, mappings). This clearly distinguishes it from siblings like get_integration_flow or get_flow_configurations, which target different aspects.

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 when you need to inspect the resources within a flow, but it does not explicitly state when to prefer this over alternatives, nor does it mention any exclusions or complementary tools. The context is clear enough for a basic guess but lacks explicit 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 full burden. It discloses only that it retrieves an artifact, but lacks details about return format, error handling, authentication requirements, or the meaning of 'design-time'. This is insufficient for an agent to understand side effects or failure modes.

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 concise sentence, which is appropriately front-loaded. However, it is under-specified, omitting essential context that would make it more useful. It is not overly verbose but lacks completeness for the reader.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, no annotations, and 0% schema coverage, the description alone is inadequate for reliable invocation. It does not clarify how 'design-time' differs from 'deployed' or indicate what data is returned, leaving critical gaps for the agent.

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

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

Schema description coverage is 0%, so the description must compensate. It only mentions 'by Id and Version', which paraphrases the property names without explaining parameter semantics, defaults (e.g., version default 'active'), or acceptable values. This adds minimal value beyond 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 clearly states the verb 'Get' and the specific resource 'design-time integration flow artifact' with identifying attributes 'by Id and Version'. This distinguishes it from siblings like list_integration_flows or get_deployed_artifact_status.

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 for retrieving a specific integration flow artifact, but it does not explicitly state when to use this tool versus alternatives like get_flow_configurations or download_integration_flow. No exclusions or conditions are given, so guidance is minimal.

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 full burden. It only states 'Get details' with no additional context on return format, error handling, permissions, or rate limits. It essentially restates the tool's name, offering no deeper behavioral insight.

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 concise sentence, front-loaded with the action and resource, containing no extraneous words.

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 simple nature of the tool (one required parameter, no output schema), the description adequately conveys the operation. It avoids over-explaining, and the context of siblings clarifies its role. Minor gap: no mention of what 'details' includes, but overall sufficient.

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

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

Schema coverage is 0%, but the description adds meaning by saying 'by Id,' clarifying that packageId is the identifier of the integration package. However, it does not provide additional details like format or constraints beyond what the schema already shows.

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 specific action: 'Get details of a single integration package by Id.' It identifies the resource (integration package), the operation (get details), and the unique identifier (Id), distinguishing it from sibling tools like list_integration_packages.

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: use when you have a packageId and need details of one package. However, it does not explicitly mention alternatives or when not to use it, such as 'use list_integration_packages to list all packages.'

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 present, so the description carries the full burden. It only states that it returns persisted payloads; it does not disclose pagination, ordering, error handling, permissions, or side effects. The behavior is not misleading, but it is largely missing.

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

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

One sentence, direct, front-loaded with the action and resource. Every word earns its place, and it is appropriately sized.

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 lack of output schema and annotations, the description should explain what the return value looks like (array, object) and any special behavior. It only states 'entries' (payloads), leaving the response format and possible error conditions unclear.

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 has one parameter, messageGuid, with no description. The tool description says 'for a message' which maps messageGuid to a message, but this is largely redundant with the parameter name. No format, example, or additional semantics are provided.

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 specifies the action (get), the resource (persisted message store entries), and the scope (for a message). It also adds context about the 'Persist' step, helping distinguish it from sibling tools like get_data_store_entries.

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 when-to-use instructions or alternatives are provided. The description implies it is used when you need persisted message payloads for a specific message, but there is no guidance on when not to use it compared to related tools such as get_data_store_entries.

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 full burden for behavioral disclosure, but it only says 'Get', which weakly implies read-only. It does not explicitly state whether the operation has side effects, requires specific permissions, or what happens when no custom properties exist. No additional behavioral context is provided beyond the basic operation.

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, concise sentence that front-loads the action and resource. There is no redundant information or filler; every word contributes to understanding the tool's purpose.

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 tool with one parameter and no output schema, the description gives the essential purpose, but it lacks guidance on parameter usage and return value shape. It mentions 'for a message' but without clarifying that this refers to a message processing log (MPL), potentially causing ambiguity. Overall, it is minimally adequate but has clear gaps.

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

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

The schema has one parameter, messageGuid, with no description (0% coverage). The tool description does not mention the parameter or add any meaning to it. Despite the parameter name being somewhat self-explanatory, the description fails to compensate for the schema's lack of detail, leaving the agent without additional semantic 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 'Get custom header properties (business keys, custom status) for a message' clearly states a specific verb and resource, and differentiates from sibling tools like get_mpl_error_information or get_mpl_run_steps. The parenthetical clarifies what the properties include, making the purpose 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 no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusion criteria. It simply states what the tool does without contextualizing it among the many related MPL and integration 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 burden. It correctly indicates a read operation and scope, but does not disclose behavior for missing/invalid GUIDs, error responses, or the exact structure of the 'full' entry.

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

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

A single, front-loaded sentence with no filler. Every word contributes to identifying the tool's purpose and primary parameter.

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 get-by-ID tool with one parameter and no output schema, the description is adequate. It could be more complete by mentioning what 'full entry' includes or behavior when the GUID is not found, but the low complexity mitigates this gap.

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

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

Input schema has one parameter with 0% description coverage. The description explicitly links the parameter to a 'specific MessageGuid', which clarifies its purpose as the identifier of the log entry, even though it adds no format or constraint details.

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 ('Get') and resource ('full Message Processing Log entry'), making the operation clear. The scope 'for a specific MessageGuid' distinguishes it from sibling tools that retrieve sub-details like errors or run 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?

Clear context is provided: this tool is for retrieving the complete log entry when a MessageGuid is already known. It does not explicitly name alternatives, but the use of 'full' implies it is the comprehensive option compared to siblings that return specific aspects.

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 only says what the tool does, not how it behaves (e.g., error handling, return format, permissions, or what happens if the message GUID doesn't exist). This lack of behavioral context is a significant 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 a single, concise sentence with no redundant information. However, while it is efficient, it may be under-specified, but that is more a completeness issue than conciseness. The structure is clean and front-loaded.

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 has only one parameter and no output schema, the description should clarify what the error text looks like and how to use the parameter. It does not explain the parameter, potential return values, or edge cases. The description is incomplete for an AI agent to invoke the tool confidently.

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 has one parameter (messageGuid) with zero description coverage, and the description does not mention or explain the parameter at all. Since schema_description_coverage is 0%, the description should compensate but fails to provide any meaning for messageGuid beyond its 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 retrieves detailed error/exception text for a failed message. It uses a specific verb ('retrieve') and resource ('error/exception text'), making the purpose unambiguous. While it doesn't explicitly differentiate from siblings, the phrase 'detailed error/exception text' distinguishes it from related tools like get_mpl_details or get_failure_summary.

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 for failed messages but provides no explicit guidance on when to use this tool versus alternatives like get_failure_summary or get_mpl_details. There are no when-not-to-use conditions or alternative recommendations, making the guidance implicit 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 must carry the full burden of behavioral disclosure. It mentions the prerequisite (trace/step logging) but fails to describe the return format, behavior when logging is disabled, error conditions, or any 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 a single, front-loaded sentence that efficiently conveys the tool's purpose and a key condition. Every word earns its place, with no fluff 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?

Given the lack of output schema and annotations, the description is too sparse. It does not describe what the run steps look like, how they are ordered, what happens if trace logging is not enabled, or any details about messageGuid. The tool is simple but still lacks essential context for an agent to use it confidently.

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 has zero parameter descriptions (0% coverage), so the description must compensate. It only hints that messageGuid relates to a message, but it does not explain the format, source, or constraints. This is insufficient for understanding how to populate the parameter correctly.

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 action ('Get the individual run steps for a message') with a specific resource and outcome. It distinguishes itself from sibling tools like get_mpl_details and get_mpl_error_information by focusing on 'run steps' rather than general details or error information.

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 a clear prerequisite ('requires trace/step logging enabled on the flow') that indicates when the tool is applicable. However, it does not explicitly name alternative tools or state when not to use it, leaving some room for ambiguity.

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

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

With no annotations, the description carries the burden, and 'List' clearly signals a read-only operation with no destructive effects. The parenthetical adds useful behavioral context about the store types (transient vs persistent). It does not discuss permissions or response format, but these are not critical for a simple listing 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 a single, front-loaded sentence that immediately states the action and object, then adds a brief clarifying parenthesis. Every word earns its place with no redundancy or 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 simple list tool with one optional parameter and no output schema, the description adequately defines the resource and scope. It could mention what is returned (e.g., store names/IDs) but 'List data stores' sufficiently implies a collection of data store references in 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 coverage is 0%, yet the description does not mention the 'top' parameter or its effect on result size/limits. The schema provides default/max/min, but the description adds no meaning to the parameter, so the agent must infer from the name alone.

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 'List' with a clear resource 'data stores' and clarifies the domain via parenthetical 'transient/persistent message persistence used by flows'. This distinguishes it from sibling tools like get_data_store_entries, which list entries rather than the stores themselves.

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 it (when needing to enumerate data stores) and gives context about what data stores are, but it does not explicitly name alternatives or state when not to use it. Sibling tools like get_data_store_entries suggest related operations, yet no comparison is 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?

With no annotations, the description carries the full burden. It fails to disclose that the 'top' parameter limits the number of results, contradicting the word 'all'. It also does not mention any ordering, filtering, or return field details beyond status.

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 that efficiently communicates the core function without waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple, but the description misses the limiting behavior of 'top' and provides no output schema or return field details. It mentions status but not other artifact attributes, leaving some gaps for an agent invoking it.

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 has a single optional 'top' parameter with 0% description coverage, and the description does not explain it at all. Since the description does not compensate for the low coverage, it scores a 2.

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 'list' and identifies the resource as 'deployed runtime artifacts' with their status. This clearly distinguishes it from sibling tools like get_deployed_artifact_status, which targets a single artifact's status.

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 this is for retrieving a broad list of all deployed artifacts with statuses, but it does not explicitly state when to choose this over alternatives or any exclusions. Since it provides clear context without explicit guidance, it earns a 3.

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 adds the useful 'design-time artifacts' scoping and 'List' implies a read-only operation. However, it doesn't mention return format, authentication needs, pagination, or error 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?

The description is a single, clear sentence with no redundancy or filler. It is appropriately sized for a simple one-parameter list 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?

For a simple list tool with one parameter and no output schema, the description provides a reasonable high-level context. However, without annotations or output schema details, the agent is left without information about the expected response structure or edge cases, so it isn't 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 0%, and the description only says 'in a package,' which merely echoes the packageId parameter name. It doesn't explain any format, constraints, or relationship beyond what the schema already shows, so the description adds little value for parameter 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 uses a specific verb ('List') and names a concrete resource ('integration flow design-time artifacts') with a scope ('in a package'). This clearly differentiates it from siblings like list_integration_packages and get_integration_flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: an agent would use this when needing to enumerate design-time integration flows within a particular package. However, there are no explicit alternatives, exclusions, or when-not-to-use conditions, so it doesn't fully guide decision-making among 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, the description must carry the behavioral disclosure burden. The claim 'List all integration packages' is potentially misleading because the 'top' parameter (default 100) limits results, so it won't return 'all' if more than 100 exist. There is no mention of pagination, ordering, or permission requirements.

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

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

The description is a single, concise sentence that front-loads the core purpose. Every word adds value and there is no redundancy or 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 tool has one optional parameter, no output schema, and no annotations. The description fails to explain the 'top' parameter semantics and the discrepancy between 'all' and the default limit. It also omits any detail about return format or behavior when the workspace has many packages.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented 'top' parameter. The description does not mention 'top' at all, leaving the agent without any insight into what the parameter does beyond its schema type 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 clearly states the action ('List'), the resource ('integration packages'), and the scope ('tenant's design workspace'). This distinguishes it from sibling tools like list_integration_flows and get_integration_package, which focus on flows or single package details.

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 intended use case (listing all packages in the design workspace) but provides no explicit guidance on when to use this tool versus alternatives like get_integration_package or list_deployed_artifacts. No exclusions or preference statements are given.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'List' implies a read-only operation, and the description mentions the return of state (capacity, message counts). However, it does not disclose potential permissions required, whether all queues are included, or any side effects. For a simple list tool, this is adequate but not exhaustive.

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, front-loaded with the core action and resource, and every word adds value. It is concise and to the point.

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 tool with no output schema, the description is largely complete. It specifies the resource and the state information returned. However, it does not detail the exact return format or any limitations such as default queue scope, leaving a minor gap.

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

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

The input schema has zero parameters, so the baseline is 4. The description does not need to explain any parameters since there are none, and it adds clarity about what the tool returns without needing to describe parameter details.

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 specifies the verb 'List', the resource 'JMS queues', and the additional detail about state (capacity, message counts). This distinguishes it from other list tools such as list_data_stores or list_variables.

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 that this tool is used to inspect JMS queues and their state, but it does not explicitly state when to use it versus alternatives or any exclusions. Usage is implied by the tool name and description, but no explicit guidance 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 provided, the description carries the full burden of behavioral disclosure. It only restates the action (listing) without revealing details such as pagination, limits, or whether sensitive key material is included. The absence of any behavioral traits beyond the name leaves the agent underinformed.

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 is concise and readable, but it misses an opportunity to include a brief mention of the parameter or return behavior without sacrificing conciseness. Overall, it is appropriately sized but slightly under-specified.

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 tool with one optional parameter and no output schema, the description should at least explain the meaning of 'top' and what the returned entries contain. The current description omits this, leaving the agent with incomplete guidance. The tool is simple, but the description does not fully cover its 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?

The schema describes a single 'top' parameter with no description (0% coverage), and the description does not mention this parameter at all. Since the description must compensate for missing schema comments but fails to do so, the agent has no understanding of how to use 'top' or what it controls.

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 tool's function with a specific verb and resource: 'List entries (certificates / key pairs) in the tenant keystore.' It differentiates from sibling tools by specifying the keystore resource, making its purpose distinct.

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 clear context about what the tool does, implying it should be used when listing keystore entries. While it doesn't explicitly mention alternatives, the resource is unique enough that no exclusions are needed. The context is straightforward and unambiguous.

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 present, so the description carries the transparency burden. It implies a non-destructive list operation but does not explicitly state that it has no side effects, authorization requirements, or that it only returns file names. The word 'list' helps, but more could be 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?

A single sentence that directly states the action, includes relevant examples, and specifies the scope. There is no redundant information, and it is appropriately front-loaded.

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, parameterless list operation, the description is largely complete. However, since there is no output schema, it could explicitly mention that the return is a list of file names or whether the files are grouped by node. It is adequate but leaves a small gap.

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

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

The tool has zero parameters, so the description needed to add no parameter-specific meaning. The context about tenant worker nodes is not a parameter but useful domain info. Per the rubric, a zero-parameter tool receives a baseline score of 4.

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 lists available system log files, specifying types (http, trace, etc.) and scope (tenant worker nodes). This makes its purpose distinct from sibling tools that deal with message processing logs or integration artifacts.

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 clear context that this tool is for viewing system log files on tenant worker nodes, but does not explicitly mention alternatives or exclusions. The context is sufficient for most use cases, though it lacks explicit 'when not to use' guidance compared to related 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, the description carries the burden of behavioral transparency. 'List' strongly implies a read-only operation, but the description does not disclose any additional behavior such as pagination, ordering, or the exact structure of the returned objects. It is adequate but minimal.

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 wasteful words. It conveys the essential purpose 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?

Given the tool's simplicity (zero parameters, no output schema), the description is mostly complete. It might benefit from specifying the return format, but the core action is unambiguous for a list 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 tool has zero parameters, so the description does not need to explain parameter semantics. Per the rubric, a baseline of 4 applies when there are no parameters.

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 ('List') and clearly identifies the resource ('configured number range objects'). It clearly differentiates from sibling tools like create_number_range by indicating a read-only listing of existing objects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage context is implied: use this tool to retrieve existing number range objects. However, there is no explicit guidance on when to prefer this over alternatives or any exclusions. The description does not mention 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?

Annotations are absent, so the description carries the burden. It adds the useful behavioral trait 'metadata only', indicating that actual credential secrets are not returned. However, it does not disclose other behaviors such as pagination behavior, permission requirements, or how empty results are handled.

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 wasted words. It efficiently conveys the action, resource, and scope ('metadata only').

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 list tool with one optional parameter and no output schema, the description covers the core purpose and the metadata-only restriction. However, it omits parameter semantics and does not differentiate from sibling list tools, leaving some gaps in completeness.

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 has one parameter 'top' with 0% coverage in the description. The description does not mention the parameter or explain that it limits the number of results, failing to compensate for the lack of schema descriptions. The parameter name and constraints give some hints, but the agent is left without explicit 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 clearly states the tool lists 'deployed OAuth2 Client Credential security artifacts' and specifies 'metadata only', distinguishing it from sibling tools that list other credential types or keystore entries. The verb 'List' and the resource are specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied by the name and description, but there is no explicit guidance on when to use this tool versus alternatives like list_user_credentials or list_keystore_entries. No exclusions or alternative recommendations 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?

With no annotations, the description must reveal behavioral traits, but it only says 'List partners.' It does not mention the optional 'top' parameter, default behavior, pagination, or any side effects. The agent receives no information about safety, rate limits, or output structure beyond the basic action.

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, concise sentence with no filler. It directly states the purpose and is easily scannable. While it could add more context without becoming verbose, the current structure is appropriately minimal.

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 is simple, but the description is insufficient given the lack of an output schema and annotations. It does not explain what partner information is returned, how the 'top' limit affects results, or any usage context. A complete description would at least mention the optional limit.

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 defines one parameter 'top' with default/min/max, but the description provides zero explanation of this parameter. With schema description coverage at 0%, the description fails to compensate by giving any meaning or usage context for the parameter.

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 (List) and the specific resource (partners in the Partner Directory). It is unambiguous and distinct from all sibling tools, none of which mention partners.

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 offers no guidance on when to use this tool versus alternatives such as list_integration_packages or list_service_endpoints. There are no scenarios, prerequisites, or exclusions provided, leaving the agent without 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?

No annotations exist, so the description carries the burden. It accurately indicates a read-only listing operation and adds context about the types of endpoints, but it does not disclose behavior like pagination (via the 'top' parameter), filtering, or whether only currently running flows are included. It adds some value but lacks deeper behavioral details.

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, tightly written sentence (18 words) that is front-loaded with the action and resource. Every word earns its place with no fluff 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 simple list tool with no output schema and no annotations, the description states the core purpose and endpoint types, but it omits explanation of the 'top' parameter and any note about the response format or potential empty results. It is minimally viable but not 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 0% and the description never mentions the only parameter 'top'. The schema provides default/min/max constraints, but the description should add meaning about its purpose (e.g., maximum number of endpoints returned). This is a gap for a single-parameter tool.

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 the specific verb 'List' with a clear resource 'runtime service endpoints (URLs)' and scopes it to 'deployed integration flows' with protocol examples (HTTP, SOAP, OData). This clearly distinguishes it from sibling tools like list_integration_flows or list_deployed_artifacts.

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 clear context about when to use this tool (to get URLs of deployed integration flows), but it does not explicitly state when not to use it or mention alternative tools. The scoping is clear enough for most cases, so this earns a 4.

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 disclosure. It explicitly states that only names/metadata are returned and no secrets are included, which is a key behavioral trait. However, it does not mention whether the operation is read-only, any required permissions, or other potential behaviors, leaving gaps.

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, well-structured sentence that is front-loaded with the verb and directly states the key scoping detail (no secrets). Every word contributes value.

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 list tool with one optional parameter, the description is reasonably complete. It defines the output scope (names/metadata only) and the resource scope (deployed artifacts). The missing parameter explanation and usage context prevent a higher score.

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 does not mention the 'top' parameter at all. The schema provides type, default, min, and max, but with 0% schema description coverage, the description should compensate. It fails to explain that 'top' is a limit for the number of returned items.

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 (list), the resource (deployed User Credential security artifacts), and the scope (names/metadata only, no secrets). This distinguishes it from sibling tools like list_oauth2_client_credentials and list_keystore_entries.

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 no guidance on when to use this tool instead of alternatives such as list_oauth2_client_credentials or list_deployed_artifacts. It does not mention any exclusions or preferred contexts.

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. It states the operation is listing variables, which implies read-only, but does not mention what data is returned, limits, pagination, or any side effects. The 'top' parameter is not explained, leaving important behavioral characteristics undisclosed.

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 of eight words, front-loaded with the verb and resource. It is appropriately concise with no fluff 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?

Given the tool's low complexity and lack of output schema, the description is too minimal to be complete. It does not explain what the response looks like, how to interpret the 'top' parameter, or any usage context. A complete description would at least mention that it returns a list and that 'top' limits the count.

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 one parameter ('top') with no description (0% coverage). The description does not mention this parameter at all, so it adds no semantics beyond the schema's type and constraints. The parameter name is self-explanatory to some degree, but the tool description should still clarify its purpose.

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 the specific verb 'List' and clearly identifies the resource as 'global and local variables persisted by integration flows.' This makes the tool's purpose unambiguous and distinct from all sibling tools, none of which mention variables.

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 (when you need to see persisted variables) but provides no explicit usage context, exclusions, or alternatives. Since no sibling tool covers variables, there is no need for explicit alternatives, but the description could still be clearer about intended scenarios.

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 responsibility of disclosing behavioral traits. It notes the permission requirement ('Requires ALLOW_WRITE') and reveals a non-obvious implementation detail: the comment is applied before the version is saved since the API doesn't take it directly. This exceeds baseline, though it doesn't detail all possible 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 two sentences, front-loaded with the core action, followed by a parenthetical explanatory note. Every word earns its place—no redundancy or 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?

Given the absence of an output schema and annotations, the description adequately covers the tool's purpose, prerequisite, and a unique behavioral nuance. It doesn't mention return values or error conditions, but it provides enough for an agent to correctly invoke the tool with the schema.

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 covers 75% of parameters with descriptions, so the baseline is 3. The description adds a useful note about the comment parameter's behavior but doesn't add meaning to artifactId or version beyond what the schema already provides. Overall, it adds modest value without fully compensating for the one undocumented parameter.

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: 'Save the current draft ('active') of an integration flow as a new version' with an optional comment. It uses a specific verb ('save') and resource ('integration flow draft'), and distinguishes this from siblings like 'deploy_artifact' or 'create_integration_flow'.

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 by mentioning 'current draft' and requires 'ALLOW_WRITE', but it does not explicitly contrast with alternative tools (e.g., when to version vs. deploy). The context is clear enough for basic use, but an agent might need more guidance on when to choose this tool over others.

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 transparency burden. It discloses the 'Most recent first' sorting behavior and filtering options, which adds value. However, it does not mention authentication requirements, rate limits, pagination behavior, or error handling. The description is reasonable but not rich enough for a higher score.

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 concise and front-loaded. The first sentence states the action and resource, the second lists filters and ordering. Every sentence earns its place with no 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?

For a search tool with 5 optional parameters and no output schema, the description covers the essential query dimensions but misses important details: the 'top' parameter controls result count, and the enum includes 'ABANDONED' which is not listed in the description. This is a notable gap that could lead to under-specification.

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 only 40% (toTime and fromTime have descriptions). The description adds meaning by grouping toTime/fromTime as 'time window' and explicitly listing status values, but it omits the 'top' parameter and its result-limit semantics. It partially compensates for the schema coverage gap but not fully.

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 purpose: 'Search SAP CPI Message Processing Logs.' It specifies the verb 'Search' and the resource 'Message Processing Logs,' and lists the key filtering dimensions (status, integration flow name, time window). This distinguishes it from sibling tools like get_mpl_details, which focus on retrieving specific log details.

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 context on when to use the tool (searching logs with filters) but does not explicitly compare it to alternatives or state when not to use it. It implies usage through the search context, but lacks direct exclusions or alternative recommendations.

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 provided, so description carries the burden. It discloses that ALLOW_WRITE permission and confirm=true are required, which are critical behavioral prerequisites not apparent from the schema. However, it doesn't discuss reversibility or effects on in-flight messages.

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 concise sentences front-load the purpose and immediately note the permission/flag requirement. 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 simple tool with no output schema or annotations, the description covers purpose, effect, and critical parameters. It could add postcondition info or error conditions, 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 0%. Description adds meaning only for confirm (must be true) but leaves artifactId unexplained beyond its name. With two params and no schema descriptions, the description should elaborate more on both parameters, especially artifactId.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb 'Undeploy' with resource 'deployed artifact' and effect 'stops it processing messages', clearly distinguishing from siblings like deploy_artifact and list_deployed_artifacts.

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?

Clear context indicated by 'Stops it processing messages' and undeploy operation, but no explicit alternatives or when-not-to-use. The description implies usage for removing an artifact from runtime, but doesn't name alternative 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. It discloses the ALLOW_WRITE permission, which is useful, but does not mention the 'confirm' requirement (must be true to proceed) or any side effects such as whether the update triggers a redeployment or affects running instances. The permission note adds some transparency, but significant behavioral gaps remain.

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 long, front-loaded with the core purpose, and contains no filler. Every word adds value; the permission note is concise and informative.

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 complexity (6 parameters, no output schema, no annotations), the description is somewhat minimal. It omits the confirm requirement (though that is present in the schema) and gives no indication of the response or post-condition. However, the schema does provide some parameter descriptions, and the description clearly states the tool's scope and permission, making it minimally viable but not 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 only 17%, affecting artifactId, parameterKey, and parameterValue which have neither schema descriptions nor elaboration in the tool description. The description's mention of 'single' and 'configuration parameter' provides some context for parameterKey and parameterValue, but it does not compensate for the lack of schema descriptions for these required parameters.

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 ('Update') and a clear resource ('a single externalized configuration parameter of an integration flow'). This precisely distinguishes the tool from siblings like get_flow_configurations and create_integration_flow. The word 'single' also clarifies scope, indicating it updates one parameter at a time.

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 when you need to update a configuration parameter, but it does not explicitly state when to use this tool versus alternatives or mention any exclusions. No sibling tools are referenced, and there is no guidance on prerequisites beyond the ALLOW_WRITE permission.

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