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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Record a new deployment' implies a write operation that creates data, but it doesn't specify whether this is idempotent, what permissions are required, how failures are handled, or what happens if duplicate deployments are recorded. For a mutation tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that gets straight to the point with no wasted words. It's appropriately sized for a basic tool description and front-loads the core purpose immediately. Every word earns its place in conveying the essential action.

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

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

Given that there's an output schema (which handles return values) but zero annotation coverage and 0% schema description coverage for 5 parameters, the description is incomplete. It adequately states what the tool does at a high level but lacks crucial details about parameter meanings, behavioral characteristics, and usage context that would make it fully helpful for an AI agent.

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

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

Schema description coverage is 0%, so all 5 parameters are undocumented in the schema. The description mentions 'application' which loosely relates to 'app_id', but provides no information about what 'revision', 'description', 'user', or 'changelog' parameters mean, their expected formats, or how they affect the deployment. The description fails to compensate for the complete lack of 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 clearly states the action ('Record a new deployment') and resource ('for an application'), making the purpose immediately understandable. It distinguishes from sibling tools like 'list_deployments' by focusing on creation rather than listing. However, it doesn't specify what constitutes a 'deployment' in this context, leaving some ambiguity about the exact nature of the operation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing application), compare with similar tools like 'list_deployments' for checking existing deployments, or specify appropriate contexts for deployment recording. The agent must 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 only states the action ('create') without detailing permissions, side effects, rate limits, or response format. For a mutation tool with zero annotation coverage, this is inadequate and leaves critical behavioral traits 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, efficient sentence with no wasted words. It is appropriately sized and front-loaded, though its brevity contributes to underspecification rather than clarity. Every word serves the purpose, earning a high score for conciseness despite content gaps.

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

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

Given the complexity of a 6-parameter mutation tool with no annotations and 0% schema coverage, the description is severely incomplete. It lacks purpose differentiation, usage guidelines, behavioral context, and parameter semantics. Although an output schema exists, the description does not provide enough context for effective tool use, making it inadequate overall.

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

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

Schema description coverage is 0%, meaning none of the 6 parameters are documented in the schema. The description adds no information about parameters, failing to compensate for this gap. It does not explain what 'grok', 'nrql', or other fields mean, their formats, or how they interact, leaving parameters entirely undocumented.

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

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

The description 'Create a new log parsing rule' restates the tool name with minimal elaboration. It specifies the verb ('create') and resource ('log parsing rule'), but does not distinguish from siblings like 'generate_log_parsing_rule' or 'update_log_parsing_rule', leaving ambiguity about when to use each. This is a tautological restatement rather than a clear, differentiated 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?

No guidance is provided on when to use this tool versus alternatives. Siblings include 'generate_log_parsing_rule' and 'update_log_parsing_rule', but the description does not mention these or explain prerequisites, contexts, or exclusions. This lack of guidance could lead to incorrect tool selection.

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

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

No annotations are provided, so the description carries the full burden. It states 'Delete' which implies a destructive mutation, but doesn't disclose critical behavioral traits: whether deletion is permanent or reversible, authentication requirements, rate limits, side effects (e.g., impact on logs), or error handling. This leaves significant gaps for safe agent use.

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

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

The description is a single, efficient sentence with zero waste—it directly states the tool's action and resource. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given a destructive tool with no annotations, 2 parameters (0% schema coverage), and an output schema (which might help), the description is incomplete. It lacks behavioral context, parameter guidance, and usage rules, making it insufficient for safe and effective agent invocation.

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

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

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It adds no meaning beyond the schema—doesn't explain what 'rule_id' or 'account_id' represent, their formats, or how to obtain them (e.g., from 'list_log_parsing_rules'). With 2 parameters and low coverage, this is inadequate.

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 'Delete a log parsing rule' clearly states the action (delete) and resource (log parsing rule), which is better than a tautology. However, it doesn't differentiate from sibling tools like 'update_log_parsing_rule' or 'test_log_parsing_rule' beyond the verb, and it lacks specificity about what deletion entails (permanent vs. soft, scope, etc.).

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing rule), exclusions, or related tools like 'list_log_parsing_rules' for selection. Usage is implied only by the verb 'delete,' with no explicit context.

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

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

With no annotations provided, the description carries the full burden. It discloses that the tool generates patterns and analysis (output behavior) and mentions default values, but it doesn't cover critical behavioral aspects such as whether this is a read-only or mutating operation, authentication needs, rate limits, or error handling. The description adds some context but is incomplete for a tool with 5 parameters and no annotations.

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

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

The description is well-structured and front-loaded with the core purpose, followed by a clear 'Args' and 'Returns' section. Each sentence adds value without redundancy. It could be slightly more concise by integrating the default notes into the parameter descriptions, but overall it's efficient and easy to parse.

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

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

Given the tool's complexity (5 parameters, no annotations, but with an output schema), the description is reasonably complete. It covers the purpose, all parameters with semantics, and the return value structure. The output schema exists, so the description doesn't need to detail return values. However, it lacks behavioral context like side effects or error conditions, which holds it back from a perfect score.

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

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

Schema description coverage is 0%, so the description must compensate. It provides meaningful semantics for all 5 parameters: it explains what each parameter is for (e.g., 'log_query: Optional NRQL WHERE clause to fetch logs'), gives examples (e.g., "service = 'api'"), and notes defaults (e.g., 'default: "1 hour ago"'). This adds significant value beyond the bare schema, though it could be more detailed on constraints or interactions between parameters.

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

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

The description clearly states the tool's purpose: 'Generate a log parsing rule from either a query or provided samples.' It specifies the verb ('Generate') and resource ('log parsing rule'), and distinguishes the two input methods (query vs. samples). However, it doesn't explicitly differentiate from sibling tools like 'create_log_parsing_rule' or 'test_log_parsing_rule' in terms of when to use each, which prevents a perfect 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?

The description implies usage by mentioning two alternative input methods (query or samples) and providing default values (e.g., 'default: "1 hour ago"'), but it lacks explicit guidance on when to choose one method over the other, prerequisites, or comparisons to sibling tools like 'create_log_parsing_rule'. This leaves some ambiguity for the agent.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), but doesn't mention authentication needs, rate limits, error conditions, or what the output contains. This leaves significant gaps for a tool with an output schema but no behavioral context.

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

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

The description is a single, efficient sentence with no wasted words, making it appropriately sized and front-loaded. Every word contributes directly to stating the tool's purpose.

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

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

Given the tool has an output schema (which handles return values), one simple parameter, and no annotations, the description is minimally adequate but incomplete. It lacks behavioral details and usage guidance, making it just sufficient for basic understanding but with 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 description adds no meaning beyond the input schema, which has 0% description coverage for the single parameter 'policy_id'. However, with only one parameter and a clear title ('Policy Id'), the schema is minimal, so the baseline is 3 as the description doesn't compensate but the burden is low.

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

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

The description 'Get details for a specific alert policy' clearly states the verb ('Get') and resource ('alert policy'), but it's vague about what 'details' entail and doesn't distinguish it from sibling tools like 'list_alert_policies'. It provides a basic purpose but lacks specificity.

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

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

No guidance is provided on when to use this tool versus alternatives such as 'list_alert_policies' for multiple policies or other get_* tools for different resources. The description implies usage for a specific policy but offers no explicit context or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves details but doesn't specify whether this is a read-only operation, what authentication is required, potential rate limits, error conditions, or the format of returned data. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

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

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

The description is a single, efficient sentence that front-loads the core purpose without unnecessary words. It directly communicates the tool's function, making it easy to parse quickly. Every part of the sentence earns its place by specifying the action and target resource.

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

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

Given the tool's low complexity (1 parameter) and the presence of an output schema, the description is reasonably complete for basic understanding. The output schema likely covers return values, reducing the need for detailed behavioral explanation. However, with no annotations and minimal parameter semantics, it could benefit from more context on usage and constraints to fully guide an 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?

The input schema has 1 parameter with 0% description coverage, so the schema provides no semantic information. The description mentions 'specific New Relic application' but doesn't clarify what 'app_id' represents (e.g., numeric ID, name, GUID) or where to find it. It adds minimal value beyond implying a single identifier is needed, insufficient to fully compensate for the schema's lack of descriptions.

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

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

The description clearly states the verb ('Get details') and resource ('specific New Relic application'), making the purpose immediately understandable. It distinguishes from siblings like 'list_applications' by specifying retrieval of details for a single application rather than listing multiple. However, it doesn't explicitly mention what details are included or the scope of information returned.

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

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

The description implies usage when details for a specific application are needed, contrasting with 'list_applications' for multiple applications. However, it doesn't provide explicit guidance on when to use this versus other detail-retrieval tools like 'get_dashboard' or 'get_server', nor does it mention prerequisites like authentication or rate limits. The context is clear but lacks comprehensive 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get metric data' implies a read-only operation, but it doesn't specify authentication needs, rate limits, error handling, or what the output contains (though an output schema exists). For a tool with 4 parameters and no annotation coverage, this is insufficient to inform the agent about behavioral traits beyond the basic read implication.

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

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

The description is a single, efficient sentence with no wasted words, making it appropriately concise. It's front-loaded with the core action, though it could be more structured by including key details. The brevity is good, but it risks under-specification given the tool's complexity.

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

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

Given the tool has 4 parameters with 0% schema coverage, no annotations, and sibling tools that might overlap, the description is incomplete. It doesn't explain parameter semantics, usage context, or behavioral aspects, though the presence of an output schema mitigates the need to describe return values. For a data retrieval tool in a monitoring context, more guidance is needed to be fully helpful.

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

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

Schema description coverage is 0%, meaning none of the 4 parameters have descriptions in the schema. The tool description doesn't add any parameter details—it doesn't explain what 'app_id', 'metric_names', 'from_time', or 'to_time' mean, their formats, or examples. This leaves parameters largely undocumented, failing to compensate for the low schema coverage.

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

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

The description 'Get metric data for an application' clearly states the verb ('Get') and resource ('metric data for an application'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_application_metrics' (which might retrieve different types of metric information), leaving the distinction vague. This is adequate but lacks specificity about what type of metric data or how it differs from similar tools.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, and with sibling tools like 'get_application_metrics' and 'query_nrql' that might overlap in functionality, there's no indication of when this specific tool is preferred. This leaves the agent without usage direction.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers minimal insight. It implies a read operation ('Get'), but doesn't cover aspects like authentication needs, rate limits, pagination, error handling, or what 'available metrics' includes (e.g., list, schema). This is inadequate for a tool with parameters and potential complexity.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('Get available metrics'), making it easy to parse. Every word contributes directly to the purpose, achieving optimal conciseness for such a brief statement.

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

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

Given the tool has an output schema (which handles return values), 2 parameters with 0% schema coverage, and no annotations, the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on usage, parameters, and behavior, leaving gaps that could hinder effective tool 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 0%, so the schema provides no parameter details. The description mentions 'an application' (hinting at 'app_id') but doesn't explain 'names' (e.g., whether it filters metrics by name). It adds minimal value beyond the schema's structural information, failing to compensate for the coverage gap.

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

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

The description clearly states the verb 'Get' and resource 'available metrics for an application', making the purpose understandable. It distinguishes from siblings like 'get_application_metric_data' (which likely retrieves actual metric values) by focusing on available metrics. However, it could be more specific about what 'available metrics' entails (e.g., metadata, types, or definitions).

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_application_metric_data' (for metric data) or 'get_application' (for general app info), nor does it specify prerequisites or contexts for usage. This leaves the agent without clear direction on tool selection.

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

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

No annotations are provided, so the description carries full burden. It states 'Get details' which implies a read-only operation, but doesn't disclose behavioral traits like authentication requirements, rate limits, error conditions, or what 'details' includes. The description is minimal and lacks necessary context for safe invocation.

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 zero wasted words. It's appropriately sized for a simple tool and front-loads the core purpose without unnecessary elaboration.

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

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

Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is somewhat complete but lacks key context. Without annotations, it should explain more about the operation's behavior and parameter usage to be fully helpful.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'specific dashboard' which hints at the 'guid' parameter's purpose, but doesn't explain what a GUID is, its format, or where to obtain it. The description adds minimal meaning beyond the schema's basic structure.

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

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

The description clearly states the verb ('Get') and resource ('dashboard'), specifying it's for a 'specific dashboard' rather than listing all dashboards. However, it doesn't explicitly distinguish from sibling 'list_dashboards' beyond the singular vs. plural wording, which is implicit but not explicit 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 provides no guidance on when to use this tool versus alternatives like 'list_dashboards' or other get_* tools. It mentions 'specific dashboard' but doesn't clarify prerequisites (e.g., needing a dashboard GUID) or contextual usage scenarios.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets details' but doesn't specify if this is a read-only operation, requires authentication, has rate limits, or what the output format is. This leaves significant gaps for a tool with one parameter and an output schema.

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

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

The description is a single, efficient sentence that is front-loaded with the core action. There is no wasted text, making it appropriately sized for its purpose.

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

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

Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations and low schema coverage, it lacks details on behavior and parameter semantics. For a simple retrieval tool, this is adequate but leaves room for improvement in clarity and context.

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

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

The schema description coverage is 0%, so the description must compensate. It implies a 'server_id' parameter is needed but doesn't add meaning beyond what the schema's title ('Server Id') provides, such as format or examples. With only one parameter, this is minimally adequate but not helpful.

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

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

The description clearly states the verb ('Get') and resource ('details for a specific server'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'list_servers' or specify what 'details' include, which prevents a perfect 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?

No guidance is provided on when to use this tool versus alternatives such as 'list_servers' for multiple servers or other get_* tools for different resources. The description implies usage for a specific server but lacks explicit context or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states this is a read operation ('Get details'), implying it's non-destructive, but doesn't cover aspects like authentication needs, rate limits, error handling, or response format. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration, making it easy to parse quickly.

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

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

Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and low schema coverage, it should provide more context on usage and parameters to be fully complete, resulting in a mid-range score.

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

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

Schema description coverage is 0%, meaning the parameter 'monitor_id' is undocumented in the schema. The description adds minimal value by implying the parameter identifies a specific monitor, but doesn't specify format, source, or constraints. With low coverage, the description partially compensates but not fully, aligning with the baseline for moderate gaps.

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

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

The description clearly states the verb ('Get details') and resource ('for a specific synthetic monitor'), making the purpose understandable. However, it doesn't distinguish this from sibling tools like 'list_synthetic_monitors' or 'get_application', which retrieve different resources or list multiple items rather than getting details for a specific one.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a monitor ID), exclusions, or comparisons to siblings like 'list_synthetic_monitors' for browsing or 'get_application' for different resource types, leaving usage context implied at best.

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

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

No annotations are provided, so the description carries full burden. It states 'Get details' which suggests a read operation, but doesn't disclose behavioral traits like authentication needs, rate limits, error handling, or what 'details' entails. This is a significant gap for a tool with no annotation coverage.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

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

Given the tool's low complexity (one parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete behavioral disclosure, it lacks completeness for safe and effective use.

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

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

Schema description coverage is 0%, but the description adds no parameter information beyond what's implied by 'specific user'. It doesn't explain the 'user_id' parameter's format, constraints, or examples. With one parameter and no schema descriptions, the baseline is 3 as it minimally covers the purpose.

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

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

The description 'Get details for a specific user' clearly states the verb ('Get') and resource ('user'), and specifies it's for a 'specific' user rather than a list. However, it doesn't distinguish from sibling 'list_users' beyond the implied singular vs. plural, missing explicit differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives like 'list_users'. The description implies it's for a specific user, but there's no explicit mention of prerequisites, when-not scenarios, or named 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 of behavioral disclosure. While 'List all alert policies' implies a read-only operation, it doesn't specify whether this requires authentication, includes pagination, returns a specific format, or has rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence with no wasted words. It's front-loaded with the core action ('List all alert policies'), making it easy to parse. Every word earns its place by conveying essential information.

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

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

Given the tool's simplicity (0 parameters, 100% schema coverage, and an output schema exists), the description is minimally adequate. However, with no annotations and a read operation, it should ideally mention authentication needs or return format hints. The output schema reduces the burden, but the description could be more complete for standalone use.

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 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics, and it doesn't introduce any confusion. A baseline of 4 is appropriate since there's nothing to compensate for.

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' clearly states the verb ('List') and resource ('alert policies'), making the purpose immediately understandable. It distinguishes from siblings like 'get_alert_policy' (singular) by specifying 'all' policies. However, it doesn't explicitly differentiate from other list tools (e.g., 'list_applications'), so it's not a perfect 5.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list_alert_policies' over 'get_alert_policy' (for a single policy) or other list tools, nor does it specify any prerequisites or contextual constraints for usage.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It states it's a list operation, implying read-only behavior, but doesn't specify whether it returns all applications at once, uses pagination, requires authentication, has rate limits, or what the output format is. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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

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

The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation. Every word earns its place, making it highly concise and well-structured.

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

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

Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. The output schema will handle return values, so the description doesn't need to explain those. However, with no annotations and a list operation that might have behavioral nuances (e.g., pagination, scope), the description could benefit from additional context about how the listing works.

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

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

The input schema has 0 parameters with 100% coverage, meaning there are no parameters to document. The description appropriately doesn't mention any parameters, which is correct for this case. Since there are no parameters, the baseline score is 4, as the description doesn't need to compensate for missing parameter documentation.

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

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

The description clearly states the verb ('List') and resource ('all New Relic APM applications'), making the purpose immediately understandable. It distinguishes from siblings like 'get_application' (singular) and 'search_entities' (broader scope), though it doesn't explicitly mention these distinctions. The description is specific but lacks explicit sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for listing applications, or compare with siblings like 'search_entities' (which might offer filtering) or 'get_application' (for single applications). Without any usage context, the agent must infer when this tool is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'List all dashboards' but doesn't cover aspects like pagination, rate limits, authentication needs, or what 'all' entails (e.g., archived dashboards). This leaves significant gaps in understanding the tool's 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, direct sentence with no wasted words, making it highly concise and front-loaded. It efficiently communicates the core purpose without unnecessary elaboration.

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

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

Given the tool's low complexity (1 optional parameter) and the presence of an output schema (which handles return values), the description is somewhat adequate. However, with no annotations and minimal parameter guidance, it lacks completeness for safe and effective use, especially regarding behavioral traits.

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

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

The description mentions 'for an account', which aligns with the 'account_id' parameter in the schema. However, with 0% schema description coverage, the description doesn't add details like the parameter being optional (default null) or its format. It compensates minimally, meeting the baseline for low coverage.

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

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

The description clearly states the action ('List') and resource ('dashboards for an account'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_dashboard' (singular) or 'search_entities', which might also retrieve dashboard information, leaving room for ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'get_dashboard' for single dashboards or 'search_entities' for broader queries, nor does it specify prerequisites or exclusions, leaving usage context unclear.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states a read operation ('List'), implying it's non-destructive, but doesn't cover critical aspects like pagination, rate limits, authentication needs, or error handling. For a tool with no annotations, this is a significant gap in transparency.

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

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

The description is a single, clear sentence with zero waste—it directly states the tool's function without unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

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

Given the tool's low complexity (1 parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter semantics, it lacks depth for safe and effective use, such as missing behavioral context or usage guidelines.

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 1 parameter (app_id) with 0% description coverage, so the schema provides no semantic context. The description mentions 'for an application', which loosely relates to app_id but doesn't explain its format, constraints, or where to obtain it. This adds minimal value beyond the schema, aligning with the baseline for low coverage.

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

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

The description 'List deployments for an application' clearly states the verb ('List') and resource ('deployments'), making the purpose understandable. However, it lacks specificity about scope (e.g., all deployments vs. recent ones) and doesn't distinguish from sibling tools like 'list_applications' or 'create_deployment', which would require more detail to reach higher scores.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an app_id), exclusions, or comparisons to siblings like 'list_applications' for broader context. This leaves the agent without clear usage instructions beyond the basic function.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'List all' but doesn't describe return format, pagination, permissions required, rate limits, or error conditions. For a read operation with zero annotation coverage, this is a significant gap in behavioral context.

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

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, directly stating the tool's purpose without unnecessary elaboration.

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

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

Given the tool's low complexity (1 parameter, read operation) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter guidance, it leaves gaps in usage context and behavioral transparency.

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

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

The description mentions 'for an account' which loosely relates to the 'account_id' parameter, but with 0% schema description coverage and only 1 parameter, it adds minimal meaning beyond what the schema title ('Account Id') provides. The baseline is 3 since schema coverage is low but the description partially compensates.

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

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

The description clearly states the action ('List all') and resource ('log parsing rules for an account'), providing a specific verb+resource combination. However, it doesn't differentiate from sibling tools like 'list_alert_policies' or 'list_applications' beyond the resource type, missing explicit sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for usage, or exclusions, leaving the agent to infer usage from the tool name alone among many list-type siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool lists servers but fails to describe key traits: whether it's read-only, how results are returned (e.g., pagination, format), rate limits, or authentication requirements. This is inadequate for a tool with zero annotation coverage.

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

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly, which is ideal for conciseness.

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

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

Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate but lacks completeness. It doesn't explain behavioral aspects like result format or limitations, and while the output schema helps, more context on usage and alternatives would improve it for an AI 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?

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned implicit aspects like default behavior (e.g., listing all servers without filters). Baseline is 4 due to zero parameters.

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

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

The description clearly states the action ('List') and the resource ('servers monitored by New Relic Infrastructure'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_server' (which likely retrieves a single server) or 'search_entities' (which might offer filtering capabilities), missing full sibling distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like retrieving all servers without filtering, nor does it reference sibling tools such as 'get_server' for single-server details or 'search_entities' for filtered searches, leaving usage context ambiguous.

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

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

No annotations are provided, so the description carries full burden. It states 'List all synthetic monitors' but doesn't disclose behavioral traits such as pagination, rate limits, authentication needs, or what 'all' entails (e.g., active only, includes deleted). This is a significant gap for a list operation with zero annotation coverage.

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

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

The description is a single, efficient sentence with zero waste—'List all synthetic monitors'—front-loaded and appropriately sized for its purpose. Every word earns its place, making it highly concise and well-structured.

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

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

Given the tool's low complexity (0 parameters) and the presence of an output schema, the description is minimally adequate. However, with no annotations and siblings that could overlap, it lacks completeness in guiding usage and behavior, though the output schema reduces the need to explain return values.

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 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter semantics, but with no parameters, this is acceptable, aligning with the baseline for 0 parameters.

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

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

The description clearly states the verb ('List') and resource ('synthetic monitors'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_synthetic_monitor' (singular) or 'search_entities', which might also retrieve monitor information, so it doesn't reach the highest 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?

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_synthetic_monitor' (for a specific monitor) and 'search_entities' (which might include monitors), there's no indication of context, prerequisites, or exclusions, leaving usage ambiguous.

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

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

With no annotations provided, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits like whether this is a read-only operation (implied but not explicit), pagination behavior, rate limits, authentication requirements, or what the output contains. For a tool with zero annotation coverage, this is insufficient.

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

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

The description is a single, efficient sentence that states the core purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

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

Given the tool's simplicity (0 parameters, output schema exists), the description is minimally adequate. However, with no annotations and sibling tools present, it lacks context about behavioral traits and usage differentiation, leaving gaps that could confuse an agent when choosing between similar 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 tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to add parameter information, and it correctly implies no filtering parameters by stating 'all users,' making it appropriately complete for this case.

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 resource ('users in the New Relic account'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_user' (singular) or 'search_entities' (broader search), which would be needed for a perfect 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?

No guidance is provided on when to use this tool versus alternatives like 'get_user' (for a specific user) or 'search_entities' (for broader entity searches). The description only states what it does without context about usage scenarios or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the three distinct operations, specifies that 'store' requires an api_key parameter, and mentions security context ('securely in keychain'). However, it doesn't address potential side effects like what happens during 'delete' (irreversible removal) or error conditions.

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 perfectly structured with a clear opening sentence establishing context, followed by a bulleted list of actions with brief explanations. Every sentence earns its place with no redundant information, making it easy to scan and understand.

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

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

Given the tool's moderate complexity (3 parameters, multiple operations) and no annotations, the description does well to explain the core functionality. With an output schema present, it doesn't need to describe return values. The main gap is not explaining the 'account_id' parameter's role, but overall it provides sufficient context for basic usage.

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

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

With 0% schema description coverage, the description compensates well by explaining the 'action' parameter's three possible values and their meanings, and explicitly stating that 'store' requires the 'api_key' parameter. It doesn't mention the 'account_id' parameter, leaving some gap, but provides substantial value 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 clearly states the tool's purpose with specific verbs ('manage', 'show', 'store', 'remove') and resources ('New Relic credentials', 'keychain'). It distinguishes from sibling tools by focusing on credential management rather than monitoring, querying, or other New Relic operations.

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

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

The description explicitly provides usage guidance through the 'Actions' list, specifying when to use each action ('status' for checking, 'store' for saving with api_key requirement, 'delete' for removal). It clearly differentiates between the three distinct operations this tool performs.

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 offers minimal information. It implies a read/write operation ('Execute') without specifying permissions, rate limits, or response behavior. The agent must infer details from the tool name and context, which is insufficient for safe use.

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

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

The description is a single, efficient sentence with zero waste—every word contributes to conveying the tool's purpose. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

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

Given the tool's complexity (executing arbitrary GraphQL queries) and lack of annotations, the description is incomplete. However, the presence of an output schema mitigates some gaps by defining return values. The description should ideally include more about authentication, error handling, or query constraints to be fully adequate.

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

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

Schema description coverage is 0%, so the description must compensate but does not add meaning beyond the schema. It mentions 'custom NerdGraph GraphQL query' which hints at the 'query' parameter's purpose, but provides no details on syntax, format, or the 'variables' parameter. Baseline 3 is appropriate as the schema defines parameters clearly despite lack of descriptions.

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

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

The description clearly states the action ('Execute') and resource ('custom NerdGraph GraphQL query'), making the purpose immediately understandable. It distinguishes itself from sibling tools like 'query_nrql' by specifying GraphQL rather than NRQL queries, though it doesn't explicitly contrast with all siblings.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'query_nrql' or other data retrieval tools in the sibling list. It lacks context about appropriate use cases, prerequisites, or exclusions, leaving the agent with minimal direction.

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

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

No annotations are provided, so the description carries full burden for behavioral disclosure. 'Execute an NRQL query' implies a read-only operation that might fetch data, but it doesn't specify whether this requires authentication, has rate limits, returns paginated results, or handles errors. For a query tool with zero annotation coverage, this leaves critical behavioral traits undisclosed.

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

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

The description is extremely concise with a single sentence 'Execute an NRQL query', which is front-loaded and wastes no words. Every part of the sentence contributes to the core purpose, making it efficient and well-structured for its 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?

Given the tool's complexity (a query execution tool with 2 parameters), no annotations, and an output schema (which helps by defining return values), the description is minimally adequate but incomplete. It states the basic action but misses context like authentication needs, query limitations, or error handling. The output schema reduces the burden, but more behavioral and parametric details would improve completeness.

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

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

Schema description coverage is 0%, so the schema provides no parameter details. The description adds no information about parameters beyond what's implied by the tool name. It doesn't explain what 'account_id' or 'nrql' represent, their formats, or examples (e.g., NRQL syntax like 'SELECT * FROM Transaction'). With 2 undocumented parameters, the description fails to compensate for the coverage gap.

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

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

The description 'Execute an NRQL query' states a clear verb ('Execute') and resource ('NRQL query'), providing basic purpose. However, it lacks specificity about what NRQL is (New Relic Query Language) or what kind of data it queries (e.g., metrics, logs, events), and doesn't distinguish from siblings like 'nerdgraph_query' or 'search_entities' that might also query data. This makes it vague but not tautological.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an account ID), compare to siblings like 'nerdgraph_query' for different query types, or specify use cases (e.g., for real-time analytics vs. configuration queries). Without any context, users must 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 full burden but only states the action without behavioral details. It doesn't disclose aspects like authentication needs, rate limits, pagination (implied by 'limit' parameter), or what the search returns (e.g., structured data vs. raw results), which are critical for a search 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, efficient sentence with no wasted words, making it highly concise. It's front-loaded with the core action, though this brevity contributes to gaps 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?

Given the tool has an output schema (which likely defines return values), the description's minimalism is partially offset. However, for a search tool with 2 parameters, 0% schema coverage, and no annotations, it lacks essential context like search scope, result format hints, or error handling, making it incomplete for effective use.

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

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

Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'query' should contain (e.g., search terms, filters) or how 'limit' works (e.g., max results, default behavior), leaving parameters undocumented beyond the schema's basic types.

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

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

The description states the verb 'search' and resource 'entities in New Relic', which gives a basic purpose. However, it lacks specificity about what 'entities' means (e.g., servers, applications, users) and doesn't distinguish it from sibling tools like 'list_applications' or 'query_nrql', making it vague in context.

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 'list_applications' for specific entity types or 'query_nrql' for more complex queries. The description implies a general search but offers no context or exclusions, leaving usage unclear.

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 mentions the automatic generation of a grok_pattern when not provided, which is useful behavioral context. However, it lacks details on permissions, rate limits, response format, or error handling for a testing tool with 3 parameters, leaving significant gaps in transparency.

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

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

The description is highly concise and front-loaded: two sentences with zero waste. The first sentence states the core purpose, and the second adds critical behavioral context. Every word earns its place, making it easy to scan and understand quickly.

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

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

Given the tool has an output schema (which handles return values) and no annotations, the description is partially complete. It covers the basic purpose and one behavioral trait but misses parameter details and broader context like error scenarios or integration with siblings. For a testing tool with 3 parameters, this leaves room for improvement.

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

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

Schema description coverage is 0%, so the description must compensate. It only addresses 'grok_pattern' by noting it can be omitted for auto-generation, but it doesn't explain 'log_samples' (e.g., format, size limits) or 'account_id' (e.g., purpose, when required). With 3 parameters and low coverage, this is insufficient.

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

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

The description clearly states the tool's purpose: 'Test a log parsing rule against sample logs.' It specifies the verb ('Test') and resource ('log parsing rule') with context ('against sample logs'). However, it doesn't explicitly differentiate from sibling tools like 'generate_log_parsing_rule' or 'create_log_parsing_rule' beyond the testing focus.

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

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

The description provides implied usage guidance: 'If no grok_pattern is provided, it will generate one automatically.' This suggests when to omit the parameter, but it doesn't explicitly state when to use this tool versus alternatives like 'generate_log_parsing_rule' or 'create_log_parsing_rule', nor does it mention prerequisites or exclusions.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure but offers none. It doesn't indicate whether this is a read-only or destructive operation, what permissions are required, whether changes are reversible, what happens to unspecified fields, or what the output contains. For a mutation tool with 7 parameters, this lack of behavioral context is critically inadequate.

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, direct sentence with zero wasted words. It's appropriately front-loaded and efficiently communicates the core action, though this brevity comes at the cost of completeness. Every word earns its place by stating the essential function without fluff.

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

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

Given the tool's complexity (7 parameters, mutation operation, no annotations) and the presence of an output schema, the description is severely incomplete. While the output schema may cover return values, the description fails to address behavioral traits, parameter meanings, or usage guidelines. For a tool that modifies log parsing rules—a potentially impactful operation—this leaves too many gaps for reliable agent use.

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

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

Schema description coverage is 0%, meaning all 7 parameters lack documentation in the schema. The description provides no information about any parameters—not even the required 'rule_id' or what fields like 'grok', 'nrql', or 'lucene' represent. This forces the agent to guess parameter meanings, which is unacceptable for a tool with this complexity.

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 'Update an existing log parsing rule' is a tautology that restates the tool name with minimal elaboration. It specifies the verb ('update') and resource ('log parsing rule') but lacks specificity about what aspects can be updated or how this differs from sibling tools like 'create_log_parsing_rule' or 'delete_log_parsing_rule'. This provides only basic purpose information without meaningful differentiation.

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

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

No guidance is provided on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., needing an existing rule ID), compare it to sibling tools like 'create_log_parsing_rule' or 'test_log_parsing_rule', or indicate appropriate contexts. The agent must infer usage from the tool name alone, which is insufficient for informed selection.

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