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 reveals that the tool mutates tags by adding or updating them, but it does not state whether existing tags are preserved, whether values are overwritten, what permissions are required, or what response/errors to expect. This is a meaningful gap for a mutating tool.

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

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

The description is two short sentences with no wasted words. The action is front-loaded, and the clarification about tag structure 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 schema fully documents parameters, but the description omits the crucial distinction from replace_tags_on_entity: does adding/updating tags preserve unrelated existing tags? It also provides no expectation about return values. Adequate for a basic call, but not fully complete for agent decision-making among sibling tag 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?

The input schema already describes all three parameters with 100% coverage, including the tags array as key-value pairs. The description's 'Tags are key-value pairs' adds little beyond the schema, 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 and resource: it adds or updates tags on a New Relic entity. It clearly communicates the core action, but it does not distinguish itself from the sibling replace_tags_on_entity, which could also be described as updating tags.

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

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

No explicit guidance is given about when to use this tool versus replace_tags_on_entity, delete_tags_from_entity, or get_entity_tags. The intended use is implied by the name and sentence, but the agent is left to infer when this upsert-style tag operation is preferable.

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

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

With no annotations provided, the description carries the full burden and does so thoroughly. It discloses that raw_configuration is sent as rawConfiguration to NerdGraph, takes precedence over typed configuration, uses accountIds as an array, is auto-populated from widget_query, and includes caveats about NR aggregation suffixes and unsupported logarithmic scale.

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

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

The description is long but front-loaded with the core purpose and then organized into practical, labeled examples. Some redundancy exists between the standalone JSON examples and the raw_configuration schema description, but each section serves a clear instructional purpose for a complex parameter.

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

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

Given the tool's complexity, nested raw_configuration object, and absence of both annotations and output schema, the description is highly complete. It covers required inputs, advanced configuration options, key New Relic-specific behaviors, and an explicit unsupported feature, leaving an agent well-equipped to 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?

Although schema coverage is 100%, the description goes substantially beyond the schema by providing concrete JSON examples, clarifying the accountIds array vs accountId scalar, showing auto-population behavior, and demonstrating combinations like fixed y-axis with hidden legend. This is far more than the baseline schema 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 action: adding a widget to an existing dashboard, requiring a dashboard GUID and widget configuration. This clearly distinguishes it from sibling tools like create_dashboard or update_widget, since the target is an existing dashboard.

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

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

The description implies usage context by saying 'existing dashboard' and requiring dashboard_guid, but it does not explicitly contrast this tool with alternatives such as create_dashboard, update_widget, or get_dashboard_widgets. An agent can infer when to use it, but the guidance is not explicit.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior, but it only states that a policy is created. It does not mention potential side effects, required permissions, duplicate-name behavior, whether the creation is immediately effective, or whether additional configuration steps are needed after creation.

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 words. It is appropriately concise, though it is so terse that it contributes minimal information beyond the schema and tool name.

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

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

For a simple create operation with only two parameters and full schema coverage, the description plus schema is minimally viable. However, the absence of an output schema and any behavioral context means the agent is left guessing about return values, uniqueness rules, and the relationship between alert policies and alert conditions.

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 both parameters are already documented in the input schema. The description adds no additional meaning beyond what the schema provides, which aligns with the baseline 3 for complete schema coverage.

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

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

The description clearly identifies the action (Create) and the resource (alert policy), making it easy to distinguish from sibling tools that operate on dashboards, NRQL conditions, or workflows. However, it is essentially a restatement of the tool name and adds no detail about what an alert policy actually contains or how it differs from related alert-condition 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 on when to use create_alert_policy versus alternatives such as create_nrql_condition or create_workflow. The description does not mention prerequisites, relationships to other resources, or any exclusions, leaving the agent 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It signals a mutating operation but does not explain what is persisted, whether creation is idempotent, what permissions are needed, or what response to expect. For a write tool, this is a meaningful transparency gap.

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

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

The description is one sentence with no filler. It is front-loaded with the action and resource, 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 simple two-parameter tool with full schema coverage, this description is adequate. However, there is no output schema, and the description does not mention the return value or how the created dashboard can be referenced later. It is minimal but has clear gaps.

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

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

The input schema already documents both parameters name and description at 100% coverage. The description adds no parameter-level detail 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 'Create a new New Relic dashboard' names a specific verb and resource. It clearly distinguishes this from sibling tools like get_dashboards, delete_dashboard, and add_widget_to_dashboard, which operate on dashboards in different ways.

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

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

The description implies the use case through the verb 'Create', but it does not explicitly say when to use this tool versus alternatives such as get_dashboards or search_all_dashboards. There are no exclusions or prerequisites stated, so usage guidance is only implied.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does state the key behavioral effect—that the tool creates a rule which suppresses alert notifications during scheduled windows—so an agent understands the outcome. However, it discloses no additional behavioral traits such as persistence, immutability, permission requirements, or response behavior, which would be valuable for a create/mutation operation without 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?

Four concise sentences, front-loaded with the primary purpose before moving into usage and detail. Every sentence contributes relevant information, though the condition-attribute list partially duplicates the schema. No filler or vague language.

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, nested objects, and no output schema, the description covers core purpose, conditions, and schedule, but is not fully complete. It omits the MONTHLY recurrence option (despite the schema supporting it), does not clarify that schedule is optional, and gives no indication of what the response/return value is. The schema fills some gaps, but the description alone leaves an agent with questions on edge cases.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates condition attributes already listed in the schema and adds a small amount of context for how conditions and schedule are used. It does not add significant new meaning beyond the schema and slightly misleads by listing only DAILY/WEEKLY while the schema includes MONTHLY.

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 ('Create'), a specific resource ('muting rule'), and its exact purpose ('suppress alert notifications during scheduled windows'). It also names the key matching dimensions (policies, condition names, entity attributes), which distinguishes it from sibling creation tools like create_alert_policy or create_notification_destination.

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

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

The description makes the use case explicit: use this when you need to suppress alert notifications during scheduled windows. It gives direct guidance on how to construct the rule ('Use conditions to match...', 'Use schedule for recurring windows'), and the roles of the create/list/delete muting rule siblings make the choice clear, though it does not explicitly name alternatives 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?

Since no annotations are provided, the description carries full behavioral disclosure burden. It only restates the core create action without explaining side effects, destination existence validation, idempotency, error behavior, or any requirements around the 'properties' field. It adds no behavioral context beyond what the tool name and schema already 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?

The description is a single sentence with no filler words, and the core action is front-loaded. It is maximally concise while still conveying the essential purpose. The absence of excess verbiage makes 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?

With no output schema and no annotations, the description is too thin to support correct invocation in all cases. It does not explain how the 'properties' object varies by channel type, whether the destination must pre-exist, or what the response will be. An agent would have to infer significant context from parameter names alone.

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 every parameter already having a meaningful description. The tool description adds no new parameter-level information; 'linked to a destination' merely echoes the destination_id schema description. With complete schema coverage, 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 states a specific verb ('Create'), a clear resource ('notification channel'), and a relationship ('linked to a destination'). This accurately distinguishes it from the sibling create_notification_destination, which creates the destination itself, and from list_notification_channels, which reads channels.

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 create_notification_destination or other notification tools. It does not mention prerequisites such as the need for an existing destination, nor does it describe the typical workflow ordering. The single sentence provides no conditions or alternatives.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states that a destination is created. It does not mention whether creation is idempotent, what validation occurs, what permissions are required, or what happens on duplicate names. The vague 'etc.' adds no behavioral detail.

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 purpose is front-loaded and the example types are useful contextual hints. It could be longer, but for what it communicates, the length is appropriate.

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

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

The tool has no output schema and no annotations, yet the description provides no information about return values, success behavior, prerequisites, or how this destination integrates with the notification system. For a create operation with a nested 'properties' object, more context is needed 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 100%, so the schema already documents all three parameters fully. The description adds little beyond restating that type can be email, webhook, Slack, etc., which is already captured by the enum. Baseline 3 is appropriate because the schema carries the semantic weight.

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 ('Create') and resource ('notification destination'), and enumerates example types (email, webhook, Slack), making the core purpose clear. It does not explicitly differentiate from the sibling 'create_notification_channel', but the distinct resource name keeps it from being ambiguous.

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 such as 'create_notification_channel' or 'create_workflow', nor any prerequisites or follow-up steps. The context in which a destination must be created before a channel or workflow can reference it is left entirely implicit.

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 states the creation action and does not reveal side effects, prerequisites like an existing policy_id, failure behavior, or whether the operation is irreversible. This is a state-changing operation with no supporting 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?

Single sentence, no filler, and the action is front-loaded. However, it is so sparse that it pushes the burden of context onto the schema and sibling names rather than the description itself.

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 9-parameter create operation with no output schema and no annotations, this description is not complete enough. It omits what a successful call returns, whether the created condition ID is needed for follow-up calls, and how it relates to update/delete sibling operations. An agent cannot fully understand the tool's role in a workflow.

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 parameters meaningfully. The description itself adds no parameter-level detail, but the baseline of 3 applies because the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Create a NRQL alert condition.' This clearly distinguishes it from siblings like update_nrql_condition and delete_nrql_condition. The action and target are unambiguous.

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

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

The description provides no when-to-use guidance, no exclusions, and no explicit pointer to alternatives such as update_nrql_condition or list_alert_conditions. An agent would have to infer usage context entirely from sibling tool names.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys only that this is a mutating 'Create' operation and does not disclose prerequisites (existing notification channels), side effects (e.g., a default filter named 'Filter-name' being applied), idempotency, or what happens if the referenced channels do not exist.

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

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

The description is a single front-loaded sentence with zero filler; the verb and resource appear immediately. It is efficient and scannable, though it is terse enough that it sacrifices useful detail for brevity.

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

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

For a five-parameter create operation with no output schema, the description is under-specified: it never mentions the filtering mechanism that is central to how the workflow selects alerts, nor prerequisites like needing channels beforehand. An agent cannot infer the core routing concept or what the operation returns from this description alone.

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 five parameters individually, meeting the high-coverage baseline of 3. The description adds no parameter-level meaning beyond the schema, and the nested filter_predicates structure is left entirely to 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 and resource ('Create a workflow') plus a purpose ('connect alert policies to notification channels'), which positions it clearly against siblings like create_alert_policy, create_notification_channel, and create_muting_rule. It is slightly imprecise, though: the schema shows routing is driven by filter_predicates/filter_name, and alert policies are not actually a parameter of this tool, so the description's implied mechanism is approximate rather than exact.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. Among siblings that include delete_workflow, list_workflows, and several other create_* tools, the description gives no hint about ordering (e.g., channels should exist first) or when this tool is the right choice versus creating a policy or channel.

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 disclosure burden. It reveals the operation is purely local ('without making an API call') and specifies what the output contains. It does not mention invalid-GUID error behavior, but that is a minor gap for a simple decode operation.

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

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

Two efficient sentences, front-loaded with the operation and output components, and the use-case sentence adds value with no 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 simple one-parameter utility with no output schema, the description fully covers what the tool does, what it returns, and why to use it. Nothing critical is missing for invocation or result interpretation.

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

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

The schema already documents the single guid parameter, so baseline is 3. The description adds meaningful context by noting the GUID is base64-encoded and what components are revealed, helping the agent form valid input and interpret the output.

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 ('Decode') and resource ('New Relic entity GUID'), and explicitly lists the revealed components (account ID, domain, entity type, domain ID), making the purpose unmistakable. This distinguishes it clearly from sibling tools like get_entity or entity_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 provides clear usage context: useful for understanding what an entity GUID refers to without making an API call. This implies when to use it instead of fetching full entity data, though it does not explicitly name alternatives or state exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys the basic operation but does not mention irreversibility, cascading effects on related resources, permissions required, or potential side effects—important for a destructive tool.

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

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

The description is one concise, front-loaded sentence with no filler. It is appropriately sized for a simple one-parameter delete 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?

For a single-parameter tool with full schema coverage, the description is mostly sufficient, but the absence of annotations and output schema leaves the destructive nature and any return behavior implicit rather than explicit.

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

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

The schema covers 100% of the single parameter with a clear description, so the baseline is 3. The tool description adds no additional parameter meaning beyond 'by ID,' but the schema already fully documents policy_id.

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'), a specific resource ('alert policy'), and a clear scope ('by ID'). It is unambiguously distinct from sibling tools like create_alert_policy, update_alert_policy, and list_alert_policies.

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, no prerequisites, and no exclusions. The description states what it does but not when it should be chosen or avoided.

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 alone must disclose behavioral traits. It only states 'Delete' without mentioning that deletion is irreversible, may require permissions, or could affect associated widgets. For a destructive tool, this is a significant transparency gap.

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

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

Single sentence with no filler; the action and identifier type are front-loaded. Every word earns its place for a one-parameter delete 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?

Although the schema fully covers the single parameter, the absence of annotations and output schema puts the burden on the description. It does not explain destructive consequences, permanence, or effects on dependent objects like widgets, so the agent lacks safety-relevant context needed for confident invocation.

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

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

Schema coverage is 100%: dashboard_guid is fully documented in the input schema and marked as required. The description merely repeats 'GUID' without adding format, source, or validation details, so it adds little beyond the schema.

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

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

Description uses a specific verb 'Delete' and a clear resource 'dashboard' with an identifier type 'GUID'. This unambiguously distinguishes the tool from sibling delete_* tools and from dashboard read/create 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 is implied by the verb and resource: it is the tool to call when removing a dashboard. However, there is no explicit when-to-use guidance, no mention of alternatives, and no prerequisites or side conditions such as dashboard existence or dependencies.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It communicates that the operation is destructive, but it does not state whether deletion is permanent, whether it is idempotent, what happens if the rule does not exist, or what authorization is required. These are meaningful gaps for a delete 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 sentence with no wasted words, and the core action ('Delete') is front-loaded. It is appropriately concise for a simple one-parameter tool.

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

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

The tool is simple, has a fully documented required parameter, and the destructive intent is stated. However, without annotations or an output schema, the description does not cover return behavior, error cases, or post-delete verification expectations, leaving the definition adequate but not fully complete.

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

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

Schema description coverage is 100% for the single rule_id parameter, and its schema description already states 'ID of the muting rule to delete'. The tool description adds minimal semantic value beyond the schema, so 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 verb ('Delete') and resource ('muting rule') with a clear scope ('by ID'). It clearly distinguishes itself from sibling tools like create_muting_rule and list_muting_rules without requiring schema inspection.

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, nor does it mention prerequisites such as needing to look up a rule_id first via list_muting_rules. Usage context is only implied by the verb 'Delete', so the agent receives no explicit decision support.

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

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

No annotations are provided, so the description carries the full burden. The word 'Delete' indicates destructive intent, but the description does not disclose that deletion is likely permanent, whether it affects associated channels/workflows, or what happens when the destination does not exist. For a destructive tool, 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?

One short, front-loaded sentence with no wasted words. It states the action and the key identifying constraint efficiently, matching the simplicity of the tool.

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

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

For a simple one-parameter delete operation, the description plus schema is mostly enough to invoke it. However, with no annotations and no output schema, an agent is left unaware of success/error behavior and the possible downstream impacts of deleting a notification destination, so completeness is only adequate.

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

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

The schema already fully documents the single parameter with 100% coverage. The description's 'by ID' merely reinforces destination_id rather than adding new meaning. This meets the baseline for schema-covered parameters but adds no extra semantic detail.

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 clearly identifies the resource ('notification destination') plus the identification mechanism ('by ID'). Among the many sibling tools, this uniquely and unambiguously matches its name and distinguishes it from create/list destination 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 is implied rather than explicit: the agent can infer that this tool is for deleting a known notification destination, and could use list_notification_destinations to find an ID. However, there is no explicit guidance about when not to use it or mention of 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 burden. It only states the core delete action and omits behavioral context such as irreversibility, required permissions, behavior when the condition does not exist, or side effects on related resources.

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 with the verb and object front-loaded. There is no filler, redundancy, or unnecessary information.

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

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

For a low-complexity tool with one required parameter and 100% schema coverage, the description provides enough information to invoke the tool correctly. The absence of an output schema and behavioral caveats is minor for such a simple delete operation.

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

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

The schema covers the single parameter condition_id completely, so the baseline is 3. The description's 'by ID' is consistent with the schema but does not add semantic detail beyond what the schema already provides.

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

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

The description states a specific verb ('Delete'), a specific resource ('NRQL alert condition'), and the method ('by ID'). It clearly distinguishes this tool from siblings like delete_alert_policy and aligns with create_nrql_condition/update_nrql_condition.

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 conveys when to use the tool: to delete a NRQL alert condition by its ID. It does not explicitly discuss alternatives or exclusions, but the resource is specific enough that usage context is clear.

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

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

With no annotations, the description carries the full burden. It does disclose a key behavioral trait: deleting a tag key also removes all its values. However, it does not mention whether the delete is permanent, what happens if a key does not exist, or any permission requirements.

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

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

A single, direct sentence that wastes no words. It front-loads the action and adds the crucial clarification about all values without extra fluff.

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

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

The tool is simple and the schema fully describes parameters, but the absence of annotations and output schema leaves no details about errors, response format, or side effects. Still, for a straightforward delete operation, the description plus schema is minimally 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 100%, so parameters guid, tag_keys, and account_id are already well-documented. The description adds little beyond the schema, only clarifying that tag_keys removal also deletes all values. This fits the baseline of 3 where the schema does the heavy lifting.

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

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

The description states a specific verb ('Delete') and resource ('tag keys ... from a New Relic entity'). The parenthetical '(and all their values)' clarifies the exact scope of deletion, distinguishing this tool from sibling delete_tag_values without needing to open 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?

The description implies when to use this tool: when you want to remove entire tag keys with all their values from an entity. However, it does not explicitly mention alternatives like delete_tag_values or add_tags_to_entity, nor does it state when not to use 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?

With no annotations, the description must carry the burden. It does disclose what is destroyed (the listed key-value pairs) and a key behavioral nuance (the key remains if other values remain). However, it does not mention account_id scoping, permissions, partial failure behavior, or response details, so it 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?

A single front-loaded sentence with no filler. The parenthetical packs crucial semantic nuance compactly, and every clause 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 three-parameter tool, the core call semantics are covered and the schema fills in parameter details. However, the lack of guidance about sibling alternatives and the absence of any annotation or response information leave gaps an agent must infer. It is adequate but not fully complete.

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

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

Schema description coverage is 100%, so the baseline of 3 applies. The description adds no extra syntax, format, or edge-case detail beyond what the schema already provides for guid, account_id, and tag_values.

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 starts with a precise verb and resource ('Delete specific tag key-value pairs from an entity') and the parenthetical clarifies the key-retention behavior, distinguishing it from deleting an entire tag key. This is specific and unambiguous, especially alongside siblings like delete_tags_from_entity.

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 parenthetical implies this tool is for selectively removing values while preserving the key, but it never explicitly tells the agent when to prefer this over delete_tags_from_entity, replace_tags_on_entity, or add_tags_to_entity. No alternatives or exclusions are named.

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 responsibility for behavioral transparency, but it only restates the delete action. It does not disclose whether deletion is permanent, whether it has side effects on other widgets or pages, whether permissions are required, or what happens to dependent 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 clear sentence with no filler. The verb and object are front-loaded, and every word contributes meaning.

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 two-parameter operation, but gaps remain: no mention of irreversibility, side effects, permissions, or the page-vs-dashboard GUID distinction. Without annotations or an output schema, a bit more context would make it safer for an autonomous agent.

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

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

Schema description coverage is 100%, so the parameters are already documented. The description adds no extra parameter details; the phrase 'from a dashboard' maps loosely to page_guid but does not clarify the relationship between dashboard pages and page_guid.

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 and object: delete a widget from a dashboard. It is not a tautology and is distinct enough from delete_dashboard because the target is a widget, not a dashboard. It does not explicitly differentiate itself from related siblings like update_widget or get_dashboard_widgets, which keeps it from 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?

There is no guidance about when to use this tool versus alternatives. It does not mention that deleting an entire dashboard should use delete_dashboard, or that modifying a widget should use update_widget. The correct usage context is left entirely to inference.

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

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

No annotations are provided, so the description must carry the burden of behavioral disclosure. It only says 'Delete a workflow by ID' and does not mention that delete_channels defaults to true, potentially deleting associated notification channels, nor does it mention irreversibility or permission needs.

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 wasted words. It is appropriately terse, though the brevity comes at the cost of missing important 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?

For a destructive operation with no output schema and no annotations, the description is incomplete. It omits the critical cascading behavior of delete_channels and any side-effect warnings, leaving the agent to discover these from the schema alone.

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

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

The input schema already provides 100% coverage, including descriptions for workflow_id and delete_channels. The description adds no parameter meaning beyond the tool name, but the schema is self-sufficient, so the baseline of 3 applies.

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

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

States a specific verb ('Delete') and resource ('workflow') with ID, which clearly identifies the operation and distinguishes it from sibling delete tools targeting other resources (e.g., delete_dashboard, delete_alert_policy).

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 relative to list_workflows or create_workflow, no prerequisites, no warnings about which workflows can be deleted, and no exclusions. The agent must infer the appropriate 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?

No annotations are provided, so the description carries the burden of disclosing behavior. It does this well by stating what the search returns, how minimal_output changes the response, and the default/maximum limit. It does not disclose tag matching semantics (AND vs OR) or error behavior, but the core behavioral contract is visible.

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

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

The description starts with the core purpose, then states returnv alues and usage tips. Every sentence adds relevant operational detail, though some sentences repeat schema metadata (e.g., default25/max200). It is concise enough and front-loaded, but a tighter version could omit duplicate schema facts.

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 flexible search tool with seven optional parameters and no output schema, the description covers the key decisions: what to search by, which domain/type values are valid, how to limit results, and how to reduce output. It does not describe the full response structure or result ordering, but the description is sufficient for an agent to invoke the tool correctly in most cases.

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

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

Schema description coverage is 100%, so the baseline is 3. The description largely restates schema-provided information, such as domain values, type examples, default limit, and minimal_output behavior. It adds a little context by mapping domains to entity kinds (APM apps, hosts, synthetic monitors), but it does not significantly deepen the meaning beyond the schema.

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

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

The description clearly states the tool searches for New Relic entities by name, type, domain, or tags, and specifies the returned data (GUIDs, alert severity, metadata). This distinguishes it from sibling tools like get_entity (which likely fetches a single entity by GUID) and list_synthetic_monitors (which focuses on one domain). The verb 'Search' plus the filter dimensions give a precise purpose.

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

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

The description provides clear context for when to use this tool: searching for entities across domains or by flexible filters such as name, tags, domain, or type. It also gives concrete usage guidance for domain, type, minimal_output, and limit. It does not explicitly mention exclusions or alternatives (e.g., 'use get_entity when you already have a GUID'), so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get recent' and does not clarify whether it returns only open violations, both open and closed, the meaning of the hours window, pagination limits, or how violations relate to incidents. This is a significant transparency gap for a tool with no structured behavioral hints.

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

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

The description is a single clean sentence with no filler or redundancy. It is front-loaded with the verb and resource, though the brevity leaves behavioral details unstated; that gap is better penalized in other dimensions.

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

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

For a tool with no output schema and no annotations, this description is underspecified. It does not disambiguate from the sibling get_incidents, does not explain what the returned data looks like, and does not state whether the incident/violation distinction matters for the caller. An agent would likely need additional investigation before invoking 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 100%, and the only parameter 'hours' is already documented with type, default, and a description. The tool description adds no extra meaning to the parameter beyond loosely implying recency, so the schema carries the semantic weight and 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 names a specific verb and resource: 'Get recent alert violations and incidents.' It is clear it returns alert violation and incident data, but it does not differentiate itself from the closely named sibling get_incidents, so the agent could be uncertain which tool to prefer.

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 like get_incidents or query_nrql. The phrase 'recent' implies a time-based lookup, but no exclusions, prerequisites, or routing 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?

With no annotations, the description carries the full behavioral disclosure burden, but it only says 'Get error metrics.' It does not explain what is included in the metrics, whether any side effects occur, or what kind of response the agent should expect. The read-only nature is implied by 'get' but not explicitly stated.

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

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

The description is a single clear sentence with no superfluous content. It is appropriately concise, though it sacrifices useful context for brevity.

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, has fully documented parameters, and lacks an output schema. However, the description omits any detail about the nature of the error metrics, time window semantics beyond the schema default, and result shape, leaving the agent to infer some behavior.

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

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

Schema description coverage is 100%, so the input schema already documents both app_name and hours. The description adds only a loose mapping to 'specific application' and no additional detail about how the parameters interact or what unit the metrics are in.

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

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

The description states a specific action ('get'), a resource ('application'), and the data type ('error metrics'). It is unambiguous about what the tool returns, though it does not differentiate itself from similar siblings like get_app_performance or get_alert_violations.

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 such as get_app_performance, get_alert_violations, or query_nrql. There are no exclusions, prerequisites, or examples of appropriate use.

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 must carry the burden of behavioral disclosure. It only says 'Get performance metrics' and does not explain the time-window behavior, read-only nature, response shape, or any other runtime behavior beyond the basic operation.

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

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

The description is a single, front-loaded sentence with no filler or repetition. It is concise, though it is so brief that it sacrifices useful guidance that could be included without much additional 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?

With no output schema and no annotations, the description is too sparse to fully prepare an agent. It does not specify which performance metrics are returned, what the effect of the hours parameter is, or how this tool differs from query_nrql and get_app_errors. This is insufficient for an agent expected to call it correctly in varied contexts.

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%: app_name is described as 'Name of the application' and hours as 'Number of hours to look back (default: 1)'. The description itself adds no parameter-specific meaning beyond indicating the tool is about performance metrics, so 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 states a clear verb ('Get') and resource ('performance metrics for a specific application'), making the basic purpose understandable. It does not explicitly differentiate from siblings like get_app_errors, though the phrase 'performance metrics' implies a broader scope than errors.

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 choose this tool over related alternatives such as get_app_errors, query_nrql, or get_infrastructure_hosts. There are no prerequisites, exclusions, or conditions for use.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the important API limit of 200 dashboards and attributes it to API limits. However, it does not explain whether guid returns a single dashboard, how search and guid interact, pagination behavior, or response shape, leaving meaningful gaps.

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

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

The description is two short sentences with no filler. The core action and key constraint ('max 200 due to API limits') are front-loaded, and the search guidance is a useful 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 read tool with three optional parameters and no output schema, the description is adequate but incomplete. It misses the relationship with the sibling search_all_dashboards tool and does not clarify parameter interactions such as guid combined with search or limit. An agent could call it correctly, but might not choose the optimal tool.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds a nudge to use search for efficient lookup and gives context for the 200 limit, but it does not add substantive meaning beyond the schema's parameter 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 and resource: 'Get New Relic dashboards', with a clear scope limit of 200. It does not explicitly distinguish itself from the sibling 'search_all_dashboards', so it misses the top score for 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 description implies usage guidance with 'Use search parameter to find specific dashboards efficiently', but it does not say when to prefer this tool over search_all_dashboards, when not to use it, or how to handle the 200-item API limit. The guidance is present but only implied.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. 'Get' clearly implies a read-only retrieval, and the phrase 'with their details and IDs' conveys the response contents. However, it does not explicitly confirm side-effect-free behavior, nor does it address edge cases like empty dashboards or invalid GUIDs.

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

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

The description is a single sentence that front-loads the verb and resource, with zero wasted words. It efficiently covers what the tool does and what it returns.

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

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

For a single-parameter retriever with no output schema, the description is largely complete: it identifies the input implicitly through the schema and states that the output includes widget details and IDs. It does not describe the exact shape of widgets or whether pagination is involved, but the tool's simplicity and the existence of related tools make this gap minor.

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 the sole parameter dashboard_guid described as 'Dashboard GUID to get widgets from'. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb (Get) and resource (all widgets from a dashboard), clearly distinguishing it from mutation siblings like add_widget_to_dashboard, update_widget, and delete_widget. It also explicitly states the return content (details and IDs), making the tool's 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 implies usage: if you need widgets from a dashboard, this is the tool. However, it does not explicitly state when to use it versus alternatives or mention that the dashboard_guid likely comes from get_dashboards. No exclusions or alternative recommendations are provided, so guidance remains implicit.

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 must carry behavioral disclosure. It implies a read operation ('get') but does not state whether it is safe/read-only, what 'impact' refers to, whether results are paginated, or what the response shape is.

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

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

The description is a single, front-loaded sentence with no filler or redundant phrases. It is appropriately brief, though it sacrifices useful detail for brevity.

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 low-complexity tool with two optional parameters and no output schema, the description gives a minimal viable purpose but leaves the meaning of 'impact' and the return format unspecified. It is adequate for basic invocation but not fully complete.

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

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds no extra meaning about how hours or app_name affect the result, but the baseline of 3 is appropriate because the schema carries the semantic weight.

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 and resource ('deployment markers') plus what is returned ('their impact'). It is clear but does not explicitly differentiate from sibling tools such as get_incidents or get_alert_violations.

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 like query_nrql or entity_search. It does not state whether it is for a specific product area or how it relates to deployment-related workflows.

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

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

No annotations are provided, so the description carries the burden of explaining behavior. It clearly communicates that this is a read-style lookup returning full entity details, including concrete examples of type-specific metadata. It does not explicitly state 'read-only' or mention error behavior, but the lookup framing and return-value focus make the tool's behavior reasonably transparent.

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

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

The description is three sentences and every sentence earns its place: the first states the core action, the second details expected returns, and the third routes to sibling tools. It is front-loaded with the most important information and contains no filler.

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

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

This is a simple single-parameter read tool with no output schema, and the description covers all essential context: what the tool does, what the input is, what will be returned, and which sibling tools to use instead for related needs. Nothing critical for a correct invocation or selection 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 schema already documents the single guid parameter, but the description adds useful context by identifying it as the New Relic entity GUID and pointing to entity_search as the way to discover GUIDs. This helps an agent understand where the value comes from and what format to supply, going slightly beyond the bare 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 opens with a specific verb and resource: 'Look up a single New Relic entity by its GUID.' It lists the exact kinds of details returned, such as name, type, alert severity, tags, and type-specific metadata, which clearly distinguishes this tool from siblings like entity_search and decode_entity_guid.

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

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

The description explicitly states when to use alternatives: 'Use entity_search to find GUIDs, or decode_entity_guid to inspect a GUID without an API call.' This tells an agent which tool to choose based on the current need and implies that get_entity is for when you already have a GUID and want full entity details.

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

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

With no annotations, the description carries the behavioral disclosure burden. The verb 'Get' implies a read-only operation, but the description does not mention error behavior, empty-tag results, or whether account_id alters the response. This is adequate for a simple read tool but not richly transparent.

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

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

The description is two short sentences with no filler. The primary purpose is front-loaded, and the second sentence gives a useful prerequisite without 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 two-parameter read tool with no output schema, the description and schema together cover the essentials: what is returned, the required guid, and how to find guids. It does not describe the output shape or error cases, but those are not critical for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents both guid and account_id. The description reinforces the guid's role by saying 'by its GUID' and connecting it to entity_search, but it adds no additional meaning for account_id, leaving the baseline of 3 appropriate.

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

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

The description states a specific verb and resource: 'Get all tags for a New Relic entity by its GUID.' It clearly differentiates from sibling tag mutation tools like add_tags_to_entity and delete_tags_from_entity, and from get_entity, by focusing narrowly on retrieving tags.

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 instruction 'Use entity_search to find GUIDs' provides clear workflow context for obtaining the required input. It does not explicitly name alternatives or exclusion cases, so it stops short of a 5, but the intended usage is evident.

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

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

With no annotations present, the description carries the full burden of behavioral disclosure, but it only conveys that the operation is a read ('Get'). It does not disclose whether returned incidents are open, resolved, or both; how the hours parameter shapes results beyond the schema; or any pagination or result-limit 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?

One seven-word sentence with the verb front-loaded and zero filler; it is efficient and scannable. However, the brevity stems from under-pecification rather than from distilling rich content, so it does not earn a 5.

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

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

Adequate for a single-optional-paramter read tool: the schema covers hours, and 'recent incidents' names the return subject. But with no output schema and a crowded sibling set of alert/incident/error tools, the agent lacks the context to route correctly or anticipate the response shape.

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 the sole paramter (hours: 'Number of hours to look back (default: 24)') at 100% coverage, so the baseline of 3 applies. The description's word 'recent' loosely aligns with the hours paramter but adds no syntax, format, or edge-case detail beyond what the schema provides.

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

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

The description states a specific verb ('Get'), a resource ('incidents'), and a platform ('New Relic'), making the core action unambiguous and matching the tool name. However, it does not differentiate from overlapping siblings like get_alert_violations or get_app_errors, which an agent could plausibly confuse with incidents.

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 provided — there is no mention of when to prefer this over get_alert_violations, no exclusions, and no context on the distinction between an incident and a violation. An agent must guess which sibling fits its task from the 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?

There are no annotations, so the description must carry the full behavioral burden. It states only that hosts and metrics are retrieved, but it does not disclose whether the operation is read-only, whether results are paginated, what metrics are included, or how the hours parameter affects the response. Key behavioral traits remain unspecified.

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, 'Get infrastructure hosts and their metrics', with the core action front-loaded and no filler. It is efficient, though it could include more useful 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 simple read tool with no required parameters and no output schema, the description is minimally adequate: it names the resource and the returned data type. However, it omits return structure, pagination behavior, what 'metrics' actually includes, and how this tool relates to sibling tools, so it is not fully self-contained.

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

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

The schema already documents the single hours parameter fully, including its type, default, and meaning, with 100% schema description coverage. The description adds no additional parameter semantics beyond that, which is acceptable given how thoroughly the schema covers the only 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 uses a specific verb and resource: it retrieves infrastructure hosts and their metrics, which clearly identifies the tool's core purpose. However, it does not explicitly distinguish this tool from siblings like get_app_performance or query_nrql, so the differentiation comes more from the name than the description.

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 usage guidance is provided. The description does not say when to use this tool instead of alternatives such as entity_search, get_entity, or query_nrql, nor does it mention any exclusions or prerequisites. An agent would have to infer the appropriate context 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?

With no annotations, the description carries the full burden. It discloses the core read behavior and expected output content: pass/fail per location, duration, and error messages. It does not mention edge details like pagination or result limits, but for a simple read-only get tool this is reasonably transparent.

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

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

Two sentences with no filler. The core purpose is front-loaded, followed by output summary and a useful pointer to the sibling tool. Every sentence earns its place.

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

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

For a simple tool with one required parameter and no output schema, the description is complete: it states what the tool returns, references the lookup tool for the required GUID, and the schema documents all parameters. No critical information is missing 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 baseline is 3. The description adds little beyond the schema: 'recent' loosely maps to the hours parameter and 'specific synthetic monitor' maps to monitor_guid, but it does not explain parameter relationships or format details beyond what the schema already provides.

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

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

The description uses a specific verb and resource: 'Get recent check results for a specific synthetic monitor.' It also clarifies what the results contain ('pass/fail per location, duration, and error messages'), making it easy to distinguish from sibling tools like get_app_performance or list_synthetic_monitors.

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 directs the agent to use list_synthetic_monitors to find monitor GUIDs, which is a clear prerequisite and points to the relevant sibling tool. However, it does not explicitly state when not to use this tool versus other monitoring/query 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 at all, the description carries the full burden of behavioral disclosure. It only states the basic listing operation and omits important details such as pagination, read-only nature, ordering, result size limits, or how the filters combine, leaving the agent without information about expected 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 that front-loads the action and then lists the filter options. Every word earns its place and there is no redundant phrasing or filler.

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

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

The description lacks details an agent often needs for a list tool: pagination, ordering, return shape, and whether filters are combined with AND/OR semantics. Since there is no output schema and no annotations, the description alone is too thin to fully guide a correct invocation in complex workflows.

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

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

Schema coverage is 100% and each parameter already has a clear description. The tool description only restates the filter options ('policy, name, or NRQL query') without adding nuance like match semantics, required formatting, or interaction between filters, so it does not add value beyond the schema.

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

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

The description uses a clear verb-resource pair ('List alert conditions') and names three concrete filter dimensions (policy, name, NRQL query), so an agent can understand what the tool does. It does not explicitly differentiate it from sibling alert-related tools, but the resource and filter set make the purpose reasonably distinct.

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

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

The phrase 'optional filters' gives some context that this is a search/browse operation, but there is no guidance on when to prefer this tool over siblings like list_alert_policies or get_alert_violations. No when-not-to-use guidance or alternative tool references are given.

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

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

With no annotations provided, the description must carry the full behavioral burden. The word 'List' clearly indicates a read-only, non-destructive operation, which is valuable. However, it does not disclose whether results are paginated, what fields are returned, or any account-level permission constraints, leaving some behavioral ambiguity.

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

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

One short sentence that conveys the tool's purpose, scope, and behavior without any wasted words. It is fully front-loaded and easily parsed.

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, simple list operation, the description is almost complete. It tells the agent exactly what will happen (list all alert policies) and the scope (account). However, since there is no output schema, the agent is left without explicit information about the response shape or expected fields, so it falls just short of a 5.

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 schema is already complete (100% coverage). The description adds nothing about parameters, which is appropriate; there is nothing to document. Baseline 4 is warranted.

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 'List all alert policies in the account' clearly names the action (list), the resource (alert policies), and the scope (account). It is immediately distinguishable from siblings like list_alert_conditions (conditions) and get_alert_violations (violations) based on resource type alone.

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

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

The description implies when to use the tool—when a full account-level list of alert policies is needed—but it does not explicitly mention alternatives or exclusion criteria. Since the resource is unambiguous, an agent could infer usage, 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?

With no annotations, the description must carry the transparency burden. It conveys a read-only enumeration and specifies that conditions and schedules are included in results, but it does not disclose pagination, ordering, authorization requirements, or limits. 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?

A single, front-loaded sentence with no filler. It immediately states the action and resource, then the scope and output content. Every word earns its place.

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

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

For a zero-parameter read tool, the description covers the key facts: what is listed, the scope, and what the results contain. It stops just short of full completeness because there is no output schema or note about response format/pagination, but the tool's simplicity keeps 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?

The input schema has zero properties and 100% description coverage, so there are no parameters requiring explanation. Per the zero-parameter baseline, the description does not need to compensate for schema gaps.

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

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

The description uses a specific verb ('List'), names the exact resource ('muting rules'), and gives the scope ('all ... in the account') plus the returned aspects (conditions and schedules). This clearly distinguishes it from siblings like create_muting_rule and delete_muting_rule without needing to inspect schemas.

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

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

The description implies the intended use: call when you need the complete set of muting rules in the account. However, it does not explicitly state when not to use it or point to alternatives such as creating or deleting muting rules, so the guidance is only implicit.

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 tool name with 'all' added, and does not mention pagination, response format, account scope, or any other behavioral traits.

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

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

The description is a single short sentence with no wasted words, making it concise. However, it adds little beyond the tool name itself, so it is efficient but not especially informative.

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

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

For a zero-parameter list operation, the description is minimally sufficient to invoke the tool. However, with no output schema and no annotations, it omits expected return details, pagination behavior, and any distinction from similar listing 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?

The input schema has zero parameters, so there is no parameter semantics for the description to clarify. With no parameters, the baseline is high 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 clearly states the verb 'List' and the resource 'notification channels', and 'all' signals an unfiltered listing. It distinguishes from creation/update siblings by its action, but it does not explicitly separate itself from list_notification_destinations, so it falls just short of a top score.

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 sibling tools like list_notification_destinations or create_notification_channel. No exclusions, prerequisites, or alternative tool hints are provided.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. 'List all' clearly indicates a read-only enumeration operation with no filtering, which is useful, but it does not describe the return shape, pagination, or error behavior. This is adequate for a simple list tool but minimally transparent.

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

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

The description is only four words and entirely front-loaded. It contains no filler or redundant phrasing, and every word contributes to the meaning.

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, with no parameters and no output schema, so the description is minimally viable. However, it omits useful context such as the output structure or the relationship between destinations and channels. An agent could invoke it correctly, but would have limited understanding of what to expect.

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

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

The input schema has zero properties and 100% description coverage, so there are no parameters for the description to clarify. For a zero-parameter tool, the baseline is 4.

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

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

The description states a specific verb and resource: 'List all notification destinations'. It is clear and unambiguous about the core operation. It does not explicitly distinguish itself from sibling tools like list_notification_channels, but the destination vs channel naming makes the resource reasonably distinct.

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

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

The description provides no guidance on when to use this tool over alternatives such as list_notification_channels or list_alert_policies. There is no mention of context, preconditions, or exclusions, so an agent must rely on 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 provided, so the description carries the burden. It communicates that this is a listing operation and previews the returned content (objectives, targets, time windows, NRQL queries), but it does not mention pagination, default account scoping when account_id is omitted, or potential errors/auth requirements.

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

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

Two tightly written sentences with no filler. The primary action and scope are front-loaded, and the output summary is 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 one-optional-parameter list tool with no output schema, the description is largely complete: it names the resource, scope, and the main content fields that will be returned. Minor gaps are the lack of explicit return format/pagination and account_id default behavior.

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

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

Schema description coverage is 100%, so the schema already documents the only parameter, account_id. The description only says 'for the account' and adds no extra meaning about how account_id behaves or what happens if it is omitted.

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

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

The description uses a specific verb ('List') and resource ('Service Level Indicators (SLIs/SLOs) for the account'), and it names concrete output fields. This clearly distinguishes it from sibling list tools like list_alert_policies or list_muting_rules.

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

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

The description implies the tool is for retrieving the account's SLI/SLO definitions, but it does not explicitly explain when to prefer this over alternatives or when not to use it. There are no exclusion conditions or sibling references.

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

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

With no annotations provided, the description carries the full burden. It clearly indicates the tool returns a list of monitors with several status and configuration fields, which is useful. However, it does not disclose potential pagination behavior, rate limits, account scoping beyond the optional account_id, or any caveats about 'all' monitors.

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

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

The description is a single, front-loaded sentence that immediately states the action and resource, then efficiently lists the notable output fields. There is no filler or redundant information.

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

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

For a read-only list tool with one optional parameter and no output schema, the description provides a strong picture of the returned data. The main gaps are lack of explicit mention of pagination, default account behavior, and a precise definition of 'location health,' but these are minor for this simple tool.

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

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

Schema description coverage is 100%, with the single account_id parameter already described as optional. The tool description adds no additional meaning about how account_id affects the listing, so the baseline score of 3 is appropriate; the schema does the heavy lifting.

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'), names the resource ('synthetic monitors'), and enumerates the key returned attributes (status, success rate, monitor type, check period, location health). It is clearly distinct from the sibling get_synthetic_results, which focuses on test results rather than monitor listings.

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

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

No explicit guidance is given about when to use this tool versus alternatives such as get_synthetic_results or entity_search. The usage context is only implied by the verb 'List' rather than stated directly, and no preconditions or exclusions 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?

No annotations are provided, so the description carries the full burden of describing behavior. It only rephrases the tool name and does not address pagination, response shape, authentication, rate limits, or return scope beyond the word 'all'.

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 is appropriately sized for a zero-parameter 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?

For a simple zero-param list, the core action is stated, but with no output schema and no annotations the description does not clarify what fields each workflow contains or whether pagination is a concern. Adequate but not fully complete.

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

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

The schema has zero parameters and 100% coverage, so there is no parameter detail the description needs to add. Baseline of 4 applies.

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

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

The description states a specific verb ('List'), a distinct resource ('alert workflows'), and a clear scope ('all'). This cleanly separates it from sibling tools like create_workflow, delete_workflow, and list_alert_policies.

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. There is no mention of exclusions, prerequisites, or scenarios favoring list_workflows over create_workflow, delete_workflow, or related list 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 disclosure burden and reveals meaningful behaviors: timeout risk for high-volume apps ('avoid query timeouts'), default result caps ('default is 10 for FACET queries'), and accepted time-range formats. It does not mention output shape or rate limits, but the safety profile of a read-only query tool is largely conveyed.

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

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

The purpose is front-loaded in the first sentence, followed by a dense but purposeful run of NRQL tips; nearly every sentence addresses a common failure mode (timeouts, high-cardinality attributes, unbounded results). It is long, but for a raw query-language tool the guidance earns its place; bullet formatting would improve scannability.

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 that accepts arbitrary NRQL with no output schema and no annotations, the description covers event types, time-range formats, query clauses, performance constraints, and defaults — enough scaffolding for an agent to compose a valid query. Minor gaps: it does not describe the response format or how to scope by entity/app name in WHERE clauses.

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 schema already names query and account_id. Beyond that baseline, the description adds substantial meaning to the query parameter by teaching NRQL syntax, time-range formats, and best practices (uniqueCount() over uniques(), LIMIT caps, short windows for high-volume apps).

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 exact action — 'Execute a NRQL query against New Relic' — with a clear verb and resource. It is unmistakably distinct from sibling CRUD tools like delete_dashboard or get_incidents, and the enumerated event types (Transaction, Span, Log) further scope what it queries.

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 rich how-to guidance (SINCE ranges, TIMESERIES, FACET, LIMIT) but no explicit when-to-use or when-not-to-use direction versus siblings such as get_app_performance or entity_search. Selection guidance is only implied: an agent must infer that raw NRQL queries belong here rather than in structured retrieval tools.

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

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

No annotations are provided, so the description carries the behavioral transparency burden. It prominently discloses the destructive overwrite nature of the operation ('overwrites existing tags'), which is the most critical behavioral trait. It does not cover permissions, idempotency, or error behavior, but the core side effect is clearly stated.

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

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

Two short sentences deliver the core action, the destructive consequence, and the sibling alternative with zero wasted words. The overwrite warning is front-loaded before the routing hint.

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

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

For a simple 3-parameter mutation with no output schema, the description plus fully documented input schema is enough for an agent to select and invoke the tool correctly. It covers the target resource, the exact behavior, and the alternative tool.

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

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

Schema description coverage is 100%, so the schema fully documents guid, tags, and account_id, including the note that tags replaces all existing tags. The description adds no new parameter-level meaning beyond what the schema already provides, which maps to 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 uses a specific verb ('Replace'), names the exact resource ('ALL tags on a New Relic entity'), and clarifies the overwrite behavior. It also differentiates itself from the sibling add_tags_to_entity by explicitly stating what it is not.

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

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

It explicitly tells the agent when to choose this tool versus the append alternative: 'Use add_tags_to_entity to append instead.' This provides clear routing guidance with no ambiguity.

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

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

The description discloses a meaningful behavioral trait: it retrieves at most 200 dashboards from the API and then filters locally. Since no annotations are provided, this is important information for the agent, as it warns about potential incomplete results for large result sets. Pagination and error behavior are not described, but the key limitation is clearly stated.

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

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

The description is compact and front-loaded: it states the purpose, the key implementation detail, and the intended use case in two short sentences. There is no redundant or filler content.

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

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

For a tool with only two optional parameters and completely documented schema, the description provides the essential context: what it does, how it behaves at scale, and when to prefer it. The absence of an output schema means return shape is not described, but for a search tool this is a relatively minor gap.

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

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

Schema description coverage is 100%, with both parameters already having clear descriptions in the input schema. The tool description adds no additional parameter-specific details, 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 states a concrete action ('Search through dashboards') with a specific resource and adds a distinguishing detail: local filtering with a 200-dashboard cap. It is clear and understandable, though it does not explicitly name sibling tools like get_dashboards to contrast the difference.

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?

'Better for complex searches' provides clear guidance on when to prefer this tool, implying it is the right choice when server-side filtering or simple listing is insufficient. However, it does not explicitly mention alternatives or state when NOT to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It signals mutation and scopes changes to name/incident preference, but it does not state whether updates are partial or full replacements, what permissions are required, whether changes are reversible, 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?

A single sentence with no filler, front-loaded with the action and resource and a concise parenthetical field list. 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 with only three parameters and full schema coverage, so the description plus schema is enough for a basic correct invocation. However, the lack of annotations and output schema leaves operational gaps such as partial-update behavior and preconditions, which an agent might need to know.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds no new parameter semantics beyond naming the mutable fields; policy_id is not mentioned in prose but is fully documented 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 (update) and resource (alert policy), and clarifies the mutable fields (name and/or incident preference). It is easily distinguished from create_alert_policy, delete_alert_policy, and list_alert_policies, 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?

The intended use is implied: modifying an existing alert policy rather than creating or deleting one. However, there is no explicit guidance on when to choose this tool over update_nrql_condition or any other update-related sibling, and no exclusions are 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Update', which is a mutation, but it does not describe partial-update semantics, validation behavior, side effects, or what happens to unmentioned settings. This is a significant transparency gap for a mutation tool.

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

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

The description is a single sentence with no filler or repetition. It front-loads the verb and resource, which is exactly what an agent needs for quick selection.

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 parameter schema is rich and fully describes inputs, but the tool lacks annotations and an output schema, and the description provides no behavioral or usage context beyond the basic update intent. For a 9-parameter mutation tool, a bit more context about update semantics would make it complete.

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

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

Schema description coverage is 100%, with all 9 parameters documented. The description itself adds no parameter-level detail, but the baseline of 3 is appropriate because the schema already carries the semantic weight.

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 ('Update') and resource ('existing NRQL alert condition'), making the tool's purpose immediately clear. It is also easily distinguished from sibling tools like create_nrql_condition and delete_nrql_condition.

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 'existing NRQL alert condition' provides clear context: use this tool when modifying an already-created condition, not for creating or deleting one. However, it does not explicitly name alternatives or state when-not-to-use, so it stops short of full guidance.

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

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

No annotations are provided, so the description carries the full burden. It does substantial work here: raw_configuration takes precedence over typed configuration, nrqlQueries requires accountIds (array) and is auto-populated from widget_query if omitted, New Relic appends suffixes to series names, and logarithmic scale is unsupported. This gives real operational insight beyond a generic 'update' statement, though it does not cover return values or authentication.

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

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

The description is long, but the length is justified by the complexity of raw_configuration and the need to show exact JSON shapes. The main purpose is front-loaded, and the examples are organized by feature with clear headings. It could be tightened slightly, but most sentences earn their 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 mutation tool with six parameters, a nested object, and no output schema, the description covers the non-obvious behaviors thoroughly. The obvious parameters page_guid and widget_id are self-explanatory, and the raw_configuration details are extensive. The only notable gap is the lack of any mention of return values or errors, but that is minor for an update operation.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful value beyond the schema by providing concrete JSON examples for yAxisLeft, dual y-axis, legend, facet, platformOptions, thresholds, and chartStyles. It also highlights the critical accountIds vs accountId pitfall and the auto-population behavior, which the schema alone does not convey.

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

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

The description opens with 'Update an existing widget on a dashboard,' a specific verb and resource that clearly defines the operation. It is distinct from sibling tools like add_widget_to_dashboard and delete_widget, and even references add_widget_to_dashboard in the body, reinforcing the difference.

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 'existing widget' implies this is for modifying an existing widget rather than creating or deleting one, but there is no explicit guidance about when to choose this over add_widget_to_dashboard or delete_widget. The mention of add_widget_to_dashboard is for an example, not for usage routing, so the guidance is implied rather than stated.

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