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

Annotations declare destructiveHint=true and the description does not contradict this. The description adds genuine behavioral value beyond the annotation by disclosing the asynchronous nature: it returns a TaskId for polling rather than a synchronous result, which is exactly the kind of trait the agent needs to know and the annotations do not convey.

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

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

Two tight sentences with zero filler. The core action is front-loaded and the essential return behavior is stated in the second sentence. Every word earns its place.

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

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

For a simple two-parameter deploy tool, the description covers the action and the return contract adequately. The gaps are the undocumented parameters (notably what 'version' means and whether it is optional) and the absence of any caveat about the destructive nature of deploying over an existing artifact.

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 provides no parameter information whatsoever. Neither 'id' nor the optional 'version' is explained, so the description fails to compensate for the total lack of schema-level documentation. The agent must guess the meaning and format of both 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 ('Deploy') and a resource ('integration design-time artifact'), which clearly separates it from the large get/search query family and from the upload/download/undeploy siblings. It stops short of explicitly naming a sibling, but the verb alone makes 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 a useful follow-up workflow — returns a TaskId to be polled with get_deploy_status — which tells the agent what to do after calling. However, it gives no guidance on when deploy is appropriate versus upload, nor any exclusions or preconditions (e.g., does the artifact need to be uploaded first?).

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

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

With no annotations, the description carries the behavioral burden and does state the core side effect: a zip is created at the specified output path. However, it does not disclose overwrite/creation behavior, permissions, or error handling, so the transparency 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?

Two short sentences with no filler; the action and format are front-loaded and the output path detail earns its place. Nothing is repeated from the title.

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

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

For a tool with no annotations and no output schema, the description omits important invocation details: the meaning/format of id, the role of optional version, and output_path expectations. It is adequate for the happy path only.

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 explain all parameters. It clarifies that 'id' selects the design-time artifact and that 'output_path' receives the zip, but it leaves 'version' entirely unexplained and does not specify whether output_path is a file or directory or needs a .zip extension.

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

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

The description names a concrete verb ('Download'), a specific resource ('integration design-time artifact (iFlow)'), and the output format ('zip file'). This clearly differentiates from sibling tools like upload_integration_artifact, deploy_integration_artifact, and search/get operations.

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 on when to choose this over alternatives, such as upload_integration_artifact or deploy_integration_artifact. The intended context is only implied by the action 'Download', with no exclusions or sibling comparisons.

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 already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds no extra behavioral context beyond stating it lists mappings; it does not disclose pagination, filtering behavior, or response format. With annotations covering safety, a 3 is appropriate.

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

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

The description is a single sentence with no fluff or redundancy. It is concise and front-loads the core purpose, but it is so brief that it under-specifies, though that is more a completeness issue than a structure issue.

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 low schema coverage, lack of output schema, and many siblings, the description is incomplete. It does not explain parameter usage, differentiate from similar tools, or describe return data. An agent would be left guessing on how to use this tool effectively.

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 provides zero explanation of the five parameters (top, skip, filter, select, orderby). Since the schema does not document them, the description must compensate, and it fails to do so. This is a significant gap for an agent needing to construct correct calls.

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 ('List') and resource ('alternative partner mappings') with a clear definition of the mapping (sender system + interface → partnerID). It is unambiguous about what it returns, but it does not distinguish this from siblings like get_partners or get_message_mappings, so it loses one point.

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

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

There is no guidance on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or conditions that would direct an agent to choose this over sibling tools like get_partners or get_message_mappings.

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

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

The annotation readOnlyHint: true already covers the read-only nature, and the description's verb 'List' is consistent. The description adds a small qualifier ('externalized parameters') which clarifies the scope of configurations, but it doesn't disclose any additional behavioral traits such as whether it returns all versions, how it handles missing versions, or the exact response structure. With the annotation present, a score of 3 is appropriate as some context is added.

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

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

The description is a single, focused sentence that front-loads the action ('List externalized parameters...') and avoids unnecessary detail. It is concise and well-structured for a simple listing tool, though it lacks any additional formatting or elaboration that could aid comprehension.

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 two parameters and no output schema, yet the description provides no information about parameter meaning or the expected return format. Since there is no output schema to rely on, the description should at least indicate what the response contains (e.g., list of configuration names/values). The description is too sparse to fully guide an agent in constructing a correct call and interpreting results.

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%, meaning the input schema provides no descriptions for the parameters 'id' and 'version'. The tool description does not mention these parameters at all, so the agent has no explicit information about what 'id' refers to (e.g., artifact ID) or the semantics of 'version'. The description fails to compensate for the schema gap, leaving the agent to guess.

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: 'List externalized parameters (configurations) for an integration design-time artifact.' It uses a specific verb ('List') and a clear resource ('artifact configurations'), and differentiates from siblings like get_integration_packages or get_integration_flows by focusing on configurations specifically. The existence of update_artifact_configuration also makes the read/get nature evident.

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

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

There is no guidance on when to use this tool versus alternatives. It doesn't mention the context (e.g., retrieving configurations before updating) or any exclusions (e.g., 'use update_artifact_configuration to modify'). No sibling or alternative tools are referenced, leaving the agent to infer the appropriate usage.

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

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

The readOnlyHint=true annotation already declares the safety profile, and the description's 'List' verb is consistent with it. The description adds scoping context ('per partner', 'message sender authorization') but discloses nothing about response format, grouping, or pagination behavior. With annotations covering safety, a 3 is appropriate.

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 nine-word sentence that front-loads the verb and resource and packs scoping context into a parenthetical. Every word earns its place; there is no filler or repetition.

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

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

With five undocumented parameters, no output schema, and only a readOnly annotation, the description leaves the agent to guess at response shape and how partner scoping is requested. Adequate for a simple read-only list endpoint, but a sentence on response format and filter semantics would close the gap.

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

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

Schema description coverage is 0%, so the description must compensate for the five undocumented parameters, but it mentions none of them. Parameter names (top, skip, filter, select, orderby) hint at OData-style paging and projection, yet the agent gets no guidance on how filter/select apply to authorized-user listing or how 'per partner' scoping is expressed.

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 ('List') and resource ('authorized users') and scopes it with 'per partner' and the clarifying parenthetical '(message sender authorization)', which helps distinguish it from close siblings like get_partners and get_user_credentials. It doesn't explicitly name alternatives, so it stops short of a 5.

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

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

The phrases 'per partner' and 'message sender authorization' imply the use case: checking which users are authorized to send messages on behalf of a partner. However, there is no explicit when-to-use guidance, no exclusions, and no mention of when to prefer siblings such as get_user_credentials.

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

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

The readOnlyHint annotation already declares the tool read-only, and the description's 'List' aligns with that. It adds context about the content type (binary parameters like XSLTs and certificates), but it does not disclose pagination behavior, defaults for top/skip, filtering semantics, or response shape. No contradiction with annotations.

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

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

The description is a single, efficient sentence that front-loads the operation and resource, with a short parenthetical giving useful concrete examples. There is no redundant or filler wording.

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 core 'what' of the tool, and the readOnlyHint covers the safety profile. However, all five parameters are unexplained, and there is no mention of pagination, filtering, or response format, so an agent cannot confidently construct a non-default request.

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 provides no explanation for top, skip, filter, select, or orderby. Although these are generic OData-style parameter names, their expected formats, default values, and supported filters are completely undocumented, leaving the agent without meaningful 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 states a specific verb 'List' and resource 'Partner Directory binary parameters', with helpful examples (XSLTs, certificates). It clearly identifies what the tool operates on, and the resource type distinguishes it from siblings like get_string_parameters and get_secure_parameters, though it does not explicitly name those alternatives.

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

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

There is no guidance on when to use this tool versus alternative getters or search tools. The description does not mention that other parameter types have separate tools, nor does it explain when a search variant might be preferable. An agent must infer usage solely from the tool name.

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

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

The readOnlyHint annotation already establishes the operation is read-only. The description adds meaningful behavioral context beyond the annotation: the tool rejects Certificate-type entries and cannot enumerate all certificates. It does not detail return format or pagination, but this is adequate given the annotation coverage.

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 with no fluff. The main purpose is front-loaded, followed by the prerequisite and the key limitation, so an agent can quickly extract the essential 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?

The description is sufficient for safe invocation: it names the required input source, explains the type restriction, and states the tool's listing limitation. It does not describe the output shape or the behavior of the OData-style query parameters, but the read-only annotation and clear purpose lower the burden.

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 important meaning for hex_alias, clarifying that it must come from a Key Pair entry even though the schema does not mark it required. However, skip, filter, select, and orderby are left unexplained, and with 0% schema description coverage the description only partially compensates for the missing parameter documentation.

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: 'Get certificate chain details for a keystore entry.' It also distinguishes itself from the sibling get_keystore_entries by noting that it cannot list all certificates directly, preventing confusion between the two tools.

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

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

Usage guidance is explicit: it requires hex_alias from a Key Pair entry in get_keystore_entries, and it warns that Certificate-type entries are rejected by CPI. It also clarifies a key limitation—'Cannot list all certificates directly'—so an agent knows when not to attempt listing via this tool.

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 already declare readOnlyHint=true, and the description adds a useful behavioral constraint: '$top not supported server-side.' This is helpful but not a rich disclosure; it does not mention auth requirements, response behavior, or other limitations beyond the $top note.

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

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

Two short sentences with no filler. The core purpose is front-loaded and the unsupported-$top caveat is clearly separated at the end. Every word earns its place.

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

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

The tool is simple and the description conveys the core purpose and one important gotcha, but with no output schema and no parameter explanations, an agent has limited guidance on how to construct valid skip/filter/select/orderby values. The note about $top is useful but does not fill the parameter-documentation gap.

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

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

Schema description coverage is 0%, and the description does not explain 'skip', 'filter', 'select', or 'orderby'. The $top note hints at pagination behavior, but the description fails to compensate for the complete lack of parameter documentation in the schema.

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

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

The description states a specific verb ('List') and a specific resource ('data store entries'), and the parenthetical clarifies what those entries are ('persisted key-value records across messages'). This is clear, though it does not explicitly differentiate from sibling tools by 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 gives clear context for when the tool is relevant: listing persisted key-value records across messages. There is no explicit alternative or exclusion, but no obvious sibling tool competes for this exact resource, so the guidance is adequate.

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 already declare readOnlyHint=true, so the read-only safety profile is covered. The description adds that this is a post-deployment status check, but does not describe response shape, failure behavior, or whether the status is polled or one-shot.

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

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

Two short sentences with no filler. The main purpose is front-loaded, and the critical parameter provenance is given in the second sentence.

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

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

For a single-parameter, read-only status tool, the description provides enough to select and invoke it correctly. The main gap is no description of return fields or status values, but this does not block correct invocation.

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

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

Schema coverage is 0%, so the description must explain task_id beyond 'string'. It does exactly that by stating it is the TaskId returned by deploy_integration_artifact. This is meaningful semantic guidance even though format details are not given.

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 ('Check') and a clear resource ('build and deploy status of an artifact'). The reference to the TaskId returned by deploy_integration_artifact clearly distinguishes this from artifact-listing and configuration-retrieval siblings.

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

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

The description gives clear context: this tool should be used with the TaskId returned by deploy_integration_artifact. It does not explicitly state when not to use it or name alternatives, but the usage context is 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?

The annotations only provide readOnlyHint=true, so the description adds meaningful behavior: packageId is mandatory, direct listing is unsupported, and omitting packageId may return 501. This clarifies failure modes beyond what the schema or annotations state.

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

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

The description is compact and front-loads the primary purpose. The second sentence adds the crucial packageId constraint and failure warning. It is slightly repetitive of the title but still efficient.

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 six parameters, no output schema, and no parameter descriptions, the description is not sufficient for reliable invocation. It covers packageId but leaves OData query parameters, return format, pagination, and error handling mostly unspecified.

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 parameter documentation. It meaningfully explains packageId, but top, skip, filter, select, and orderby remain completely undocumented in both schema and description.

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

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

The description states a clear verb and resource: get integration flows from a package. It also adds a scoping constraint by stating packageId is required. It does not explicitly distinguish itself from search_integration_flows, though the packageId requirement implies a different access pattern.

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: packageId is required and direct listing all iFlows is unsupported. It also warns about a possible 501 when listing directly. However, it does not explicitly mention sibling alternatives like search_integration_flows for cross-package searching.

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

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

The readOnlyHint annotation already signals safety; the description adds the meaningful behavioral limitation that $filter and $select are unsupported. However, it does not mention response format, error behavior, or ordering/pagination behavior beyond the raw parameter names, so it offers only moderate value beyond the annotation.

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 well-structured: a single clear purpose sentence followed by a concise behavioral note. Every sentence earns its place without wasted wording.

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

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

For a simple read-only list endpoint this is acceptable, but there are gaps: parameter semantics are unexplainedley and the sibling search_integration_packages is not explicitly recommended for filtered queries. The description covers the essential purpose and a key limitation, but not the full calling context.

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

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

Schema description coverage is 0% and the description does not compensate for this. Although the parameter names 'top', 'skip', and 'orderby' are somewhat self-explanatory, the schema only provides string types with no format details, and the description does not explain how to use them or what values are acceptable.

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

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

The description clearly states a specific action ('Get') and resource ('all integration packages'), making the tool's purpose understandable. It doesn't explicitly differentiate from the sibling search_integration_packages, but the 'all' phrasing provides some distinction.

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

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

The note that $filter and $select are not supported implies that this tool is only appropriate for unfiltered retrieval)Skip if filtering is needed, but it never names the alternative or gives explicit when-to-use guidance. The context is present but only implicitly.

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 declare readOnlyHint: true, which the description matches with 'Get.' The description adds the detail that filtering supports the eq operator with examples, which is a behavioral capability not fully covered by the schema. However, it does not disclose other behaviors like pagination, return format, or error handling. With readOnlyHint already covering the read-only nature, this adds moderate value.

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

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

Two sentences with no filler. The first sentence states the purpose, and the second provides filter detail. Information is front-loaded and every word earns its place.

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

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

For a tool with five optional parameters and no output schema, the description is incomplete. It only explains filter, leaving the other OData-style parameters unexplained. It also doesn't mention the relationship to search_integration_runtime_artifacts. An agent would lack sufficient context to correctly use the tool beyond basic filtering.

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 explains the filter parameter with syntax and examples, which is helpful. But top, skip, select, and orderby are left completely undocumented. The description only covers one of five parameters, failing to adequately compensate for the lack 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 states a clear verb and resource: 'Get all integration runtime artifacts.' It identifies the tool's primary action and the object it operates on. However, it does not explicitly differentiate from the sibling search_integration_runtime_artifacts, though the name and 'all' imply a listing behavior. It's clear but lacks explicit sibling differentiation.

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 about when to use this tool versus the search variant or other sibling tools. It doesn't mention alternatives or conditions that would select one over the other. The phrase 'Get all' hints at a broad list, but the description does not state when to prefer this over search_integration_runtime_artifacts.

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

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

The annotation declares readOnlyHint=true, and the description's action verb 'List' aligns with that; there is no contradiction. The description adds useful context by warning about a possible 501 status, which is a behavioral trait not captured in the schema or annotations. This is a helpful addition beyond the structured 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?

The description is a single, short sentence with a parenthetical. It is concise and covers the main purpose efficiently. It is front-loaded with the core action and resource. Nothing is redundant, though it could have used the sentence to add a hint about parameter usage instead of the parenthetical.

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 is minimal but the tool is a simple list operation with no required parameters, so the bar for completeness is lower. The annotations cover read-only behavior, and the parenthetical covers an edge case. However, given the low schema coverage and zero parameter documentation, a fuller description could have clarified what the parameters are for (e.g., OData-style queries), which would materially help an agent construct valid calls.

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%, meaning the schema provides no descriptions for the parameters, and the description does not explain what 'top', 'skip', 'filter', 'select', or 'orderby' mean or how they should be used. The description names none of the parameters. Since there are 5 parameters with no documentation anywhere, the description fails to compensate; a baseline of 3 is not justified.

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

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

The description states the action ('List') and the resource ('JMS broker instances'), and it mentions 'status' as part of the output. It is clear enough to distinguish from the many sibling tools, though it does not explicitly name a sibling to contrast with. The phrase 'and their status' adds a bit of specificity.

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

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

No explicit guidance on when to use this tool versus alternatives, but the context signal of the tool name and the sibling list make it clear it is one of many 'get_' tools. The parenthetical 'may return 501 depending on tenant' provides some situational context about availability, but there is no explicit when/when-not 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?

The readOnlyHint annotation already signals a safe read operation, and the description aligns by saying 'List'. It adds some behavioral context by naming what the returned resource view contains, but it does not disclose pagination behavior, ordering, or any limitations. This is acceptable given annotation coverage, but not rich.

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 efficient, front-loaded sentence with no filler. It is appropriately concise, though it could have used the brevity to add a bit more differentiation or parameter context.

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

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

With no output schema, zero parameter descriptions, and a large sibling set containing similar JMS/messaging tools, the description is too thin to fully orient an agent. It names resource attributes but does not clarify the response shape, pagination semantics, or how this relates to get_jms_brokers/get_messaging_queues.

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 what top, skip, filter, select, or orderby mean in this context. The word 'List' implies these are list-query parameters, but the description adds no concrete detail beyond the schema's bare parameter 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 action ('List') and the resource ('JMS queue resources') and adds useful specifics (queue depth, consumer count, capacity status). It does not explicitly differentiate from closely related siblings like get_jms_brokers or get_messaging_queues, so it stops short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives such as get_jms_brokers or get_messaging_queues. There are no exclusions, prerequisites, or context signals that would help an agent decide 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?

The readOnlyHint annotation already marks this as a safe read operation, and the description adds a concrete server-side behavior by noting that $top is not supported. This goes beyond the structured fields, though it does not describe the return 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 concise: a single action statement with scope plus one short caveat. Nothing is redundant, and the most important information 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?

For a tool with no output schema and no parameter descriptions, the description leaves the query parameter semantics and return shape unstated. It captures the scope and one limitation but is not complete enough for an agent to call 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?

Schema description coverage is 0%, and the description provides no explanation of skip, filter, select, or orderby. The description fails to compensate for the missing parameter documentation.

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 resource ('keystore entries'), and the parenthetical clarifies that these are certificates and key pairs deployed on the tenant. It is clear but does not explicitly differentiate this tool from sibling tools such as get_certificate_resources.

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

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

There is no guidance about when to use this tool versus the many sibling get_/search_ tools. The $top note is a server limitation, not a routing or alternative-selection guideline.

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 already declare readOnlyHint=true, and the description adds a useful behavioral caveat: '$top not supported server-side; may return 501 depending on tenant.' This warns the agent about a possible failure mode beyond what the annotation conveys.

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 only two sentences, with the purpose front-loaded and a single high-value caveat following. There is no redundant or filler phrasing.

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

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

The tool has four undocumented parameters and no output schema, so the description should carry more weight. It covers purpose and one server-side limitation, but leaves parameter syntax, return shape, and pagination behavior completely unexplained.

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 explain the four parameters (skip, filter, select, orderby). It does not explain any of them, and the only query-option note references $top, which is not even in the schema. The agent gets no meaningful parameter 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 uses a specific verb and resource: 'List runtime log files for troubleshooting iFlow execution.' This is clear and adds context beyond the title, but it does not explicitly differentiate from sibling tools like get_trace_content or get_message_processing_logs.

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

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

The phrase 'for troubleshooting iFlow execution' provides a clear use context. It does not name alternatives or state when not to use this tool, but the intended scenario is reasonably 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?

The readOnlyHint annotation already signals a safe read operation. The description adds that it 'Supports listing and $top,' which gives some behavioral context about pagination/limiting, but it does not disclose return format, pagination behavior beyond $top, or any other side effects. This is acceptable but not rich.

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

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

The description is two short sentences with no filler. 'Get all message mappings.' is front-loaded and clear, and 'Supports listing and $top.' adds a relevant detail without unnecessary 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?

With 5 undocumented parameters, no output schema, and 0% schema description coverage, the description is noticeably incomplete. It names only $top and gives no information about filtering, sorting, selecting fields, or what a message mapping looks like. The agent cannot confidently use the advanced query parameters.

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 undocumented parameters. It mentions only '$top' but does not explain its meaning (e.g., maximum number of results). The parameters skip, filter, select, and orderby are entirely unaddressed, leaving the agent without adequate 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 states a specific verb and resource: 'Get all message mappings.' The word 'all' hints at a full listing as opposed to the sibling search_message_mappings, but it does not explicitly differentiate from that sibling. Thus it is clear but lacks direct sibling differentiation.

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

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

The phrase 'Get all message mappings' implies this tool is for retrieving the full set of mappings, contrasting with search_message_mappings. However, it gives no explicit when-to-use guidance, no exclusion criteria, and no mention of alternatives. Usage is only implied, not stated.

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

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

Annotations already declare readOnlyHint=true, and the description's use of 'Get' is consistent, so there is no contradiction. However, the description adds only minimal behavioral context beyond the annotation, such as the fact that attachments include payloads and traces. It does not disclose pagination behavior, error handling, or any side effects. Since the annotation covers the safety profile, this is acceptable but not exceptional.

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 with no filler. It front-loads the verb and resource, then adds scope. Every word contributes to the meaning. This is an exemplary example of conciseness.

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 6 parameters, none described in the schema, and no output schema, the description is grossly incomplete. It provides no information about what the response looks like, how to use the optional parameters, or any constraints. An agent calling this tool would be largely guessing on parameter formats and expected results. This is far below the minimum viable definition 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?

The schema has 0% description coverage, and the description only indirectly references the required parameter message_guid ('specific message processing log entry'). The other five parameters (top, skip, filter, select, orderby) are entirely unexplained. An agent would have no idea what these OData-style query parameters do or how to format them. The description fails to compensate for the missing 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 the action (get), the resource (attachments), and the scope (for a specific message processing log entry). It even gives examples of what attachments are (payloads, traces), which helps disambiguate from sibling tools like get_message_processing_logs or get_message_processing_log_errors. This is a precise and unambiguous definition.

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

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

No guidance is given on when to use this tool versus alternatives. It does not mention any exclusions, prerequisites, or conditions that would help an agent decide between this and the many sibling get_* tools. The only implicit signal is the name itself, but no explicit routing or 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?

The readOnlyHint annotation already signals a safe read operation, and the description adds no further behavioral detail. It does not disclose return shape, whether multiple errors can be returned, pagination behavior, or how message_guid is scoped. The description is not misleading but misses an opportunity to add context.

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

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

A single, front-loaded sentence with no wasted words. It efficiently communicates the core action and object, which is all that conciseness demands for this short description.

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 and only one parameter, the description is too thin. It does not specify what 'error details' includes, how a valid message_guid is obtained, or what error cases exist. An agent may know what the tool does but will lack confidence about the response format and input provenance.

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 provides only a message_guid string with 0% description coverage, and the description does not explain what message_guid is or where to find it. The parameter name is somewhat self-explanatory, but the description should clarify that it refers to the message processing log entry.

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 ('Get') and resource ('error details for a specific message processing log entry'). The word 'errors' distinguishes it from sibling tools like get_message_processing_log_attachments and get_message_processing_log_properties, but it could more explicitly mention the message_guid parameter.

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. It does not state that message_guid should come from get_message_processing_logs or that other aspects like attachments, properties, or runs are handled by the corresponding 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?

The annotation readOnlyHint: true already covers the read-only nature, so the description does not need to restate that. It adds that the tool retrieves specific header properties, but it does not disclose any additional behavioral details like error handling, empty results, or performance characteristics. Given the annotation coverage, a score of 3 is appropriate.

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

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

The description is a single sentence with no superfluous words. It is concise and front-loaded with the key action and target, making it 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?

The tool has a simple one-parameter schema and no output schema, so the description should at least hint at the return format. It states the properties are 'custom header properties' but does not describe the structure (e.g., a map or list) or what happens if no properties exist. This leaves some ambiguity, but given the simplicity, it is adequate.

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

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

Schema description coverage is 0%, so the description must compensate for the parameter. It mentions 'for a message log entry' which implies the message_guid is an identifier, but it does not explicitly describe its format, required status, or purpose beyond that. The parameter name is self-explanatory, but the description adds minimal 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 clearly states the tool's purpose: it retrieves custom header properties (SAP_ApplicationID, business IDs) for a specific message log entry. The verb 'Get' combined with the resource 'custom header properties' and the specific examples distinguish it from sibling tools that fetch logs, errors, attachments, or runs.

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 its use case by specifying the type of data it returns, but it does not explicitly state when to choose this tool over alternatives. For example, it does not say 'use this when you need only custom headers' or contrast it with get_message_processing_logs. The guidance is 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?

The readOnlyHint annotation already declares the operation as read-only, and the description's 'Get' verb is consistent with that. The description adds the domain detail that a message log entry can have multiple individual processing step runs, but it does not disclose ordering, pagination, or result shape.

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

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

The description is a single sentence with no filler. The core object is front-loaded, and the phrasing is compact and precise for a single-parameter read-only getter.

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

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

For a simple read-only resource with one required parameter, the description provides enough to make a correct call: it identifies the resource and the input's role. It omits an explicit output format and usage exclusions, but the readOnlyHint and simple schema keep the gap small.

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 a message log entry' gives message_guid its semantic role as the identifier of the log entry whose runs should be fetched, which is meaningful despite the sparse 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 identifies a specific verb and resource: 'Get individual processing step runs for a message log entry.' This distinguishes it from tools like get_message_processing_logs and get_message_processing_log_errors, though it does not explicitly contrast it with the similar get_run_steps 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?

No guidance is given for when to use this tool versus related siblings such as get_message_processing_logs or get_run_steps. The intended context must be inferred from the tool name and sibling list rather than 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?

The description is consistent with the readOnlyHint annotation, using 'List' which matches the read-only nature. It adds value by disclosing default top and ordering, but does not describe the response format or pagination behavior beyond defaults. Given the annotation, the description carries moderate additional context.

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

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

The description is two sentences, front-loaded with the primary action and filter capabilities, followed by default behavior. No wasted words; it is concise and 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?

With no output schema and 5 generic parameters at 0% schema coverage, the description is incomplete. It does not explain the meaning of top, skip, filter, select, or orderby, nor does it describe the returned data structure. The description leaves an agent without enough information to construct a valid filter or understand the response.

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

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

Schema coverage is 0%, and the description does not explain the generic OData parameters (top, skip, filter, select, orderby). It mentions filter fields like Status and IntegrationFlowName but not how to construct the filter string. The description fails to compensate for the complete lack of parameter documentation in the schema.

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

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

The description clearly states the tool lists message processing logs and mentions filter capabilities (Status, IntegrationFlowName, LogStart/LogEnd). It is specific about the resource and action, though it doesn't explicitly differentiate from sibling tools like get_message_processing_log_errors or get_message_processing_log_attachments, which are more specialized.

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 listing logs and provides default behavior (top=20, ordered by LogEnd desc) but does not state when to use this tool versus alternatives such as error-specific logs or attachment logs. No explicit when-not or alternative 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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by enumerating the fields returned in each message, which goes beyond the annotation. It does not contradict annotations. However, it omits details like pagination behavior or how the filter parameter works, but given the read-only nature, this is sufficient.

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 primary action, and efficiently lists the fields without excess. Every sentence contributes to understanding the tool's purpose and scope. No wasted 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?

The description covers the core purpose and return fields, but lacks details on pagination (top/skip), ordering, and the OData filter syntax. It does not reference sibling tools to guide selection. Given no output schema and sparse parameter documentation, the description leaves an agent with gaps on how to properly construct queries beyond the queueName hint.

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

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

Schema coverage is 0%, so the description must compensate. It introduces queueName as a filter mechanism, but that parameter is not in the schema; it likely refers to a filter expression. The description does not explain top, skip, filter, select, or orderby, which are the actual schema parameters. This is a significant gap for a tool with 5 parameters and no 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 the action (list) and the resource (individual JMS messages), and provides specifics about filtering by queueName and the fields returned. This distinguishes it from sibling tools like get_messaging_queues (which lists queues) and retry/move tools. The verb+resource is unambiguous.

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

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

The description provides a usage hint by mentioning the queueName filter for scoping, but does not explicitly state when to use this tool versus alternatives like retry_messaging_messages or move_messaging_messages. There is no exclusion or 'when not to use' guidance. The context is clear but lacks explicit differentiation.

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 already declare readOnlyHint=true, so the description adds no new safety information. It does mention the output includes message counts and status, which is useful context beyond the annotation, but lacks details like pagination defaults or whether hidden queues are included.

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 concise sentence that front-loads the core purpose and output details. No waste, though adding brief parameter guidance could be done without harming conciseness.

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?

It lacks an output schema and only partially describes the data. With 5 undocumented OData parameters, an agent cannot determine valid filters, select fields, or ordering without external knowledge. The description covers the 'what' but not the 'how' to call effectively.

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 5 parameters (top, skip, filter, select, orderby) with 0% coverage in the description. The description does not explain what these parameters do, how to format OData syntax, or defaults. The agent has no guidance on using them, making this a significant gap.

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

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

The description clearly states the tool lists JMS messaging queues and includes specific details (per-queue message count, active/exclusive status). This distinguishes it from siblings like get_jms_brokers and get_messaging_messages.

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 implies use for retrieving queue information, which fits the get_* pattern, but does not explain when to prefer it over get_jms_brokers (which lists brokers) or get_messaging_messages (which lists individual messages). No explicit alternatives or exclusions 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?

Beyond the readOnlyHint annotation, the description discloses the ~184KB full size and the 50KB truncation behavior. This is critical for an agent deciding whether the response is sufficient, and it adds real value beyond the annotation.

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 that front-load the core action and immediately follow with the most important caveat. No wasted 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?

For a parameterless, read-only tool, the description fully covers what is returned, its format, its size limitation, and where to get complete metadata. Nothing essential is missing.

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

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

The tool has zero parameters and schema description coverage is 100%, so there are no parameter semantics to clarify. Baseline 4 is appropriate since no parameter information is needed.

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

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

The description names the exact resource ('OData $metadata service document') and explains its contents ('XML schema of all entity sets, properties, and associations'), making the tool's purpose unambiguous and distinct from all sibling getters.

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 clearly communicates when the truncated response is insufficient and directs the user to the local reference file for complete metadata. It does not name a sibling tool alternative, but no sibling provides metadata, so this context is adequate.

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

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

The annotation readOnlyHint=true already signals that this is a safe read operation. The description adds the note that $top is not supported server-side, which is a useful behavioral limitation. However, it does not disclose return format, pagination behavior, or other potential side effects. Given the annotation covers the safety profile, the description adds modest context beyond it.

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

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

The description is a single sentence with a brief note, front-loading the core purpose and adding a relevant limitation. Every word earns its place, and there is no redundancy or unnecessary detail.

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

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

For a list tool with four parameters and no output schema, the description is incomplete. It does not explain what fields a number range includes, how pagination works (beyond the $top note), or the meaning of the parameters. An agent would struggle to form a correct query without external knowledge of OData conventions.

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 provides no information about any of the four parameters (skip, filter, select, orderby). The parameter names hint at OData conventions, but the agent receives no explanation of expected formats, defaults, or interactions. The description fails entirely to compensate for the missing 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 states a specific verb ('List') and resource ('number ranges'), and clarifies what they are (auto-incrementing sequences for message numbering). It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools beyond the resource name, which is distinct enough. The added clarification about the resource type adds value.

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 a limitation about $top, which is a behavioral detail, not usage guidance. There are no exclusions or references to sibling tools for comparison, leaving the agent to infer usage based on the resource name alone.

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 already declare readOnlyHint=true, and the description's 'List' is consistent. The description adds a meaningful behavioral note that $top is not supported server-side, which is beyond the annotations and useful for agents constructing queries. It does not contradict any annotations, and this extra limitation disclosure justifies a strong 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 two short sentences, front-loaded with the primary action and scope, followed by a concise limitation note. It is efficient with no redundant phrasing, though it could have added more utility without becoming verbose. The structure is appropriate for a simple list operation.

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 four optional parameters and no output schema, the description is too sparse. It fails to explain the purpose or expected format of any parameter, and does not mention pagination, return structure, or any other operational context. For an agent to correctly construct a query, the missing parameter semantics are a significant gap.

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

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

Schema description coverage is 0% and the description provides no explanation of the four parameters (skip, filter, select, orderby). The only mention, $top, is not even a parameter in the schema. With zero schema coverage, the description fails to compensate by explaining parameter syntax, valid values, or usage, leaving agents without guidance on how to use these options.

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 'List' and the resource 'OAuth2 client credential configurations' with a scope of 'deployed on the tenant', making the purpose specific and easily distinguishable from siblings by resource type. However, it does not explicitly name an alternative tool or contrast with similar get_* tools, so it stops short of the highest rating.

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 such as get_user_credentials or get_keystore_entries. It relies solely on the resource name for differentiation, offering no explicit conditions or exclusions. An agent would need to infer usage from the tool name alone.

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

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

The readOnlyHint annotation already signals that this is a safe read operation, and the description does not contradict it. The description adds only the basic facts that it lists all Partner Directory partners, but it does not disclose query semantics such as pagination defaults, result size, or whether filter/select change how many entries are returned. Given the annotation carries the main safety context, a middle score is fair.

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 compact sentence that leads with the core action and resource. The parenthetical adds useful specificity without introducing 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?

This is a five-parameter endpoint with no output schema and no parameter documentation. The description only says 'list all', but does not clarify whether the query options are supported for pagination/filtering, what the response shape is, or whether 'all' means an unrestricted listing or a configured page size. More explanation is needed for an agent to invoke this tool correctly beyond sending empty arguments.

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 description coverage is 0%, and the description does not explain top, skip, filter, select, or orderby beyond their self-evident parameter names. There is no mention of supported filter syntax, selectable fields, ordering capabilities, or interdependencies between these parameters, so the description fails to compensate for the schema gap.

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

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

The description names a specific verb ('List') and resource ('Partner Directory partners') plus a clarifying parenthetical ('trading partner routing entries') that makes the tool's target clear. It is distinguishable from the sibling get_alternative_partners, so an agent can understand what this tool returns without opening the schema.

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

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

There is no guidance on when to use this tool instead of sibling search or get_* alternatives, nor any note about the intended default use case. The description does not mention whether this is the canonical listing endpoint or when a caller should prefer a more filtered search tool.

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

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

The readOnlyHint annotation already covers the non-destructive safety profile, and the description goes beyond that by stating what the tool returns: step IDs, activities, status, timing, and model step IDs. However, it does not disclose potential ordering, pagination, missing-run behavior, or error cases, so transparency 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 two sentences, front-loaded with the core action, followed by return fields and the parameter source. Every sentence carries useful information 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?

Given the tool has only one parameter, no output schema, and a readOnly annotation, the description is largely complete: it explains what the tool does, what it returns, and where the required RunId comes from. It could add error/precondition details, but nothing critical is missing for invoking the tool correctly.

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

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

The schema only defines run_id as a string with no semantic help. The description compensates by explicitly saying the RunId comes from get_message_processing_log_runs, which tells the agent exactly which value to pass. For a single parameter, this is sufficient 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 states a specific verb and resource: 'Get all processing steps for a message run.' It clearly distinguishes this tool from sibling tools like get_message_processing_log_runs by focusing on processing steps rather than the run list itself. It also lists the key returned fields, making the tool's purpose immediately understandable.

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

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

The description explicitly says it 'Requires RunId from get_message_processing_log_runs,' giving the agent a concrete usage sequence and source for the required parameter. It doesn't explicitly name alternatives or when-not-to-use conditions, but given the single-purpose nature and sibling set, this is clear enough context.

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

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

Annotations already declare readOnlyHint=true, and the description adds a meaningful behavioral constraint: packageId is required despite being optional in the schema, and global listing is unsupported. It does not cover response or pagination details, but for a read-only list tool this is reasonable.

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 front-loads the core action and immediately follows with the key usage constraint. No wasted 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?

Adequate for a simple read-only list operation, but with no output schema and six underdocumented parameters, it leaves pagination semantics, return shape, and the relationship to search_script_collections unaddressed. It is not complete enough for an agent to call it with full 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?

With 6 parameters and 0% schema description coverage, the description must compensate, but it only explains packageId. The top, skip, filter, select, and orderby parameters are left entirely to inference from their names.

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

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

The description clearly states the action ('Get script collections') and the scope ('from a package'), which distinguishes it from a generic list-all tool. However, it does not explicitly differentiate from the sibling search_script_collections, so it falls 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?

It gives clear usage context: you must supply a packageId and listing all directly is not supported. It does not name the alternative search_script_collections or state when to prefer it, so it is not fully 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?

The readOnlyHint annotation already signals a safe read operation. The description adds one useful behavioral detail: $top is not supported server-side, which warns the agent that pagination via $top will fail. It does not disclose other behaviors like default page size, filtering limitations, or whether the values are returned decrypted, but the annotation covers the safety profile.

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 plus a short note, with no wasted words. The core purpose is front-loaded, and the $top caveat is appended efficiently. It earns a 4 for being compact and readable, though it could have used the space to explain parameters instead.

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 parameter documentation, and only a one-line description, the tool definition is incomplete for an agent that needs to know how to use skip, filter, select, and orderby. The $top note is a small piece of server behavior, but the overall context is thin for a tool with four undocumented parameters.

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 four undocumented parameters (skip, filter, select, orderby). The description only mentions $top, which is not even a parameter in the schema, and provides no meaning for skip, filter, select, or orderby. This is a significant gap for an agent trying to construct a correct request.

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 ('List') and resource ('secure parameters'), and clarifies they are encrypted configuration values. It distinguishes itself from sibling tools like get_string_parameters and get_binary_parameters by naming the resource type, though it doesn't explicitly contrast with those siblings.

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

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

The description implies a read-only listing operation, and the readOnlyHint annotation reinforces that. However, it provides no explicit guidance on when to choose this tool over alternatives like get_string_parameters or get_binary_parameters, nor does it mention any exclusions or prerequisites.

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

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

The annotation readOnlyHint=true already establishes that this is a read-only operation. The description's 'List' is consistent and clarifies that the result is a collection of parameters rather than a single record, but it adds no further behavioral context such as pagination, limits, or response shape. No contradiction.

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 wasted words. The examples add useful context without bloating the description.

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?

While the read-only annotation and concise resource description help, the total absence of parameter semantics and any mention of response format leaves an agent to infer OData conventions and return structure. This is not complete enough for precise 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 5 parameters (top, skip, filter, select, orderby) with 0% description coverage. The description does not explain any of these query parameters or their syntax, and the provided examples are domain values, not input semantics. It fails to compensate for the schema gap.

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

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

States a specific resource ('Partner Directory string parameters') and operation ('List'), with concrete examples (MaxJMSRetries, DLQ_EndEvent). The word 'string' also distinguishes it from sibling tools like get_binary_parameters and get_secure_parameters.

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 on when to use this tool versus alternatives such as get_binary_parameters or get_secure_parameters. There are no stated conditions, exclusions, or selection criteria; the intended usage is only implied by the resource name.

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 already declare readOnlyHint=true, and 'Fetch' is consistent with that read-only profile. The description adds useful context about what each include value returns and where trace_id originates, but does not disclose failure modes (e.g., behavior for an unknown trace_id) or response formatting. With annotations carrying the safety burden, this is adequate but not rich.

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

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

Three sentences with no waste: purpose is front-loaded, parameter semantics are compactly enumerated, and provenance is stated last. Every sentence earns its place; length is proportional to the information density required.

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

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

For a simple two-parameter read tool, the description covers what the tool does, the meaning of every parameter value, and how to source the required trace_id. Minor gaps: no hint about the returned content structure (there is no output schema to defer to) and it references get_message_trace, which is not among the listed sibling tools, though the other source get_run_steps is present.

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

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

Schema description coverage is 0%, so the description carries the full burden, and it delivers: each enum value is mapped to its meaning ('payload' for message body, 'headers' for HTTP headers, 'properties' for exchange properties, 'all' for everything), and the trace_id parameter gets provenance guidance. The schema's raw enum names are cryptic without this elaboration.

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

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

The description opens with a specific verb+resource pair ('Fetch trace content for a specific trace message'), which clearly states what the tool does. The elaboration of the 'include' options makes the scope of 'content' explicit, distinguishing it from sibling trace/logging tools like get_run_steps and get_message_processing_logs.

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 sentence 'TraceId comes from get_run_steps or get_message_trace' provides clear workflow context, telling the agent this tool is a follow-up to those tools and how to obtain the required parameter. It stops short of naming alternatives and giving explicit when-to-use-this-instead conditions, so it is clear context without 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?

Annotations already include readOnlyHint=true, so the description doesn't need to restate that. It adds valuable context by noting that $top is not supported server-side, which affects pagination behavior, and clarifies that the credentials are basic auth username/password pairs rather than OAuth tokens. This goes beyond the annotations and helps the agent avoid an unsupported 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 succinct: a single sentence stating the core purpose plus a short note about a limitation. It is front-loaded with the essential action and resource type, and the note is concise and relevant. No word is wasted, making it easy to parse quickly.

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 that there is no output schema and no parameter descriptions, the description is insufficient for an agent to use the tool effectively. It fails to explain the meaning of the four parameters or hint at the response structure. The $top note is useful but does not cover pagination alternatives (e.g., skip). The tool's complexity is low, but the missing parameter semantics make the guidance incomplete.

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

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

Schema description coverage is 0%, meaning the schema properties (skip, filter, select, orderby) have no descriptions. The tool description does not compensate at all—it mentions none of the parameters or their intended use. Without any explanation, the agent cannot correctly construct parameter values or understand what each one does, resulting in a critical gap.

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

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

The description clearly states the verb 'List' and the specific resource 'deployed user credentials (basic auth username/password pairs)'. It distinguishes itself from sibling tools like get_oauth2_credentials and get_authorized_users by specifying the exact credential type, leaving no ambiguity about what the tool retrieves.

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 its siblings. While the note about $top not being supported is a usage constraint, it does not help the agent choose between get_user_credentials and get_oauth2_credentials or other credential-related tools. No explicit exclusions or alternatives are mentioned.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the useful contextual trait that this is a listing operation supporting $top pagination, but discloses nothing else about behavior such as default page size, max results, or how skip/filter/select/orderby behave.

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

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

Two short sentences with the main action front-loaded; there is no filler or repetition. The only minor structural flaw is that 'Supports listing and $top' awkwardly couples a behavior with a parameter, and the singular emphasis on $top is arbitrary given the other four parameters.

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 five optional OData-style parameters and a direct sibling (search_value_mappings), the description is too thin. It does not help an agent decide between get and search, does not explain the filter/skip/select/orderby parameters, and given no output schema, offers no indication of what the response looks like.

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 carries the full burden for parameter meaning. It mentions only $top, leaving skip, filter, select, and orderby undocumented. The bare parameter names hint at OData-style semantics, but the description never says they are OData query options or explains their syntax.

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

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

The description clearly states a specific verb and resource ('Get all value mappings') and signals the operation type ('Supports listing'). This distinguishes it from search_value_mappings, since 'get all' implies a full listing versus a filtered search, though it never names the sibling explicitly.

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

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

There is no guidance about when to use this tool versus search_value_mappings or get_message_mappings. The phrase 'Supports listing' weakly implies a paginated list use case, but no context, exclusions, or alternative-selection criteria are provided, leaving the agent to infer the choice.

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

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

The description adds a non-obvious server-side limitation ($top unsupported) and explains that variables persist across iFlow executions, giving context beyond the readOnlyHint annotation. It does not address response format or pagination details, but the annotation already covers safe read 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?

Two short sentences with the core purpose first and the caveat second. No filler or redundancy; every clause adds 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?

The description is adequate for a read-only list operation and includes the meaningful $top caveat, but it omits any explanation of the optional query parameters and does not describe the return shape. Without an output schema, a bit more parameter context would make this 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?

None of the four parameters (skip, filter, select, orderby) are described in the description, and schema description coverage is 0%. The $top note does not explain any listed parameter, so the agent gets no semantic help for these OData query options.

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

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

Clearly states it lists runtime variables and defines them as state maintained between iFlow executions. This verb-resource pair distinguishes it from parameter- or artifact-focused siblings, though it does not explicitly name an alternative.

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 no guidance on when to use this tool over siblings like get_string_parameters or get_secure_parameters. It states only what it does and a server-side limitation, with no selection criteria 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?

The annotations already declare destructiveHint=true, and the description adds the HTTP method (POST) and return type (server response string). It does not elaborate on side effects beyond the implied destructive move, but given annotation coverage the additional context is moderate.

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 that front-load the core action and return value with no unnecessary words or repetition. Every part earns its place.

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

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

For a zero-parameter tool with no output schema and a destructive annotation, the description covers the action, mechanism, and return type well. It could briefly mention the destructive effect, but annotations already carry that warning, leaving no critical gaps.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter meanings, and it adds context about the underlying function import without being misleading.

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 ('Move') and resource ('JMS messages between queues'), making the tool's function immediately clear. It distinguishes itself from sibling tools like retry_messaging_messages and get_messaging_messages by specifying the move-between-queues behavior.

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

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

The usage is implied by the purpose statement: use this tool to move JMS messages between queues. However, it does not explicitly contrast with alternatives such as retry_messaging_messages or provide when-not-to-use guidance.

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

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

Annotations already flag destructiveHint: true, and the description adds only that it is a POST and returns a server response string. It does not disclose what 'retry' entails (e.g., whether it resends, clears, or duplicates messages), nor does it explain any side effects beyond the destructive hint. With a destructive operation, more behavioral context is needed.

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, consisting of two short sentences that state the action and the return value. It avoids fluff, but it is arguably too terse for a destructive operation, missing opportunities to clarify behavior within the same length.

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 lacks critical context for a destructive operation. It does not clarify what scope 'failed JMS messages' covers (all messages, a specific queue?), whether any prerequisites exist, or what the server response string signifies. Given the destructive nature, an agent would benefit from knowing the impact before calling.

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 empty schema provides complete coverage. According to the baseline for 0-parameter tools, a score of 4 is appropriate. The description does not need to explain parameters, and it doesn't.

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 (retry), the target (failed JMS messages), and the mechanism (RetryMessagingMessages function import, POST). It distinguishes itself from siblings like get_messaging_messages (retrieval) and move_messaging_messages (moving) by explicitly focusing on retrying failed messages.

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. There is no mention of scenarios where retry is appropriate, nor any exclusion criteria or mention of other tools for moving or fetching messages. The agent is left to infer usage context.

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

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

Annotations already declare readOnlyHint=true, aligning with the read-only 'Search' action. The description adds valuable behavioral detail by explaining the underlying mechanism (direct entity lookup or $filter on runtime artifacts), which goes beyond the annotation and helps the agent understand what happens internally. It does not mention potential edge cases like empty results or result limits, but given the annotation coverage, this is sufficient.

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

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

The description is two sentences with no redundancy. It front-loads the primary action and resource, then adds a concise technical detail. Every word contributes value, making it highly efficient.

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 three optional parameters and no output schema, the description covers the search criteria and the method. It does not describe the return format (e.g., list vs single result), but this is common for search tools and may be implied. Given the low complexity, the description is mostly complete for an agent to call it correctly, though adding a note about return type would make it fully complete.

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

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

The input schema has 0% description coverage, so the description carries the burden of explaining the parameters. It mentions 'by ID, version or name', which clarifies the purpose of each parameter. However, it does not specify whether parameters are mutually exclusive, combinable, or how they interact (OR vs AND). The meaning is partially added but not fully elaborated, so a baseline 3 is appropriate.

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

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

The description clearly states the verb 'Search' and the resource 'integration flows', and specifies the search criteria (ID, version, name). It distinguishes this from siblings like get_integration_flows (likely a direct fetch) and search_integration_runtime_artifacts (searching artifacts rather than flows). The exact-match qualifier further separates it from fuzzy searches.

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 exact-match lookups but does not explicitly name alternatives or provide when-not-to-use guidance. The mention of 'exact match via direct entity lookup or $filter on runtime artifacts' gives some context on the approach, but it does not state when this tool should be chosen over sibling search tools. No exclusion criteria 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?

Annotations already declare readOnlyHint=true, so the description's statement that it fetches all packages and filters client-side adds useful behavioral context beyond the annotation, such as the lack of server-side filtering. However, it does not describe pagination, response format, or how filters combine, leaving some behavioral aspects 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?

Two sentences, no filler, front-loaded with the purpose and then the key behavioral note. Every word earns its place, making it easy to scan and understand.

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

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

The tool has five optional parameters, no output schema, and minimal annotation coverage (only read-only hint). The description explains the basic search function and client-side filtering but omits critical details like return value structure, how filters interact, and any performance caveats beyond the filtering note. For a tool with this complexity, it is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It lists the five parameters (ID, version, name, vendor, mode) matching the schema, which tells the agent what fields exist but adds no additional meaning about matching behavior (exact vs. partial), case sensitivity, or combination logic (AND/OR). This is minimal but not completely absent.

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

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

States the specific action 'search' on 'integration packages' and lists the filterable fields (ID, version, name, vendor, mode). While it clearly identifies the resource and operation, it does not explicitly differentiate from sibling 'get_integration_packages' which likely returns all packages without filtering, though the 'search' verb and the mention of client-side filtering imply a distinction.

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

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

No explicit guidance on when to use this tool versus alternatives. The description notes that it fetches all packages and filters client-side, which hints at use cases needing filtering, but does not mention that 'get_integration_packages' might be more appropriate for unfiltered access, nor does it discuss performance trade-offs or 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?

The annotation readOnlyHint=true already signals a safe read operation, so the description doesn't need to restate that. The description adds the 'Uses eq filter' detail, which is useful behavioral context about how filtering works. However, it doesn't disclose other behavioral traits like pagination, result limits, or whether multiple filters combine with AND/OR.

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

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

The description is two short sentences with no wasted words. The main purpose is front-loaded, and the filter detail is a useful addition. It could arguably include a bit more guidance, but for its length it is efficient.

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, 0% schema coverage, no output schema, and no enum constraints, the description is thin. An agent knows it can search by these fields but doesn't know how the eq filter behaves across multiple parameters, what the response looks like, or how this search differs from the sibling get_integration_runtime_artifacts. The readOnly annotation covers safety, but operational completeness is lacking.

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 5 undocumented parameters. The description lists the parameter names (ID, version, name, type, status) but adds no additional meaning beyond what the schema property names already convey. It doesn't explain value formats, allowed values, or how the eq filter applies to each 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 states a clear verb ('Search') and resource ('integration runtime artifacts') and lists the filterable fields (ID, version, name, type, status). It distinguishes itself from sibling get_integration_runtime_artifacts by implying a search/filter operation rather than a direct get, though it doesn't explicitly name the 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 usage for searching/filtering artifacts, and the sibling list includes get_integration_runtime_artifacts, suggesting a get-vs-search distinction. However, it doesn't explicitly state when to use this tool versus get_integration_runtime_artifacts or other search tools, nor does it mention any exclusions or prerequisites.

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

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

The readOnlyHint annotation already covers the read-only nature. The description adds little behavioral context beyond 'direct entity lookup' – it doesn't explain what happens on no match, multiple matches, or any error behavior. Given the annotation, this is acceptable but not enhanced.

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 fluff. It immediately states the purpose and the key qualifier, making it easy to scan.

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

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

For a tool with 3 parameters and no output schema, the description is incomplete. It fails to cover the 'name' parameter, doesn't describe return format or pagination, and doesn't explain behavior when no results are found. This leaves an agent guessing on critical aspects.

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 mentions ID and version but omits the 'name' parameter entirely, leaving that parameter's role unexplained. It does not clarify the meaning of 'version' or how parameters interact.

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

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

The description clearly states a specific verb (search) and resource (message mappings), and specifies that it's a direct entity lookup by ID and version. This differentiates it from generic search tools, though it doesn't mention the name parameter, which slightly reduces completeness.

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

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

The phrase 'direct entity lookup' implies use when you have an ID and version, but it doesn't explicitly state when to use this over alternatives like get_message_mappings or other search tools. No exclusions or alternate conditions 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?

Annotations already declare readOnlyHint=true, and the description does not contradict that. The description adds some behavior context by clarifying the lookup is direct/entity-based, but it does not disclose other behaviors such as result limits, error conditions, or the role of the optional name parameter.

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 action and resource, and contains no filler. The parenthetical 'direct entity lookup' adds meaningful clarification without bloating the definition.

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

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

For a simple read-only lookup, the description is close to adequate, especially with the readOnlyHint annotation. However, the silent treatment of the name parameter and the lack of explicit differentiation from get_script_collections leave meaningful gaps for an agent deciding between 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 description coverage is 0%, so the description must compensate. It names id and version but omits name, and it does not explain whether parameters are combinable, optional, or required in any particular way. This leaves the agent guessing about how to construct a valid lookup.

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

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

Description states a clear action ('Search script collections') and a specific scope ('by ID and version (direct entity lookup)'). It conveys that this is an exact lookup rather than a broad search, though it does not explicitly differentiate itself from get_script_collections.

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

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

The phrase 'direct entity lookup' implies this is appropriate when the caller already knows the ID and/or version. However, it does not explicitly say when not to use this tool, nor does it name alternatives like get_script_collections or other search 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?

readOnlyHint=true is already in annotations, so the safety profile is covered. The description does add a useful behavioral qualifier — 'direct entity lookup by ID and version' — indicating a point lookup rather than an unfiltered scan. But it says nothing about behavior when all parameters are omitted (all three are optional), authentication needs, or result shape, so the added context beyond annotations is thin.

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 zero filler — verb, resource, and qualifier appear immediately. Every word carries meaning; the brevity problem is one of omission (name parameter), not of wasted phrasing.

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

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

For a search tool with three undocumented optional parameters and no output schema, one sentence is not enough. An agent cannot tell what an empty-parameter call returns, whether results are exact matches, whether pagination exists, or how get_value_mappings differs in behavior. The description is adequate only if the agent already knows the tool.

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

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

Schema description coverage is 0%, so the description bears the full burden of explaining id, name, and version. It covers id and version but omits the name parameter entirely, and it does not clarify whether matching is exact or partial or what happens when multiple/all parameters are absent. Compensation is only partial.

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

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

The description names a specific verb ('search'), a resource ('value mappings'), and a qualifier ('direct entity lookup'), which distinguishes it from the broader get_* and search_* siblings in the list. However, it never explicitly contrasts itself with the adjacent get_value_mappings or search_message_mappings, leaving some differentiation to inference.

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

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

No when-to-use guidance is offered. The parenthetical 'direct entity lookup' weakly implies that this tool is for point lookups, but the description never names get_value_mappings or search_message_mappings as alternatives nor states the condition that would select one over another. An agent has to guess when this tool fits.

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

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

The annotations already flag destructiveHint=true, and the description adds value by clarifying the nature of the destructiveness: it removes the artifact from runtime rather than deleting the artifact definition itself. This contextualizes the destructive action and correctly aligns with the annotation, with no contradiction.

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 13-word sentence that front-loads the action, uses a parenthetical to clarify semantics, and states the required input. Every word earns its place; there is no repetition of the title 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 one-parameter tool with a destructive annotation and no output schema, the description covers the essential facts: what the action does, the destructive nature, and what identifier to pass. The only notable omissions are how to discover the runtime ID (e.g., via get_integration_runtime_artifacts) and that deployment can be reversed with the deploy sibling, which are minor given the tool's simplicity.

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

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

Schema description coverage is 0%, so the description must compensate for the bare 'id' string parameter. It does add meaning by specifying that the ID is the 'runtime ID' rather than a package or flow ID, but it does not explain what a runtime ID looks like or how to obtain one, leaving partial ambiguity for an agent.

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 pairs a specific verb ('Undeploy'/'remove from runtime') with a specific resource ('integration artifact') and states the key identifying dimension ('by its runtime ID'). This clearly distinguishes it from sibling tools: deploy_integration_artifact is the inverse, upload/download handle file transfer, and get/search tools handle discovery. The parenthetical 'remove from runtime' further disambiguates it from permanent deletion.

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

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

Usage is only implied: the verb 'undeploy' signals this is the tool to remove an artifact from runtime, and mentioning 'runtime ID' hints that a prior discovery call is needed. However, there is no explicit guidance about when not to use it or mention of alternatives like deploy_integration_artifact for reversing the action, so the agent must infer the tool-selection logic.

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 destructiveHint=true already signalling that this is a write with destructive potential, the description adds useful behavioral context: it updates an externalized parameter and requires edit mode. It does not mention versioning or failure behavior, but it goes beyond the annotation.

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

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

Two tight sentences, front-loaded with the action and reserved for the one prerequisite that matters. Every word earns its place.

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

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

For a mutating tool with no output schema and no parameter descriptions, the description gives the critical edit-mode constraint but leaves version semantics and result behavior to inference. This is 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?

Schema descriptions are absent, so the description must carry parameter meaning. It only clarifies that parameter_key/parameter_value represent an externalized setting; id and especially optional version (which likely controls concurrency) are not explained. This is insufficient compensation for 0% 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 names a specific verb ('Update'), a precise object ('externalized parameter value'), and a target scope ('design-time artifact'), which clearly differentiates it from read-focused siblings and other artifact mutations.

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 states the key precondition for safe use: the artifact must be in edit mode (not read-only), and frames the tool as applying only to design-time artifacts. It does not name an explicit alternative tool or a when-not-to-use case, stopping short of a 5.

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

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

The destructiveHint annotation already signals mutating behavior, and the description adds meaningful detail by explicitly stating that 'update' replaces an existing artifact. It also clarifies the local zip file source, which helps the agent understand the operation's behavior beyond the annotation alone.

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

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

The description is two sentences with no filler. It front-loads the core action and immediately provides mode-specific behavior, making every sentence earn 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 six parameters, five of which are required, no output schema, and no parameter-level descriptions, the description is too thin to fully guide invocation. Key details such as what 'id' represents, how it should be supplied for create vs update, and the meaning of 'name' and 'version' are missing.

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

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

With 0% schema description coverage, the description must compensate, but it only clarifies 'mode' and 'file_path' (a local zip file). The roles of 'id', 'name', 'package_id', and 'version' are left unexplained, especially important for required parameters in create vs update scenarios.

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

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

The description explicitly states the action ('Create or update') and the resource ('integration design-time artifact'), with a clear source ('local zip file'). It distinguishes itself from siblings like download_integration_artifact and deploy_integration_artifact by focusing on design-time artifact creation/update.

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 guidance on mode selection: use 'create' for a new artifact and 'update' to replace an existing one. It does not explicitly mention when not to use the tool versus alternatives, but the mode-based usage context is clear and actionable.

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