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

With no annotations provided, the description carries the full burden of disclosing behavior. The verb 'Get' conveys a read-only intent, and 'from AEM instances' indicates the data source. However, it does not describe response behavior, how failures surface, or whether both bundleId and symbolicName are supported per call.

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

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

The description is one sentence and the key action is front-loaded. There is no filler or repeated schema information. It could include a bit more operational context, but as a concise summary it is effective.

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 optional parameters, two ways to identify a bundle, and two ways to target AEM instances, yet the description only says 'Get detailed information about OSGi bundles from AEM instances'. It does not state that a bundle identifier is expected, how instances vs aliases are resolved, or what the returned details include. With no output schema and no annotations, this is insufficiently complete for reliable invocation.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters. The description adds no additional meaning about how parameters relate, such as whether bundleId and symbolicName are alternatives or whether aliases and instances target the same concept. This is adequate but not value-adding beyond the schema.

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

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

The description states a clear verb and resource: obtaining detailed information about OSGi bundles from AEM instances. It is distinguishable from sibling actions like aem_bundle_start or aem_bundle_stop, and the word 'details' separates it from aem_bundle_list. It could be more specific about identifying a single bundle, but the core purpose is clear.

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

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

The description provides no explicit guidance on when to use this tool versus alternatives. There is no mention of prerequisites, such as needing a bundleId or symbolicName, nor any statement that this tool is for inspecting a single bundle rather than listing all bundles. Usage must be inferred entirely from the tool name and generic wording.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'List OSGi bundles' and does not mention that the tool can query multiple instances, supports pagination via limit/offset, is read-only, or what the response format looks like. The agent has no information about side effects, prerequisites, or output behavior.

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

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

The description is a single, tight sentence with no redundancy: 'List OSGi bundles from AEM instances'. It is front-loaded with the action and resource. It earns its place but could have added a bit more useful context (e.g., multi-instance or filtering) without becoming verbose, so it is not a perfect 5.

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

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

This tool has six parameters, no annotations, and no output schema. The description is too minimal to tell the agent what the response will look like or how aliases/instances are used, while the complex parameter set suggests a richer explanation is needed. The description leaves important context about multiple instances, filtering, and pagination entirely unstated.

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

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

Schema description coverage is 100%, so the baseline is 3 even though the tool description adds no parameter-specific meaning. Each parameter like aliases, instances, nameFilter, and stateFilter already has a reasonable schema description. The description itself does not enrich the parameters, but the schema adequately covers them.

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

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

The description states a specific verb ('List'), resource ('OSGi bundles'), and scope ('from AEM instances'). This clearly distinguishes it from sibling mutation tools like aem_bundle_start/stop and from other resource lists like aem_component_list and aem_configuration_list. The word 'list' also separates it from aem_bundle_details, which implies a single-bundle focus.

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

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

The description implies usage: when you want to enumerate OSGi bundles, use this tool. However, it provides no explicit guidance about when to prefer it over alternatives, such as aem_bundle_details for a specific bundle or aem_logs_search for diagnostics. There are no stated exclusions or alternative routing, so usage context is only inferable.

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

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

Annotations are absent, so the description must disclose behavior on its own. It does not explain whether refresh mutates bundle state, whether it is safe, whether credentials are required, or what the operational effect is compared to restart. The term 'Refresh' remains ambiguous in lifecycle terms.

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 short, front-loaded sentence with no filler. It is efficient, though extremely terse and lacking any supporting 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?

With no annotations and no output schema, the description leaves critical details unresolved: which parameters are needed, what happens after refresh, what the return value is, and how this differs from restart. An agent would struggle to invoke it correctly with confidence.

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

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

The input schema already documents all four parameters with descriptions, giving 100% coverage. The description adds no extra meaning about how to choose between bundleId and symbolicName, or between aliases and instances, but high schema coverage keeps this at baseline.

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

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

Description states a specific action ('Refresh') and resource ('OSGi bundles on AEM instances'), making the broad purpose clear. However, it does not distinguish this from the sibling aem_bundle_restart, and 'refresh' vs 'restart' could overlap semantically.

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 any of the bundle sibling tools such as restart, stop, start, or uninstall. There are no usage conditions, exclusions, or alternative recommendations despite many closely related tools.

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

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

With no annotations, the description carries the full burden of disclosing behavior. It says only that bundles are restarted and does not mention side effects such as service disruption, authentication/credential requirements, whether the operation waits for completion, or what response to expect. The verb 'restart' implies a mutating lifecycle operation but provides little beyond that.

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 concise sentence with the action front-loaded and no filler. It is slightly too sparse to earn a 5 because it omits contextual guidance that would make the entry more helpful, but as a concise statement 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?

For a mutating 4-parameter tool with no annotations and no output schema, the description is not complete. An agent cannot tell whether aliases and instances are alternatives, how bundleId relates to symbolicName, what happens on multiple instances, or what the return behavior is. The schema covers parameter names but not the operational context.

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

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

Schema coverage is 100%, so all four parameters (aliases, bundleId, instances, symbolicName) are documented at the schema level. The description itself adds no parameter meaning, and per baseline a high-coverage schema earns a 3 even without description-level parameter details.

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

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

The description uses a specific verb ('Restart') and resource ('OSGi bundles on AEM instances'), clearly identifying the core operation. It is distinguishable from sibling bundle operations because 'restart' is a distinct lifecycle action vs start/stop/refresh, though it does not explicitly differentiate itself or clarify whether it applies to selected bundles or all bundles.

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 for when to use this tool over aem_bundle_start, aem_bundle_stop, or aem_bundle_refresh, and there are no prerequisites or exclusions. Usage is only weakly implied by the verb 'restart'.

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 available, the description is the only source of behavioral information, but it only states the action 'Start' without disclosing side effects, idempotency, failure behavior, permission requirements, or what happens if the bundle is already running. It is not misleading, but it is very minimal.

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

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

The description is a single concise sentence with no filler or redundant wording. It is front-loaded and easy to scan, though it could benefit from one more sentence giving usage or behavioral context without becoming bloated.

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

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

For a mutation tool with four parameters and no annotations or output schema, the description is too thin. It fails to explain how instances are specified (aliases vs full instance objects), how the bundle is identified, what state the operation expects, or what the result or return value will be. This is insufficient for an agent to confidently invoke 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?

Schema description coverage is 100%, so the parameter meanings are fully documented in the input schema. The description adds no additional insight into how the parameters relate to the operation, such as the distinction between aliases and instances or between bundleId and symbolicName, so it stays at the baseline.

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

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

The description states a specific action ('Start') on a clear resource ('OSGi bundles') and the target environment ('AEM instances'). It is unambiguous about the primary operation, though it does not explicitly distinguish itself from sibling tools like aem_bundle_stop or aem_bundle_restart.

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 alternatives such as stop, restart, refresh, or uninstall. There is also no mention of prerequisites, such as whether the bundle must already be installed or stopped, or how to choose between bundleId and symbolicName.

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

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

With no annotations, the description carries the full behavioral burden, but it only restates the action. It does not disclose the operational impact of stopping a bundle, whether the action is reversible, what happens to dependent services, authentication requirements, or any side effects. Like the 'update_drive' calibration case, this mutation-style tool needs more behavioral context.

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

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

The description is a single, front-loaded sentence with no filler or repetition of the tool name beyond what is necessary. It is concise and readable, though it sacrifices operational detail that other dimensions penalize.

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 parameters, zero required fields, no output schema, and no annotations, yet the description provides no guidance on parameter combinations or invocation conditions. An agent cannot confidently determine whether bundleId, symbolicName, aliases, or instances need to be supplied together. This is insufficient for correct invocation.

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

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

Schema description coverage is 100%, so the input schema already documents all four parameters. The description adds no additional parameter-level meaning, such as how bundleId relates to symbolicName or how aliases relate to instances, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Stop') and resource ('OSGi bundles on AEM instances'), making the tool's core action unmistakable. The action also differentiates it clearly from its lifecycle siblings such as start, restart, refresh, uninstall, list, and details.

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

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

There is no guidance about when to use stop versus the closely related bundle lifecycle tools (restart, start, uninstall, refresh). No contextual triggers, exclusions, or alternatives are mentioned, so an agent must infer the right choice 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?

No annotations are present, so the description carries the full burden of behavioral disclosure. It identifies the action as 'Uninstall,' implying a destructive operation, but does not disclose side effects, reversibility, required permissions, or the effect on other bundles.

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 no fluff and puts the action and resource up front. It is concise, though slightly under-specified; the brevity is a positive structural trait even if behavioral details are missing.

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 destructive tool with no annotations and no output schema, the description lacks important context: it does not clarify how an agent should identify the target (bundleId vs symbolicName), how instances are selected (aliases vs instances), or what a successful uninstall returns.

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

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

The schema already provides descriptions for all four parameters (100% coverage), so the baseline is 3. The description adds no extra meaning about the parameters, such as how aliases and instances relate or whether bundleId and symbolicName are alternatives.

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 ('Uninstall') and a specific resource ('OSGi bundles on AEM instances'), making the tool's action unmistakable. It also stands apart from sibling tools such as aem_bundle_start, aem_bundle_stop, and aem_bundle_refresh because the operation is clearly uninstallation, not lifecycle state change.

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

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

The description states what the tool does but not when it should be chosen over alternatives. It never mentions, for example, that aem_bundle_stop or aem_bundle_restart should be preferred for temporary changes, so an agent receives no decision guidance.

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

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

With no annotations, the description carries the full behavioral burden, but it only says 'Get detailed information'. It does not disclose authentication requirements, failure behavior, or return contents, and the read-only nature is only implicit.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the core purpose.

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

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

For a tool with one required parameter and full schema coverage, the description is minimally viable. However, with no output schema and no annotations, it omits what 'detailed information' includes and how instances/aliases affect the call.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds emphasis on componentName by saying 'by name', but it does not clarify the role of aliases or instances beyond their 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 identifies the action ('Get') and the resource ('detailed information about a specific OSGi component'), and the phrase 'by name' distinguishes this from listing operations. It does not explicitly differentiate from sibling tools, but the specificity is 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?

The description implies this tool is for retrieving details about one known component, but it does not state when to prefer it over aem_component_list or other component tools. No exclusions or alternative routing are provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation is a disable action but does not disclose side effects, persistence, reversibility, permissions needed, or what happens if the component is already disabled or not found.

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

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

The description is a single concise sentence with no filler or repetition. The core action, target, and selection method are 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?

With no annotations and no output schema, the description leaves important context unstated, such as how to choose between aliases and instances, whether either must be provided, and what the expected result looks like. The minimal description is insufficient for fully safe invocation despite the simple surface.

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

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

Schema description coverage is 100%, so the schema already documents every parameter. The description adds no additional meaning beyond the parameter names, but this is acceptable because the schema handles the baseline semantic load.

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 ('Disable') and resource ('OSGi components on AEM instances') and specifies the key selection criterion ('by component name'). This clearly differentiates it from siblings like aem_component_enable and aem_component_list.

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, no prerequisites, and no mention of whether instances/aliases are required or how targeting works. The only implied usage is from the tool name and the verb 'Disable'.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals that the tool mutates component state by enabling it, but it does not mention side effects, reversibility, permissions, idempotency, or what happens if the component is already enabled.

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

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

The description is a single, focused sentence with no filler. It front-loads the primary verb and resource, making the tool's core purpose immediately clear.

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 too spare for a state-changing tool with no annotations and no output schema. It omits how to choose between aliases and instances, what a successful enable looks like, and any operational caveats, leaving an agent to infer critical invocation details.

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

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

Schema description coverage is 100%, so the schema already documents each parameter at a basic level. The description adds minimal semantic value beyond indicating that componentName is the lookup key, but it does not clarify the relationship or selection logic between aliases and instances.

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

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

The description states a specific action ('Enable') on a specific resource ('OSGi components') and the key input ('by component name'). It clearly differentiates this from sibling tools like aem_component_disable and aem_component_list.

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 alternatives, such as aem_component_disable or aem_component_details. The description implies the use case through the verb 'Enable,' but it does not state exclusions, prerequisites, or conditions for choosing between target options.

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

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

With no annotations, the description carries the burden of behavioral disclosure. 'List' implies a read-only operation, but the description does not explain whether credentials are required, what happens when no aliases or instances are provided, or any output characteristics. It is minimally transparent but lacks meaningful behavioral depth.

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

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

A single sentence that is front-loaded with the core action and resource, followed by a brief mention of the filters. Every word earns its place; no filler or redundancy.

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

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

For a tool with six parameters and no output schema, the description is too thin. It does not explain the relationship between aliases and instances, pagination behavior beyond the schema defaults, or what constitutes a valid invocation. An agent could select the tool but would lack important operational context.

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

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

The input schema already provides descriptions for all parameters (100% coverage). The description only restates the existence of state and name filtering without adding new meaning, so it meets the baseline but does not enrich parameter understanding.

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

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

States a specific verb ('List'), a clear resource ('OSGi components'), the target ('AEM instances'), and optional filters ('state and name filtering'). This clearly distinguishes it from siblings like aem_component_details or aem_component_enable.

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

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

The description implies this is the list/read operation for OSGi components, but it gives no explicit guidance on when to prefer this over aem_component_details, nor does it mention exclusions or prerequisites such as needing aliases or instances. Usage context is reasonably clear but leaves judgment to the agent.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the mutation implied by the tool name and does not reveal what happens if the PID already exists, whether the operation is destructive, or how authentication is handled through the instances array.

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

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

The description is a single, front-loaded sentence with no wasted words. It is concise and easy to parse, though it does not provide enough depth for a tool with six parameters and nested objects.

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 annotations, no output schema, and a complex input schema containing nested objects, the description is too sparse. It does not explain what properties should look like, the role of aliases and instances, or what a successful creation returns, leaving significant gaps for correct invocation.

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

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

Schema description coverage is 100%, so all six parameters already have minimal descriptions such as 'Configuration PID' and 'Factory PID for factory configurations'. The description adds no additional meaning beyond what is present in the schema, warranting the baseline score of 3.

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

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

The description states a specific verb and resource: 'Create a new OSGi configuration'. This clearly differentiates it from sibling tools such as aem_configuration_list, get, update, delete, and unbind.

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 create versus update, or when factoryPid should be supplied. The description does not mention any prerequisites or alternative tools, leaving the agent to infer the appropriate 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?

There are no annotations, so the description must carry the full burden of behavioral disclosure. 'Delete' does signal mutation/destructiveness, but the description does not mention permanence, required permissions, effects on runtimes or instances, or whether the deletion targets all specified instances/aliases.

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 short declarative sentence with no filler or redundancy. It is front-loaded with the essential action and resource, which is ideal for conciseness even if other dimensions lack depth.

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 annotations, no output schema, and a one-sentence description, the tool is under-specified for an agent deciding whether deletion is appropriate or what it will affect. The presence of optional aliases and instances fields raises questions about targeting that the description does not address.

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

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

Schema description coverage is 100%, with each parameter having some description in the schema. The tool description itself adds no parameter-level meaning, so the baseline of 3 applies: the schema does the heavy lifting and the description does not need to compensate.

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 ('Delete') and a clear resource ('an OSGi configuration'), so an agent can tell this is a destructive configuration operation. It differentiates from list/get/create/update, though it doesn't explicitly contrast with aem_configuration_unbind, making 5 slightly too strong.

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 instead of related ones such as aem_configuration_unbind, aem_configuration_update, or aem_configuration_create. The description only states what it does, not the conditions or prerequisites for invoking 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get' suggests read-only behavior, but the description does not state whether it modifies anything, what permissions are required, what happens if the PID is not found, or what the response contains.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to identifying the operation, and the structure is appropriately minimal for such a simple tool.

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

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

There is no output schema and no annotations, but the description does not explain return values, failure modes, or behavior when instances/aliases are supplied. For an agent to use this tool confidently, more context is needed beyond the one-line summary.

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

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

Schema description coverage is 100%, so the input schema already documents pid, aliases, and instances adequately. The description adds no parameter-level meaning beyond what the schema provides, so the baseline score of 3 applies.

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

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

The description clearly states a get operation targeting a specific OSGi configuration, which is unambiguous and distinct from list/create/update operations by virtue of the word 'specific'. However, it does not explicitly name or contrast a sibling tool, so it stops short of the strongest 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?

There is no guidance on when to use this tool versus aem_configuration_list or when to prefer another tool. The description implies a single-config lookup but provides no conditions, exclusions, or alternatives.

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

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

No annotations are provided, so the description carries the full responsibility for behavioral disclosure. It only states the operation and resource, without saying whether output is a summary or detailed configs, whether pagination via offset/limit is applied, whether authentication is required, or any side effects. 'List' implies read-only, but that is not explicitly guaranteed.

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 starts with the action verb and names the target resource. There is no redundant wording. It could have included more context, but it is structurally clean and front-loaded.

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

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

The schema fully documents the five parameters, so an agent can construct a syntactically valid call. However, with no output schema and no annotations, the description does not explain what the returned list contains, how pagination behaves, or how multiple instances are handled. These are clear gaps for running the tool correctly and understanding the result.

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

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

Schema coverage is 100%, meaning every parameter already has a description such as limit, offset, aliases, instances, and pidFilter. The description itself adds no new parameter-level meaning, but since the schema fully documents all parameters, the baseline of 3 is appropriate.

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

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

The description uses a specific action verb ('List') and a clear resource ('OSGi configurations') with a source ('AEM instances'). It is immediately distinguishable from sibling configuration tools like get, create, update, delete, and unbind, as well as from bundle/component list 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?

There is no guidance about when to choose this list tool over `aem_configuration_get` for a single configuration, nor about relationships to configuration create/update/delete tools. The intended use is implied by the tool name, but the description does not actively route the agent to the correct alternative.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action but not the consequences, such as whether the unbind is reversible, whether it triggers a bundle restart, whether it affects existing configuration data, or what permissions are needed. This is a meaningful gap for a mutating operation.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It is appropriately concise, though slightly terse given the complexity of the operation and the number of 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?

Despite full schema coverage, the description lacks important context about the unbinding behavior, its effect on the bundle or configuration, and the role of optional parameters like bundleLocation, aliases, and instances. Without annotations or an output schema, the description alone is insufficient for an agent to confidently invoke the tool in complex scenarios.

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

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

Schema description coverage is 100%, and the description adds no additional meaning beyond what the schema already provides. The baseline of 3 applies because the parameter documentation is complete in the schema, but the description doesn't enrich parameter understanding.

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

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

The description uses a specific verb ('Unbind') and resource ('OSGi configuration from a bundle'), clearly identifying the operation. It distinguishes itself from sibling configuration operations like delete or update, though it does not explicitly name them or highlight the distinction.

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

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

No guidance is given about when to use this tool versus alternatives such as aem_configuration_delete or aem_configuration_update. The description only states the operation itself, leaving the agent to infer the appropriate context from the tool name and sibling list.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only conveys the mutation itself. It fails to state whether the provided 'properties' replace or merge with existing values, whether credentials on target instances are required, how factory configurations behave, or what side effects the update triggers.

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

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

A single front-loaded sentence with the verb first and zero filler words. It is appropriately compact for the message it carries, though it could earn a 5 by folding in the missing behavioral 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?

The tool has 6 parameters, nested credential objects, two targeting mechanisms, and no annotations or output schema, yet the description conveys only the bare operation. Critical details — merge vs replace behavior, factory configuration handling, targeting mechanics, and authentication expectations — are absent.

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

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

Schema description coverage is 100%, so each of the 6 parameters has at least a minimal schema description, meeting the baseline of 3. However, the tool description itself adds no parameter-level meaning, and the schema's terse labels leave key semantics unexplained, such as what the 'properties' object should contain or how 'aliases' vs 'instances' targeting works.

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') and a specific resource ('existing OSGi configuration'), which is clearly scoped to AEM's OSGi config system. The qualifier 'existing' distinguishes it from sibling aem_configuration_create and aem_configuration_delete, though it does not explicitly name them.

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

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

No guidance is given on when to use this tool versus alternatives like create, delete, get, or unbind. The word 'existing' implies the configuration must already be present, but there is no explicit context, precondition, or exclusion information.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does not mention that executing Groovy scripts can have arbitrary side effects, destructive potential, or require elevated permissions. The description frames it as safe maintenance/automation without warning about the power and risk of arbitrary code execution.

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, economical sentence with no fluff. It states the verb, target, mechanism, and general use case efficiently, though it does not use any structural aids like bullets or examples.

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 powerful arbitrary-code-execution tool with no annotations, no output schema, and a mutually-exclusive parameter pair (script vs scriptPath). The description does not explain return values, behavior when both parameters are supplied, timeout semantics, or safety/authorization requirements. It is too sparse for correct and safe invocation.

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

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

Schema description coverage is 100%, so the schema already documents all parameters. The description adds no extra parameter-level meaning, such as what happens when both script and scriptPath are provided, which is a notable gap. Baseline 3 is appropriate because the schema handles the basics.

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

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

The description uses a specific verb ('Execute') with a clear resource ('Groovy scripts on AEM instances via Groovy Console') and a stated purpose ('maintenance and automation tasks'). It is clearly distinct from sibling tools, which target bundles, components, configurations, logs, and health checks.

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 some context by mentioning 'maintenance and automation tasks,' which implies use when generic scripted operations are needed. However, it does not explicitly state when to prefer this tool over siblings, when not to use it, or any prerequisites such as Groovy Console availability.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states what metrics are checked but does not say whether the operation is read-only, whether it modifies AEM state, what authentication requirements exist beyond credentials in the instance object, or what failure modes look like. This is a significant gap for a tool that could have side effects or require elevated permissions.

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 redundancy. The main purpose is front-loaded, the metric scope is compactly listed, and the critical parameter constraint is placed in the second sentence. Every word earns its place.

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

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

The description covers what is checked and the input requirement, but lacks information about the output/return format, whether the operation is safe/read-only, and any prerequisites. With no output schema and no annotations, these details fall on the description. It is adequate for a health-check tool but leaves the agent guessing about the result shape and side effects.

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

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

Schema coverage is 100% for both parameters, so the baseline is 3. The description adds value by stating the relationship between the parameters ('Either aliases or instances must be provided'), which clarifies that at least one is required and they are not both mandatory. It does not repeat schema details, and the 'overrides aliases' semantics in the schema are preserved implicitly.

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 ('Performs comprehensive health checks') and the resource ('AEM instances'), and lists the specific metric categories (memory, threads, bundles, requests, repository). This makes it easy to distinguish from sibling tools like aem_bundle_list or aem_logs_search, which target individual subsystems.

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 about when to choose this tool over siblings or when it would be inappropriate. The only usage hint is 'Either aliases or instances must be provided,' which is a parameter requirement, not guidance for selecting between tools. The agent must infer that a health check is the broad diagnostic entry point, but this is not stated explicitly.

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 available, the description carries the behavioral disclosure burden. It does disclose pagination and regex-based searching, and 'Search' implies a read operation, but it does not mention authentication needs, result format, limits, or multi-instance behavior.

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

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

The description is a single, efficient sentence with no fluff or repetition. It front-loads the core purpose. It could be slightly richer, but it is appropriately concise.

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 5-parameter tool with no output schema and no annotations, the description is under-specified. It doesn't explain what a page of results looks like, how pagination is navigated, or how multiple instances/credentials factor in. An agent would need external knowledge to fully invoke and interpret 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?

Schema description coverage is 100%, so every parameter already has a description. The tool description adds little beyond the schema, only summarizing that regex and pagination are involved, which is the appropriate baseline.

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

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

The description names a specific verb ('Search'), resource ('AEM logs'), and key behaviors (regex patterns, log types, pagination). It is clearly distinct from all sibling tools, which cover bundles, components, configurations, health checks, and Groovy execution rather than log search.

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 usage context: an agent should use this when searching AEM logs with regex across log types and paging results. It does not explicitly state when not to use it or name alternatives, but no sibling tool competes for this purpose.

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