Plutus

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

The annotations already indicate a safe, read-only, idempotent operation. The description adds important behavioral context beyond that: cost is always in USD and billed (never amortized), rows include native_cost/native_currency, and native_cost must never be summed or quoted without naming its currency. This is exactly the kind of non-obvious behavior an agent 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 dense but every sentence earns its place: purpose, sibling distinction, USD rule, native fields, and the billed-cost caveat. Key information is front-loaded, and there is no filler or repetition.

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

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

For a read-only two-parameter endpoint with no output schema, the description covers return-value semantics, currency rules, and how it differs from query_costs. The only meaningful gap is the lack of explicit date-parameter guidance, which prevents 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?

The schema descriptions are empty, so the description must explain startDate/endDate. It only says 'over a date range' and never names the parameters, their format, timezone handling, or whether they are effectively required. The agent is left guessing about how to supply these arguments.

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: 'Fetch raw per-service cost entries... over a date range (unaggregated).' It explicitly distinguishes itself from query_costs by calling out that it returns unaggregated individual rows, so an agent can tell them apart.

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

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

It gives an explicit routing directive: 'Prefer query_costs for time-bucketed/aggregated spend — this is for inspecting individual rows.' It further clarifies the lack of a cost_metric parameter compared to query_costs, making the when-to-use decision unambiguous.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful structural context (widgets reference catalog_id; customMetrics/customCharts are inline) and warns about set_dashboard_widgets' replace-all behavior, but does not disclose additional behavioral traits like pagination, authorization, or error characteristics. This is typical baseline value beyond 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 three sentences with no filler. It front-loads the core function, then adds essential structural detail, then closes with a practical usage warning. Every sentence earns its place and the content is easy to scan.

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

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

For a single-parameter, read-only, idempotent fetch operation, this description is complete. It identifies what is returned, how widget references are resolved, and how the tool relates to set_dashboard_widgets. No output schema exists, but the description covers the return contents sufficiently for an agent to know 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 single parameter dashboard_id is fully documented in the schema as 'A shared dashboard id from list_dashboards', giving 100% schema coverage. The description reinforces that the dashboard is org-shared but adds no new parameter-level meaning. Baseline 3 per the rubric 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 ('Fetch') and a specific resource ('one org-shared dashboard's full layout'), then enumerates the exact contents: placed widgets, custom metrics, custom charts, and grid positions. This clearly distinguishes it from sibling list_tools like list_dashboards or list_dashboard_widget_catalog.

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 tells the agent when to call this tool: before set_dashboard_widgets when preservation of existing items is desired, because that tool always replaces everything. This is concrete, actionable routing guidance that names the alternative and the condition for choosing this tool.

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

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

Annotations already mark this as readOnly, idempotent, and non-destructive. The description adds meaningful behavioral detail beyond annotations by explicitly stating that credentials/URLs are never returned, only id/type/name/enabled state. This addresses privacy/security expectations without contradicting any annotation.

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

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

Two compact sentences deliver the essential information: the operation and resource, the practical use case, and the output confidentiality constraint. There is no fluff or repetitive 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 zero-parameter, read-only list tool with complete annotations, the description covers purpose, output shape, security behavior, and a usage scenario. No output schema exists, but the description provides the key return fields. Nothing critical 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?

The tool has zero parameters and 100% schema description coverage, so the input schema already fully documents the empty parameter set. The description compensates by clarifying the output fields (id/type/name/enabled state), which is the relevant semantic information for an agent.

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

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

The description states a specific verb and resource: 'List this account's alert notification channels', enumerating channel types (Slack/Teams/webhook/email). It clearly distinguishes these from sibling tools like list_alert_subscriptions and list_alert_deliveries by focusing on channels themselves.

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

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

The description gives a concrete use case: 'need a channel's id to call create_alert_subscription'. This implies when this tool is useful, though it does not explicitly state when not to use it or name alternatives. The context is clear enough for an agent to select this over 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?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable behavioral details: it only covers recent history, does not include delivery error text, and corresponds to a specific API endpoint. This goes beyond what annotations provide.

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 wasted words. The core purpose is front-loaded, followed by a useful exclusion and an API reference that aids discoverability. 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 read-only list operation with one optional parameter and rich annotations, the description is fully sufficient. It explains what the tool does, what data it surfaces, a key exclusion, and the underlying endpoint, so an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, and the only parameter, limit, is fully described in the schema with default and ordering semantics. The tool description adds no parameter-specific details, which is acceptable given the schema already carries the full burden.

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

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

Description states a specific verb and resource: list recent alert delivery history. The parenthetical clarifies what question it answers (did it fire, did it send successfully), and 'deliveries' clearly distinguishes it from sibling tools like list_alert_channels and list_alert_subscriptions.

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

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

Provides clear context: use this to inspect whether alerts actually fired and sent successfully, mirroring the Alerts page's delivery heatmap. It does not explicitly name alternatives or list when-not-to-use conditions, but the purpose is distinct enough that an agent can infer 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the core safety profile is covered. The description adds useful context about the subscription-to-trigger relationship and the mirrored API endpoint, but does not disclose other behavioral traits such as pagination, account scope, or response shape. This meets but does not exceed the expected bar.

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, information-dense sentence that front-loads the core purpose before adding the trigger detail and API mirror. Every clause earns its place, and there is no fluff.

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

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

For a zero-parameter, read-only list operation with strong annotations and clear purpose, the description is complete enough for an agent to invoke it correctly. No output schema exists, but the tool's name and description adequately convey that it returns subscription relationships without needing detailed return documentation.

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 are no parameter semantics to document. The description references the trigger and alert-channel concepts, which helps the agent understand the domain, and schema description coverage is 100% by virtue of having no properties. Baseline 4 is appropriate for a parameterless tool.

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

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

The description states a specific verb and resource: listing which alert channels are subscribed to which trigger, and enumerates the trigger types (budget spend_threshold, account-wide event_overage/cost_anomaly). This clearly separates it from sibling list_alert_channels, which would list channels themselves rather than subscription relationships.

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 explicit guidance on when to use this tool versus alternatives like list_alert_channels or list_alert_deliveries. The intended use is implied by the resource, but there is no direct statement of conditions, exclusions, or why this should be preferred in a given situation.

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

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

Annotations already mark this read-only and idempotent, and the description adds substantial behavioral context: results are capped at 200 rows, ordered most recent first, account-scoped, and not causal despite correlated_events. It also carefully explains the null-vs-empty-array distinction for driven_by and correlated_events, and the meaning of suppressed and notified=false—valuable information not derivable from annotations or 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 long but every sentence adds necessary operational detail, from high-level purpose to field-level null semantics. It front-loads the core purpose and sibling distinction before diving into output details, and it is organized logically rather than as a random field dump.

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, the description carries the full burden of explaining return semantics—and it does so thoroughly: row cap, ordering, field meanings, suppressed handling, null-vs-empty distinctions, notified=false semantics, and the non-causal interpretation of correlated_events. An agent has enough to interpret and present results 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?

There is only one parameter, days, and the schema already documents its type, range, and default. The description adds that days 'bounds the lookback' and restates default/max, but does not meaningfully go beyond the schema. With 100% schema coverage, this meets the baseline.

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

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

The description opens with a specific verb and resource: 'List detected cost anomalies for this account over a trailing lookback window.' It also distinguishes itself from query_costs by emphasizing that results are the detector's real output, not recomputed raw spend. This makes the tool's identity immediately clear even among many list_* siblings.

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

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

Explicitly says 'Prefer this over eyeballing query_costs for "did anything spike"' and explains why: the detector accounts for day-of-week baselines and an absolute-dollar noise floor. This gives an agent a concrete decision rule for when to choose this tool over a sibling.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description aligns with those. It adds useful behavioral context beyond annotations: only active suppressions are returned, each item carries an expires_at field (null meaning indefinite), and the tool mirrors a REST endpoint while MCP write operations are unavailable.

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

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

Three sentences, each earning its place: definition of a suppression, the key expires_at field, and the MCP limitation. Information is front-loaded and no filler exists.

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-only list tool with no output schema, the description is complete: it defines the items, the filtering to active ones, the expires_at semantics, and the endpoint equivalent. An agent can correctly invoke and interpret this tool without further clarification.

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 parameters, there are no parameter semantics to document. The baseline of 4 applies; the description correctly explains what the result represents so the agent understands the tool's purpose despite having no inputs.

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

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

The description names a specific verb ('List'), resource ('anomaly suppressions'), and scope ('this account's active'). It clearly distinguishes this from sibling tools like list_anomalies by explaining these are human-marked-as-expected signatures that suppress detector findings.

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 provides clear context: this lists suppressions that are currently active and explains what a suppression is. It also states that creating or deleting suppressions is not available over MCP, which sets an explicit boundary, though it does not name alternative tools because none directly competes.

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

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

Annotations already establish read-only/idempotent/non-destructive behavior, and the description adds important non-obvious behavioral detail: budgets carry their own currency, amounts are NOT converted to USD base, and spend/projected values are denominated in status_currency. The warning never to quote figures as dollars without checking those fields is exactly the kind of behavioral caveat that protects an agent from downstream errors.

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 front-loaded with the main action and only adds necessary details: the mirrored endpoint and the critical currency semantics. Every sentence earns its place, and the warning is concise yet highly actionable. It is dense but not 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 zero-parameter read-only list tool with no output schema, the description covers the core return fields, status notions, and the crucial currency pitfall. It does not spell out the exact response container or pagination, but given the simple list nature and the endpoint mirror, the information is sufficient for correct invocation 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?

The tool has zero parameters, so the baseline is 4 and there is no parameter burden to compensate for. The description still adds relevant context by implying the account is fixed ('this account') and mirroring GET /api/accounts/:accountId/budgets, which clarifies how the account is scoped even though no explicit parameter exists.

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

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

The description uses a specific verb and resource: 'List this account's spend budgets' and further specifies the payload (current-cycle status, spend, projected total, states). It clearly separates itself from sibling tools by naming the exact domain: budgets with currency semantics distinct from cost 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 gives a clear context for when this tool is appropriate: listing this account's spend budgets with their current-cycle status. It also indirectly contrasts with 'cost tools' by warning that budget currencies are not converted to USD, which helps an agent avoid misusing this tool for dollar-normalized cost queries. It does not explicitly enumerate sibling alternatives or exclusion conditions.

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

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

Annotations already indicate readOnly/idempotent/non-destructive, so the safety profile is covered. The description goes beyond that by disclosing the underlying source APIs, the monthly snapshot granularity, and the core outputs (utilization, coverage, net savings), which gives the agent useful behavioral context without contradictions.

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

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

The description is concise and front-loaded, starting with the main action and resource. All three sentences contribute useful information: data source, aggregation, metric semantics, and API mirror. It is appropriately sized, though slightly dense and could be trimmed without losing value.

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

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

Given no output schema, the description reasonably explains what the tool returns—utilization/coverage snapshots and net savings vs on-demand—and references the mirrored REST endpoint. It does not describe exact response fields or pagination, but for a parameterless read-only list tool, this is sufficient for an agent to call it correctly.

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

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

The tool has no parameters and schema description coverage is 100%, so the description is not required to explain parameter meaning. The description does add relevant account/month framing, but since there are zero parameters, the 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 uses a specific verb ('List') and identifies a clear resource: Reservation (RI) and Savings Plan utilization/coverage snapshots. It also adds distinguishing context about the data source (AWS Cost Explorer APIs) and aggregation (one snapshot per commitment type per month), but it does not explicitly contrast itself with related siblings like list_savings_recommendations.

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 an agent needs RI/SP utilization, coverage, or savings vs. on-demand snapshots. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, so the guidance is more implicit than explicit.

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

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

The description goes well beyond the readOnly/idempotent annotations by explaining the semantics of each possible cost_basis value, the limitations of estimate sources (no historical billing API, static rates ignoring negotiated discounts), and instructing the agent to qualify estimated totals rather than presenting them as billed spend.

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 efficiently structured: the first sentence states the primary action, and the second adds only essential detail about the cost_basis field. Every sentence contributes meaningfully, with no filler or repetition of annotation values.

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 tool with annotations already covering read-only/idempotent behavior, the description fully explains the domain-specific distinctions that matter when interpreting results. Nothing essential is missing.

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

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

This tool takes no parameters, so there are no parameter semantics to explain. The description correctly focuses on output semantics instead, which is the only meaningful guidance an agent needs here.

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

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

The description names a specific verb (List), a specific resource (cost-source providers enabled for this account), and examples (AWS, GCP, Anthropic). It clearly distinguishes this from sibling list_* tools by focusing on providers rather than tags, alerts, budgets, or other resources.

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

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

The description clearly conveys when to use it: when you need the enabled cost-source providers and their cost_basis meanings. It does not explicitly name alternatives or draw exclusion boundaries, but the provider-specific resource is unambiguous and no contradictory guidance is given.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those: results are restricted to tag/label keys 'actually present' in cost data and 'Only ever populated on grain='service' rows.' This helps the agent understand result scoping without contradicting the 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 compact and front-loaded: it states what is returned, why it is useful, a critical scoping caveat, and the parameter omission behavior in just two sentences. Every clause earns its place and no information is repeated from the schema or annotations.

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 optional-parameter read-only tool with no output schema, this description is complete: it explains the result, the account/data scope, the grain='service' limitation, the use case, and the default behavior of searching all providers. An agent has enough context to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds meaningful nuance by explaining that omitting cost_source_id searches across every enabled provider and that the parameter restricts to a single provider like 'gcp'. This enriches the schema's terse 'Restrict to one provider' text.

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+resource: 'List distinct provider-native tag/label keys actually present in this account's cost data.' It names AWS Cost Allocation Tags, GCP/Hetzner labels, and Azure tags, and clarifies it returns keys rather than values or rules, which distinguishes it from sibling tools like list_cost_source_tag_values.

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 a clear use case: discovering what a 'tags.<key>' cost-tag-rule match could reference before creating one. It also explains the optional parameter's behavior ('Omit cost_source_id to search across every enabled provider'). It does not explicitly list when-not-to-use or name alternatives, but the context strongly implies the right 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool's safety profile is established. The description adds useful context about operating within 'this account's cost data' and being 'provider-native', but it does not disclose additional behavioral details such as pagination, ordering, or limits. This is acceptable for a simple read-only list operation but adds limited behavioral depth.

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

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

The description is a single sentence that front-loads the action and resource, and includes a useful cross-reference to the related keys tool. Every word earns its place; there is no redundancy or filler.

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

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

For a simple read-only list tool with one required and one optional parameter, the description plus schema and annotations are complete. It explains the scope of data, points to the source of valid tag_key values, and the sibling reference resolves ambiguity about where keys come from. No output schema is present, but the return shape of a distinct-value list is reasonably inferable.

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 both parameters are documented in the input schema. The description does not meaningfully add parameter semantics beyond referencing the tag/label concept and provider restriction, which the schema already conveys. Baseline 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 states a specific verb ('List'), a clear resource ('distinct values seen for one provider-native tag/label key'), and explicitly references the sibling list_cost_source_tag_keys to distinguish keys from values. An agent can immediately tell this tool apart from the related 'keys' tool.

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: after you have identified a tag key, you list its distinct values. It points to the sibling tool for key discovery, and the schema reinforces that tag_name must come from list_cost_source_tag_keys. It does not explicitly state when not to use it, but the context is clear enough.

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

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

The annotations already declare read-only and idempotent behavior, and the description goes well beyond them by explaining priority ordering, first-match-wins semantics, the Untagged fallback, split-rule weighting, and the display-label nuance for split rules. It also warns about downstream reallocation, which is essential behavioral context not available from the schema or 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 front-loaded with the core purpose and then delivers a highly relevant warning about split rules. It is longer than average, but every sentence contributes meaningful information; the API mirror reference is mildly extra but not wasteful.

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, the description covers all critical semantics: priority order, first-match-wins, Untagged fallback, split-rule behavior, and pointer to redistribute_bucket. An agent can understand what this tool returns and how to interpret it without additional information.

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 the schema already describes tag_key as one of the tag_keys returned by list_cost_tags. The description reinforces that same relationship but does not add new format or syntax details, so a 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 names a specific verb and resource: listing the actual match rules for one cost-allocation tag_key. It clearly distinguishes this from list_cost_tags by explaining that it shows the dimension-value-to-tag_value mapping and priority order, so an agent can select it correctly.

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 the tool: when you need a specific tag_key's rules, and it points to list_cost_tags for obtaining valid tag_keys. It does not explicitly state when not to use it, but the context is strong enough to route the agent correctly.

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

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

Beyond the readOnly/idempotent annotations, the description explains potentially surprising behavior: each tag_key is locked to a cost_entries grain, rules map dimension values to tag_values, and redistribute_bucket dissolves 'Untagged' spend into other values and affects query_costs output. This is exactly the kind of non-obvious behavior an agent needs to know.

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 dense but efficient: it states the resource, describes the returned fields, gives concrete usage guidance, and explains the redistribute_bucket edge case in three sentences. No filler or repetition of annotation 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?

There is no output schema, so the description carries the burden of explaining return values. It covers what each tag_key includes (grain, rule count, redistribute_bucket) and how it behaves in query_costs, making the tool fully navigable for 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 tool has zero parameters, so there is nothing for the description to add about parameters. The baseline of 4 applies and the description instead uses the space to clarify the returned tag_key metadata and redistribution semantics.

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

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

The description uses a specific verb and resource: 'List the virtual cost-allocation tag_keys defined for this account.' It clearly distinguishes these from source-tag tools like list_cost_source_tag_keys and from list_cost_tag_rules by explaining what kind of object is returned and what accompanies it.

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 tells the agent how to use a listed tag_key with query_costs and breakdown_by: 'tag', which directly supports cross-tool usage. It does not explicitly state exclusions relative to sibling tools, but the intended 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?

Annotations already mark the tool as read-only and non-destructive, and the description adds meaningful scope behavior: it lists only org-shared dashboards, excludes personal dashboards, and explains the ID limitation for personal dashboards. This goes beyond the 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?

Three sentences with no filler. The main action and scope are front-loaded, exclusions are explained, and the final sentence routes to related tools. Every sentence contributes necessary 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 parameterless read-only list tool, the description fully covers what is listed, what is excluded, why the exclusion exists, and how to use the results. Nothing needed for correct invocation 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?

There are zero parameters and the schema documents 100% coverage, so no parameter explanation is needed. The description correctly avoids inventing parameters and instead clarifies the output scope. Baseline 4 is appropriate for a parameterless tool.

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

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

The description names a specific action and resource ('List this account's org-shared dashboards') and clearly differentiates it from personal dashboards and downstream tools. The scope is unmistakable and it distinguishes itself from sibling tools like get_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 explicitly states what is included and excluded, explains why personal dashboards are not addressable, and tells the agent how to use returned IDs with related tools. This gives clear when-to-use and when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so no safety warning is needed. The description adds meaningful behavioral context beyond those flags: the response includes grid_cols and size_bounds, there is no preset chart type, and size_bounds apply per type rather than per catalog_id. This is exactly the kind of non-obvious behavior an agent needs to know.

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 dense paragraphs, each earning its place. The first identifies the resource and the critical limitation (no preset charts). The second explains the useful response fields and how to use them. It is longer than a one-liner, but every sentence adds operational value and the core purpose is front-loaded.

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

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

Even without an output schema, the description covers the return payload's relevant fields: catalog_id, the supported kpi/widget types, grid_cols, and size_bounds. It also gives the cross-reference to create_dashboard for custom_chart specs. Nothing essential is missing for an agent to call the tool correctly and interpret its results.

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

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

The tool has zero parameters, so the description needs to add nothing about inputs. The empty schema fully covers parameter semantics. The description instead usefully explains what the catalog entries reference and how the response fields should be consumed.

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: 'List the built-in ("preset") dashboard widgets available to place with create_dashboard/set_dashboard_widgets.' It clearly distinguishes this catalog from the sibling list_dashboards by framing it as a widget catalog rather than a dashboard list, and it further separates preset entries from custom charts.

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 explains when this tool should be used: to find preset widget catalog_ids before calling create_dashboard/set_dashboard_widgets. It also names the alternative for trend charts ('build one inline with a {"kind": "custom_chart", ...} spec instead of a catalog_id') and tells the agent to consult grid_cols and size_bounds before supplying explicit w/h values.

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

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

Beyond the readOnly/idempotent annotations, the description reveals important behavior: status is only set on successful syncs and never flipped back on failure, so is_overdue is the real staleness signal. This is exactly the kind of non-obvious runtime behavior agents need.

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

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

Three dense sentences, each earning its place: the core purpose, the critical status/is_overdue nuance, and the concrete use case. The API endpoint reference is a useful bonus and does not bloat the description.

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

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

For a zero-parameter, read-only listing tool with no output schema, the description is complete: it states what is listed, which fields are meaningful, how to interpret the key signal, when to call it, and even the REST endpoint it mirrors. Nothing essential for correct invocation or interpretation is missing.

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

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

The tool has zero parameters and the schema is fully covered, so there is no parameter gap to compensate for. The description still adds useful context by clarifying that the listing is account-scoped and that is_overdue is a computed signal based on the connection's effective sync interval.

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: 'List sync health for every cost/event/usage connection this account has.' It enumerates the returned fields and clearly distinguishes this health-monitoring tool from the many sibling list_* and query_* 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 gives explicit guidance on when to use the tool: check it before asserting recent cost/usage data is complete, especially before calling query_costs or query_usage for a recent date range. It also tells agents to rely on is_overdue rather than status, which prevents misinterpretation.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds scoping context ('distinct values ... for one provider') but does not disclose pagination, date-range behavior, or result limits. This is adequate given the annotations but not rich.

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

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

The description is one sentence, front-loaded with the action and target, and includes a practical use case. No repetition of schema fields and 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?

For a read-only list tool with rich annotations, the description plus schema covers core behavior, required parameters, and the shape of results ('distinct values'). It is missing explicit mention of optional date filtering and does not distinguish from list_usage_dimensions, but those are secondary gaps rather than blocking omissions.

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

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

Schema description coverage is only 25%, with only cost_source_id documented. The description partly clarifies dimension via examples and cost_source_id via 'one provider', but it does not explain the optional start_date/end_date parameters, and it does not compensate for the sparsely documented schema.

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

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

The description states a specific verb ('List') and resource ('distinct values ... for a given dimension'), includes provider scoping, and connects to a concrete use case. However, it does not differentiate from the similar sibling list_usage_dimensions, and it lists only five example dimensions while the schema enum allows ten.

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

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

The description explicitly says the tool is 'useful for discovering filter values before calling query_costs', which gives clear when-to-use guidance. It does not mention when not to use it or name alternative tools, so it stops short of a full exclusion-based comparison.

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

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

Annotations already declare readOnlyHint true and destructiveHint false. The description adds useful behavior beyond that: currently only the 'repo' facet is supported, results mirror GET /api/events/facets, and it operates over a date range. It does not detail response shape or pagination, but the read-only annotation lowers that burden.

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

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

Three sentences with no filler: it says what the tool lists, the current facet constraint, and the intended use with query_events. The mention of the mirrored API endpoint is a compact, useful addition rather than repetition.

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

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

For a simple read-only facet listing tool, the description is largely complete: it names the supported facet, clarifies the date-range context, and explains how to use it with query_events. The absence of an output schema is mitigated by the self-explanatory list operation, although source_id semantics and return shape remain undocumented.

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 clarifies that attr currently means 'repo' and connects this to query_events' meta_repo filter, and it suggests start_date/end_date bound the date range. However, source_id is not explained, and date format or requiredness is left implicit.

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 distinct values for a faceted event metadata field, with the concrete current example 'repo'. It clearly distinguishes itself from sibling list_* tools by tying it to event facets, Event Explorer, and query_events.

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 says the tool is useful for discovering query_events' meta_repo filter values before calling query_events, which is a clear when-to-use signal. It does not enumerate alternatives or exclusions, but tthe sibing context makes those mostly unnecessary.

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

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

Annotations already mark this as read-only, idempotent, and non-destructive, and the description adds substantial behavioral detail beyond that: Plutus does not compute recommendations itself, commitment rows represent purchases rather than instance swaps, only one term/payment/lookback variant is surfaced, and currency handling differs between individual recommendations and the total. These are exactly the non-obvious behaviors an agent needs to know.

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 dense but every sentence earns its place: purpose, type taxonomy, commitment-row distinction, single-variant caveat, API mapping, and currency behavior. It is front-loaded with the core action and then layers caveats in a logical order, with 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?

With zero parameters and no output schema, the description carries the full burden of explaining what the agent will receive. It covers the recommendation types, the special shape of commitment rows, the one-variant limitation, and the currency semantics. Nothing essential is missing for an agent to invoke and interpret this 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?

There are no input parameters, so the description has no parameter semantics to explain; baseline 4 applies. It does add useful semantics about the returned `type` enum and the contents of `detail`, which helps with output interpretation even though no output schema is provided.

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

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

The description opens with a specific verb and resource: list active cost-reduction recommendations for this account. It clearly distinguishes the tool from siblings by stating these recommendations come from each provider's own engine (AWS Cost Explorer, Azure Advisor, GCP Recommender), not from Plutus itself. The detailed `type` taxonomy further removes ambiguity about what the tool returns.

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 strong contextual guidance for interpreting results, especially the caveat that only one commitment variant is surfaced and should not be treated as exhaustive. It does not explicitly name alternative sibling tools or state when not to use this tool, but the specificity of the semantics effectively routes an agent to this endpoint for provider-computed savings recommendations.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description goes beyond annotations by stating account scoping, explaining the meaning of `next_period_label`, mirroring the REST endpoint, and explicitly noting that create/edit operations are not exposed.

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

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

Three tight, purposeful sentences. The first sentence front-loads the tool's purpose and return contents, the second clarifies a field's meaning, and the third gives endpoint context and an important limitation. No filler or redundancy.

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

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

For a parameterless, read-only list operation with no output schema, the description is complete: it states what is returned, the account-level scope, the meaning of a key field, and what is not possible over MCP. The annotations cover safety, so no additional behavioral disclaimers are needed.

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?

There are zero input parameters and the schema covers 100%, so the baseline of 4 applies. The description adds a small bonus by clarifying a response field (`next_period_label`), which is helpful despite there being no input parameters to document.

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 ('this account's scheduled cost digests'), and immediately clarifies the account scope. It also names the concrete fields returned, which clearly distinguishes this tool from the many list_* siblings that target different resources.

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

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

The description clearly implies when to use this tool: whenever the agent needs the account's scheduled report definitions. It also explicitly warns that creating/editing is not available over MCP, preventing misuse, though it does not name an explicit sibling alternative.

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

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, so the description is not required to restate safety. It adds valuable behavioral context: recommendations are only listable over MCP, accepting/dismissing is UI/REST-only, and each item includes estimated_monthly_spend_cents. This goes beyond the structured annotations without contradicting them.

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 information-dense but tightly structured. The first sentence states the tool's purpose and the two main recommendation sources; the second sentence explains the key output field; the third clarifies API mirroring and MCP limitations. Every clause earns its place without padding.

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

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

With no output schema present, the description carries the burden of explaining return values. It explains the central returned field and the overall suggestion types, which is sufficient for a no-input list tool. It stops short of describing the full shape of a recommendation object (e.g., tag_key, tag_value, source), but the lack of parameters and the read-only annotations make this a minor omission.

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 there is no parameter semantics burden. The description still adds meaning to the output by defining the key returned field, estimated_monthly_spend_cents, as USD-base spend that would newly be covered. This satisfies the 0-parameter baseline of 4.

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

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

The description opens with a specific verb and resource: "List suggested cost-allocation tag rules this account doesn't have yet." It further clarifies what kinds of suggestions are included, distinguishing itself from tools like list_cost_tags and list_cost_tag_rules by emphasizing recommendations that are not yet present.

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 useful context for when to use this tool: when seeking new tag-rule suggestions, including high-spend 'Untagged' values or provider-native tags. It points to list_cost_tags as a related sibling and explicitly notes that accept/dismiss actions are not available over MCP, preventing misuse. It could be stronger with an explicit when-not-to-use statement against list_savings_recommendations, but the scope 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?

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context by revealing the account-level scope, the included fields (members and tag_value), and the downstream budget relationship. No contradiction with annotations.

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

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

Two tightly written sentences lead with the action and resource, then add the crucial budget-scoping relationship. Every sentence earns its place; there is no filler or repetition.

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

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

For a parameterless, read-only list tool with no output schema, the description is complete: it states the scope, the returned data, and an important use case. An agent can understand when and why to invoke it without further documentation.

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 there is no parameter schema to document. The description still adds context by noting the account scope and the mirrored endpoint, making the tool's implicit input clear. This meets the baseline for a parameterless tool.

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

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

The description states a specific verb ('List'), a clear resource ('this account's teams'), and the exact data returned (members and cost-tag tag_value). It also distinguishes itself from the many sibling list_* tools by focusing on teams and their role in team-scoped budgets.

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 connects this tool to a concrete use case: resolving team IDs for create_budget calls with scope_type: 'team'. It does not state when not to use it, but since no sibling tool lists teams, the usage context is sufficiently 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?

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description only needs to add context around the data access. It adds that the tool returns saved, account-scoped metric definitions rather than live computations, which is useful and does not contradict the 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 three sentences long, starts with the core action, and uses examples and backticked field names efficiently. It is slightly dense with domain terminology, but every sentence contributes to understanding what is listed and what to do next.

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 tool with no output schema, the description does a good job of explaining the returned metric structure and the relationship to query_unit_costs. It could more explicitly state the output shape (e.g., an array of metric definitions), but the current text is sufficient for correct invocation and 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 input schema has zero parameters, so the baseline is 4. The description adds meaningful context by explaining the fields of the returned metrics — numerator_scope, denominator_metric, denominator_scale — and pointing out that an id feeds into query_unit_costs. This helps an agent interpret results, even though these are not input 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 opens with a specific verb and resource — 'List this account's saved unit-economics metrics' — and immediately defines what those metrics are with concrete examples. It also distinguishes itself from the sibling query_unit_costs by noting that an id would be passed there for computation.

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 a clear pointer to query_unit_costs for computing a metric over a date range, which implies the intended division of labor. It does not explicitly state exclusions or exhaustive when-to-use guidance, but the context is clear enough for an agent to pick the right tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds value beyond that by disclosing the output shape (raw value paired with label), the label fallback logic for external_customer_id, and that it mirrors a GET endpoint. This is meaningful behavioral context without contradicting 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?

Three efficient sentences with the core purpose front-loaded, followed by output details and endpoint reference. Every sentence earns its place; there is no filler or repetition of schema fields.

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

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

For a simple list operation with strong annotations and only three params, the description covers purpose, when to use it, output entry structure, and label semantics. It does not discuss pagination or response limits, but that is not critical for a discovery-oriented list tool and the description is otherwise complete enough to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the dimension enum values and the role of start_date/end_date as a date range, but it does not specify date formats, optionality, or edge-case behavior. The parameter names are self-explanatory and the description adds enough for basic invocation, but gaps remain.

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: listing distinct values for a usage dimension over a date range. It also distinguishes the tool from query_usage by stating it is useful for discovering filter values before querying, and the endpoint mirror adds precise grounding. This clearly differentiates it from sibling list tools like list_dimensions.

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 explicit context: use this to discover filter values before calling query_usage. It does not enumerate when-not-to-use cases or name alternatives like list_dimensions, but the intended workflow is clear and sufficient for an agent to select it appropriately.

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

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

Annotations already declare read-only and idempotent behavior, so the description is free to add critical behavioral nuance: estimate-vs-invoiced semantics via cost_basis, quantity/unit/cost_per_unit caveats, currency conversion, coverage.complete_through lag, and lagging_sources. These go well beyond the structured annotations and materially change how a caller should interpret results.

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 every paragraph earns its place by addressing a distinct interpretation risk: what the tool returns, how to treat estimated costs, and how to interpret incomplete coverage. It is front-loaded with the core action and then layers caveats in a logical order without repetition.

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

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

For a tool with 18 parameters, no output schema, and a complex cost-reporting domain, the description is exceptionally complete. It explains currency, estimate status, unit semantics, coverage lag, differences from sibling tools, and unsupported combinations. An agent has enough context to invoke it correctly and interpret results responsibly.

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 meaningful parameter-level meaning, especially around cost_metric: amortized only differs for AWS/FOCUS/Azure, is unavailable before 2026-08-04, and cannot be backfilled. It also clarifies secondary_breakdown_by pairing constraints and the tag_key relationship, which the schema alone does not fully 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?

Opens with a specific verb and resource: 'Query time-bucketed spend for this account,' and immediately distinguishes itself from related tools by naming the dimensions it can break down by, the tag path, and the mirrored endpoint. It also contrasts behavior with query_unit_costs and get_cost_entries, so an agent can tell sibling tools apart.

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 explicit when-to-use and when-not-to-use guidance: it references list_cost_tags for tag keys, notes that amortized data is 'Not supported by get_cost_entries,' and explicitly contrasts its row-truncation behavior with query_unit_costs. It also warns about unsupported secondary_breakdown_by pairs, which prevents misuse.

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?

Goes well beyond the readOnly/idempotent/non-destructive annotations by disclosing operational behavior: results are capped at 5000 rows, ordered oldest-first, can be silently truncated without date scoping, and include no cost figure. This is exactly the kind of non-obvious behavior an agent needs to invoke the tool safely.

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 tight sentences, each earning its place: purpose with source examples, critical scoping caveat, cost distinction, and API reference. No filler or redundant restatement of schema fields.

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 query tool with a fully self-describing schema, the description covers source breadth, filtering expectations, result limits, ordering, truncation risk, and the lack of cost data. The 'Mirrors GET /api/events' reference also gives the agent an external anchor for return behavior without an output schema.

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

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

The schema already documents all six parameters with 100% coverage, so the baseline is 3. The description adds meaning for start_date/end_date by explaining why they are essential and linking them to truncation and ordering behavior, which the schema 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?

States a specific verb and resource ('Query this account's business-event timeline'), enumerates supported event sources, and differentiates itself from cost queries by noting it 'Carries no cost figure.' It also ties itself to the Cost/Event Explorer charts and the GET /api/events endpoint, making its scope unmistakable.

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?

Explicitly instructs the agent to 'Always scope with start_date/end_date' and explains the consequences of not doing so: no pagination, 5000-row cap, and silent truncation. It also provides a clear when-not signal ('Carries no cost figure') and indicates this is the event-timeline query rather than a cost query.

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 annotations already declaring readOnlyHint and idempotentHint, the description adds substantial behavioral context: null unit_cost means missing data rather than zero, series truncation at coverage.complete_through is normal, lagging sources lower unit costs, and an empty rows with numerator_status.available=false means a broken metric, not zero spend. These caveats go well beyond the annotations and materially prevent misinterpretation.

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 every paragraph earns its place by addressing a distinct, high-stakes misinterpretation risk: null semantics, missing newest data, lagging sources, broken definitions, allocation policy, and per-customer caveats. It is front-loaded with the core purpose and the most critical null warning immediately after.

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

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

Given there is no output schema, the description carries the full burden of explaining the response—and it does: return fields, null meaning, coverage block, numerator_status, per-customer row structure, and currency conventions. It also links to list_unit_metrics for ID resolution and list_cost_tags for allocation policy. Nothing essential for correct invocation and interpretation 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 input schema has 100% description coverage for all four parameters, so the baseline is 3. The description does not add much parameter-level detail, though it enriches the meaning of the result (unit_cost, denominator_label, coverage) and references list_unit_metrics for unit_metric_id. It relies on the schema for parameter syntax, which is acceptable given full 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 opening sentence states a precise verb ('Compute'), a specific resource ('one of this account's saved unit-economics metrics'), and a distinguishing formula ('cost divided by business units'). It also names list_unit_metrics as the source of metric IDs, which separates it from siblings like query_costs or query_usage.

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 establishes when the tool is appropriate: for saved unit-economics metrics over a date range, and it points to list_unit_metrics for valid IDs. It also warns about differences from raw dimension totals and amortized cost, which implies alternatives without explicitly saying 'use query_costs for raw spend.' This is clear context but lacks a direct when-not-to-use statement.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds meaningful behavioral context beyond that: the data is pushed/synced backend telemetry, `quantity` must never be treated as currency, and external_customer_id breakdown only applies 'when the pushed rows carry one.' This is useful, though it does not cover response pagination or full return shape.

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

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

The description is compact and front-loaded: the first sentence states the tool's core purpose and scope, followed by a necessary money-handling warning, a breakdown note, and an API mirror reference. Every sentence contributes valuable information 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?

Given seven optional parameters, no output schema, and many sibling tools, the description does a strong job covering purpose, raw/cost distinction, currency caveat, and optional breakdown. It still leaves a small gap around what the query response contains beyond `quantity` and any pagination behavior, but the description plus schema and annotations are sufficient for correct tool selection and basic 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 71%, so most parameters are already documented. The description supplements this by explaining the semantic framing ('raw count, no currency') and the external_customer_id breakdown condition, which helps for breakdown_by. However, it does not add meaningful guidance for filter_external_customer_id or clarify the meaning of the two undocumented parameters beyond their inferable names.

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

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

The description names a specific verb ('Query') and resource ('time-bucketed usage telemetry'), and narrows the scope to data 'this account's own backend has pushed or synced in.' It also distinguishes itself from related unit-economics tools by saying the data is 'inspected directly rather than through a pre-defined ratio' and warns that `quantity` is a raw count, not money.

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 positions this tool as the raw-data counterpart to cost or ratio metrics, even pointing to list_unit_metrics/query_unit_costs as related alternatives. It does not explicitly enumerate when to prefer query_events or query_costs, but the 'raw count with no currency' warning and 'rather than through a pre-defined ratio' phrase provide usable routing context.

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