Ticker: Live Event Ticket Market

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

Annotations already establish the mutation/safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds genuine behavioral context: what constitutes a Match, that delivery happens by email or to a destination, and that a Digest is optional. It omits plan-limit refusals (Digest count) and that predicate validation is server-side, but the core create-and-deliver behavior is disclosed.

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 zero filler. The purpose and the resource definition are front-loaded, and the routing guidance follows immediately, so 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 high-complexity, 12-parameter create tool with nested objects and no output schema, the description is thin on its own, but the exceptionally rich schema (predicate DSL, digest, triggers) carries the parameter burden and the description covers purpose and routing. The main residual gap is that, with no output schema, it does not say what a successful create returns (e.g. the new View id).

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 83% (>80%), so the schema already documents the 12 parameters in depth. The description only gestures at the channels/digest parameters ('sends it by email or to a destination, with an optional Digest') without adding syntax beyond the schema. Baseline 3 is correct.

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+resource ('Creates a View') and defines the resource in domain terms: a saved predicate that records a Match when an event enters it, with email/destination delivery and an optional Digest. It also distinguishes itself from siblings by naming screen_events (test the predicate) and update_view (change an existing View).

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?

Gives explicit when-to-use alternatives: 'Try the predicate with screen_events first; use update_view to change a View that exists.' This both routes away from the wrong tool (update_view for existing Views) and prescribes a safe pre-flight step, leaving nothing to inference.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=false, so the safety profile is covered. The description adds the one piece of context annotations cannot express, that the endpoint is retired, but it does not say what happens if it is invoked anyway (error, no-op, or success).

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

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

One short sentence, front-loaded with the critical word 'Removed:', with zero filler. It is efficient, though the brevity comes at the cost of stating an actual purpose.

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

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

For a retired single-parameter tool, the essential message (do not use; manage destinations in the web app) is present, but the definition omits what a call returns or whether the tool still executes, and points to no sibling tool.

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

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

With 100% schema description coverage, the single destination_id parameter is fully documented in the schema, including its source (list_destinations). The description adds nothing about the parameter, which is acceptable at baseline but no better.

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 never states what the tool does; it announces that the tool was removed and redirects the user to the Ticker web app. It effectively negates the name/title rather than clarifying the operation, so an agent cannot tell from the text whether the tool is still callable.

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 does give a routing instruction for where destination management now lives (Settings in the web app), which is actionable. However, it never references the relevant siblings such as update_destination or list_destinations, so the agent gets no tool-level 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 declare destructiveHint=true and readOnlyHint=false, so the safety profile is partly covered. The description goes beyond them by disclosing the cascade ('all its Matches'), irreversibility ('it cannot be undone'), and the softer alternative. It doesn't discuss permissions or confirmation requirements, but the key behavioral risk is well communicated.

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: destructive consequence front-loaded, alternative second. Every clause earns its place with no redundancy.

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

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

For a destructive single-param delete with no output schema, the description covers consequence, irreversibility, and the safer path. Nothing needed to invoke it correctly 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?

Schema coverage is 100% with a single required param (view_id) already documented including its source ('from list_views'). The description adds no parameter-level detail, so baseline 3 is appropriate when the schema does the work.

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 ('Deletes a saved View'), plus the scope of the deletion ('all its Matches'). It is clearly distinguishable from siblings like update_view and list_views without opening either schema.

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

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

Explicitly names the when-not case and the alternative: 'To stop a View for now and keep its Matches, use update_view with enabled false instead.' The agent is routed to the correct sibling with the exact parameter value to 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds the meaningful context that the tool is superseded, but says nothing about whether it still functions, whether it is an alias with identical results, or whether it will be removed.

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

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

A single sentence with zero waste, front-loaded with the decisive word "Renamed" so the agent knows immediately this is a redirect.

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 legacy stub with a fully documented schema and no output schema, the description supplies the one thing an agent needs: where to go instead and how to call the replacement. It omits any statement about this tool's continued behavior, which is the only remaining gap.

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

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

Schema description coverage is 100%, so the schema already documents all six filters (name, limit, state, country, capacity_min/max) with examples and defaults. The description adds only the venue_name/name mapping hint, which is marginal; 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 never states what find_venue does; it only announces a rename and names the successor tool. An agent can infer the resource (venues) from the target parameters, but the tool's actual purpose is left implicit rather than stated as a verb+resource.

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 routes the agent to get_venue_schedule and even specifies the required view ("venues") and field (venue_name), which is unusually actionable. It stops short of saying whether this tool should never be called or only as a fallback, and the venue_name/name field naming differs from this schema's own 'name' parameter.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful behavioral context: it enumerates what is returned (plan, dates, remaining quota/limit per allowance) and the 'call it once' guidance implies a stable, cacheable, side-effect-free read. It stops short of stating auth requirements, but nothing contradicts 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?

Two sentences, zero filler, with the primary purpose front-loaded and the routing guidance second. Each 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?

There is no output schema, so the description must sketch the return value on its own, and it does: plan identity, plan dates, and remaining quota/limit per allowance. For a zero-parameter, non-destructive read that is sufficient, though it could say slightly more about what 'each quota and limit' comprises.

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 takes zero parameters, so the baseline is 4 and there is no parameter syntax the description needs to compensate for. No param-level value could be added 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?

States a specific verb and resource ('Shows the caller's plan, its dates and how much of each quota and limit is left') and implicitly distinguishes itself from the many list_* siblings by naming them as alternatives for item-level data. An agent can identify this as the plan/quota probe without opening a schema.

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

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

Gives explicit when ('Call it once before you say which plan includes a reading') and when-not/alternatives ('Use list_views, list_watchlist or list_destinations for the items behind a count'), naming three concrete sibling tools. Nothing is left to inference.

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

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: it discloses that a range call returns one row per date, that the tool now consolidates two former tools, and a do-not-fill constraint tied to days_missing. It stops short of describing pagination or output volume.

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?

Front-loaded with the core purpose, and each sentence carries routing or mode information rather than filler. It is dense and the 'never fill a date listed in days_missing' clause is cryptic since that field is never defined, which slightly hurts clarity without adding much length.

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

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

With no output schema, the description reasonably compensates by describing the return shape (full row vs. headline set, one row per date) and the sale-window fields. The gap is that days_missing is referenced as if defined elsewhere but is unexplained, leaving one behavioral rule ambiguous.

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 schema already documents range, columns, and event_id. The description adds meaning beyond it by explaining that range yields one row per past date and by clarifying columns omission behavior (full row now vs. headline signal set with range), which is not stated in the schema.

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

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

States a specific verb+resource with enumerated scope ('prices, inventory, demand, their recent changes, prediction markets, and its presale and public on-sale windows'). It explicitly differentiates from siblings (screen_events, get_event_chart, research_event) and notes it replaces get_event_analytics_history and get_event_sale_windows, so an agent can place it precisely without opening a schema.

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

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

Gives explicit routing: 'Use screen_events to compare many events, get_event_chart for the price series, research_event for why a number moved.' It also states the condition that selects history mode ('Pass range ... to test a signal against what came next') and a negative constraint ('never fill a date listed in days_missing').

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds almost nothing behavioral: it does not say whether calls to this alias still succeed, whether it is deprecated or will be removed, or whether it errors. 'Renamed' implies a working alias but leaves the agent guessing.

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

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

One short, front-loaded sentence with no filler — the alternative tool is stated immediately. It is perhaps too terse for the amount of behavioral uncertainty it leaves, but nothing is wasted.

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 three-parameter read tool with annotations, the mechanical information is available elsewhere. What is missing is the one thing only the description can supply: whether this alias still functions, whether it is deprecated, and what happens to the caller if they use it instead of get_event_analytics.

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 itself is unusually detailed (range enum with default and boundedness, event_id format and legacy-id expiry, columns semantics). The description's 'with range' adds nothing beyond that, so the 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 never states what the tool does — it only announces a rename to get_event_analytics. An agent cannot infer from it that this retrieves historical event analytics rows; the title is the only hint at the resource. It does, however, distinguish itself from get_event_analytics by marking itself as the superseded name.

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

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

It names a specific alternative (get_event_analytics) plus the condition that selects it ('with range'), which is exactly the routing an agent needs. It stops short of stating when this tool itself should still be used, or whether it should never be used at all.

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 the safety profile (readOnly, non-destructive, closed world), so the description is free to add what they can't: it discloses that output is a summary by default and that rows=true yields truncated data 'cut to fit with a pointer to read on'. That truncation/pointer behavior is genuinely useful beyond the structured fields, though it says nothing about permissions or rate limits.

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, front-loaded with the combined scope and followed by the routing rule; the middle enumeration of summary contents is dense but earns its place. Slightly list-heavy, but 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?

There is no output schema, and the description does sketch what comes back (headline prices, listings, demand, series start/end/bottom/peak, top sections) plus the summary-vs-rows tradeoff, which is adequate. The full row shape still depends on the schema text, so it stops short of complete.

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

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

Schema description coverage is 100%, so the schema already defines rows, parts, range and event_id in detail; baseline is 3. The description adds only a light restatement ('Pass rows true for each part's rows') and never mentions the range or parts parameters, so it does not meaningfully exceed the schema.

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

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

States a specific verb+resource (read one event's price series, analytics and sections in a single call) and explicitly contrasts itself with the three sibling tools that read one part in full. An agent can distinguish it from get_event_chart/analytics/sections without opening any schema.

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

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

Gives an explicit selection rule: 'Use it when you need more than one of these on one event', then names the alternatives and their condition ('read one part in full'). No inference required.

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/destructiveHint=false, but the description goes well beyond them: it states the never-mix-primary-and-resale constraint, explains that demand shows levels over a window rather than tickets bought that day, and notes the default render behavior (data-only via render:false). It also discloses deprecation/replacement behavior, which the annotations cannot express.

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?

Front-loaded with the core behavior in the first sentence and organized around metric modes before routing to alternatives. It is dense and jargon-heavy but every clause carries routing or semantic information rather than 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 five-parameter chart tool with no output schema, the description covers the essential context: metric semantics, source rules, response shape (rows per date, image vs data-only) and sibling routing. The per-source series envelope is only described inside the schema, so the description alone is not fully self-contained, but it is sufficient to call the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3, and the description largely restates what the schema already documents (price as default metric, vs as default source, the primary/resale distinction, the never-mix rule). It adds framing but little syntax or format detail beyond the structured fields.

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

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

States a specific resource and shape ('One event over time, one row per date') and then splits the two modes into distinct meanings: metric price = prices/inventory from one source, metric demand = interest and sales levels. It also explicitly names the tools it supersedes (get_event_price_chart, get_event_demand_chart), so an agent can disambiguate against siblings immediately.

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?

Gives explicit alternatives and the conditions that select them: use get_event_sections_live with view series for one section in finer steps, and get_event_analytics with range for other numbers over time. It also flags this tool as the replacement for two deprecated siblings, removing any ambiguity about which chart tool to call.

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, so the safety profile is covered. However, for a renamed tool the single most important behavioral fact is missing: whether the tool still executes and returns data, or is deprecated and fails. Nothing is said about the response format, the rendered-PNG behavior, or lifecycle status.

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

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

A single short sentence with zero padding and the actionable instruction front-loaded. The terse 'Renamed:' fragment is slightly cryptic (renamed from what, and is this name still valid), but nothing is wasted.

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

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

For a simple 3-param read tool with 100% schema coverage, no output schema, and safety annotations, the description covers the migration path adequately. What it omits is the deprecation lifecycle detail an agent needs to decide whether invoking this tool is safe.

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 params (event_id, range, render) are fully documented in the schema, so baseline 3 applies. The description adds no parameter detail beyond the schema, though it does name the 'metric' value the replacement tool expects.

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 never states what the tool does; the purpose ('demand chart for an event') is only inferable from the name/title. It does usefully identify the tool as a renamed alias and points to its replacement, which helps an agent place it among siblings, but as a statement of purpose it is a redirect notice rather than a description.

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

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

It explicitly names the alternative to use instead (get_event_chart) and the exact parameter that reproduces this tool's behavior (metric "demand"), which is precisely the routing information an agent needs. It stops short of stating whether calling this tool is still supported, errors out, or silently redirects.

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, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description's one behavioral contribution is disclosing deprecation/renaming, which is genuinely useful context. It says nothing about pagination, limits, or what a call to the stale name would do.

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

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

A single short sentence that front-loads the critical fact (renamed) and immediately names the replacement and its argument. There is no filler whatsoever.

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 deprecation/redirect stub, the essential information an agent needs — don't use this, use that instead with this argument — is present. It would be marginally better if it stated whether the old name still resolves, but nothing critical 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?

Schema description coverage is 100%, so all six parameters (limit, width, cursor, section, event_id, occurrence) are already documented in the schema, including the non-obvious width and occurrence semantics. The description adds no parameter detail at all, so the 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 never states what this tool does or returns; it only announces that it was renamed. An agent can infer it was once about GA history from the name, but the text itself provides no verb+resource statement. It does, however, distinguish itself as a dead end relative to 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?

It explicitly redirects to a named sibling (get_event_sections_live) and even supplies the selecting parameter (view "ga"), which is exactly the when-to-use guidance an agent needs. It stops short of saying whether this tool still works or what happens if called.

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 state readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds nothing about deprecation status, whether calling it still functions, or what happens if an agent invokes it, which is the key behavioral fact for a renamed tool.

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

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

One short, front-loaded sentence with no wasted words. It is concise, though it omits essential information.

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

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

For a renamed/deprecated tool with four parameters and no output schema, the description is inadequate. It does not say whether this tool is still callable, whether it forwards to get_event_chart, or what the replacement's required parameters are (e.g., that get_event_chart also requires event_id and a metric argument).

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

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

Schema description coverage is 100%, so the schema already fully documents event_id, range, render, and source. The description adds no parameter semantics beyond the implicit equivalence to get_event_chart(metric="price"). Baseline 3 is appropriate.

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

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

The description only says the tool was renamed and points to get_event_chart with metric "price". It does not state what the tool actually does (produce a price chart for an event), so an agent unfamiliar with the rename has to infer purpose from the name alone.

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

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

It implicitly tells the agent to prefer get_event_chart with metric "price" instead of this tool, which is useful routing. But it gives no explicit when-to-use/when-not guidance and does not address whether this tool still works or is deprecated.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds the rename fact but says nothing about whether invoking it aliases the new tool, fails, or returns a deprecation error. It neither contradicts the annotations nor enriches them much beyond the routing note.

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

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

A single short sentence with zero filler, front-loading the essential fact (renamed) and the destination tool plus arguments. Nothing is padded or repeated.

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 renamed/deprecated alias, the most important missing context is whether the tool still works and what happens on invocation; the description omits this. It does supply the replacement target and exact columns, which is the essential routing info, but an agent cannot tell if calling it is safe or futile.

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?

Only one parameter exists and schema description coverage is 100%, so the schema fully documents event_id ('The event to read.'). The description adds no parameter meaning, which lands at the baseline for a fully-covered single-param 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 never states what the tool does; it only announces a rename and points at a replacement. The name suggests 'sale windows' but the text supplies no verb+resource statement of behavior. It is closer to a redirect stub than a purpose statement, though it does distinguish itself from siblings by declaring itself superseded.

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 names the alternative (get_event_analytics) and even the exact columns to request (["presales","onsale"]), which is actionable routing. However it never says whether this tool still functions, returns an error, or should be avoided entirely, leaving the 'when to use this vs. that' question half-answered.

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 the safety profile (readOnlyHint true, destructive false), so the bar is lower, but the description adds only the fact that the tool is renamed. It discloses no behavioral traits such as pagination, truncation, or response shape beyond the redirect.

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

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

A single front-loaded sentence with zero waste, which is appropriate for a deprecation notice. It is not padded or buried, though it is terse to the point of omitting any statement of the tool's function.

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 renamed alias, the correct agent behavior is to redirect rather than invoke, and the description accomplishes that despite 11 parameters and no output schema. Nothing further is required for an agent to act correctly, since it should not call this tool at all.

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% across 11 parameters, so the schema carries the semantics and baseline 3 applies. The description's only parameter-adjacent claim references a view "history", which does not correspond to any value in the scope enum (seat/section/event) — it is a reference to the successor tool's parameter, not this one's.

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 never states what the tool does beyond the name; it only announces a rename. It does effectively differentiate from siblings by pointing to get_event_seats with view "history", so an agent knows this is not the tool to pick. Vague on purpose, clear on routing.

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 tells the agent to use get_event_seats with view "history" instead, which is precisely the when/when-not guidance needed for a deprecated alias. The named alternative and the condition selecting it are both stated, leaving nothing to inference.

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

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

Annotations already declare readOnly/non-destructive, and the description adds real behavior beyond them: 'read count, not the list length', 'republish marks a price change, not a sale', page/truncation behavior with next_cursor, and that all_in is not served with `at`. These are non-obvious semantics an agent could not infer from annotations or schema alone.

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

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

Front-loaded with the live/recent/history modes, then the alternative and the replacement note; no sentence is wasted for a 14-parameter tool. The semicolon-chained clauses are dense and border on run-on, which costs it the top mark but keeps it compact for the complexity involved.

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 high-complexity multi-mode read tool with no output schema, the description covers mode selection, scoping, pagination/truncation, cross-parameter constraints, the sibling alternative, and the consolidation of four tools. Essentially nothing needed to invoke it correctly 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?

Schema coverage is 100% with 14 well-documented params, so the baseline is 3, but the description adds interaction semantics the schema does not: how `view`, `scope`, `rows`, `at` and `cursor` combine (e.g. rows turning a per-section summary into per-seat history paged 25 at a time). It stops short of fully mapping every parameter, but meaningfully exceeds the schema.

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

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

States a specific verb (get) and resource (seats at one event) and enumerates the three operating modes (live/recent/history) with scope. It explicitly distinguishes itself from get_event_sections_live and from the three tools it replaces, so an agent can place it without opening the schema.

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

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

Each view mode is given a selection condition ('live: open now', 'recent: came on or off sale in the last minutes', 'history: one seat over time'), and the alternative get_event_sections_live is named with its reason. It also states it replaces get_event_seats_live, get_event_seats_recent and get_event_seat_history, which directly resolves sibling ambiguity.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. Beyond the rename notice, the description adds no behavioral context: it doesn't say whether calling this alias returns the same payload as get_event_seats, whether it is deprecated-but-working or removed, or how the parameters map to the replacement's view argument.

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

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

A single front-loaded sentence with zero filler, and the actionable instruction (the replacement call) comes first. Nothing is padded or repeated.

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 rename stub, telling the agent the successor call is the essential information, but the description omits whether the alias still works and how this tool's four parameters carry over to the replacement's view argument. No output schema exists, so return-value omission is acceptable.

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 four parameters (at, limit, all_in, event_id) are thoroughly documented in the schema, including interactions like all_in not being served with at. The description adds nothing about parameters, so the 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 does not state what this tool does in its own right; it only says it has been renamed and points to get_event_seats with view "live". The redirect is informative and distinguishes it from siblings like get_event_seats_recent or get_event_seats_history, but the purpose is conveyed indirectly via the replacement rather than directly.

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?

"use get_event_seats with view 'live'" explicitly names the alternative and the condition that selects it, which is exactly what an agent needs to route correctly. It stops short of a 5 because it never states whether this alias still functions, errors out, or should never be called.

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, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds no behavioral context at all: no mention of deprecation semantics, whether calling it still works, or what it returns.

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

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

A single short sentence with zero padding, and the redirect is front-loaded. It is appropriately sized for a tombstone notice, though it is so terse that it borders on under-specification.

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 redirect stub it covers the essential point (use get_event_seats with view "recent"), and the schema and annotations handle the rest. It never explicitly states the deprecation or whether this alias still functions, leaving a gap an agent must infer.

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

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

Schema description coverage is 100%, so all five parameters (limit, all_in, minutes, section, event_id) are already documented in the schema. The description only references the "view" argument of the successor tool, adding nothing for this tool's own 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 does not state what the tool does; it only announces a rename and points to get_event_seats with view "recent". An agent learns this is a superseded alias, but nothing about the resource or operation (recent seat moves) is conveyed beyond what the name/title already imply.

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 names the replacement tool and the argument needed (view "recent"), which is exactly the routing guidance an agent needs to pick the right sibling. It lacks any statement of when the old alias might still be valid, so it falls short of a full 5.

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

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

Annotations already declare a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds real behavioral context beyond that: the results cover a trailing 7-day window and can be scoped to a single market/event. It does not discuss cost, rate limits, or result size, which would push it higher.

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

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

Two sentences, no filler, with the scope statement front-loaded before the alternative-tool routing. Every clause carries 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?

With no output schema, the description conveys what comes back (per-section prices and tickets) and the temporal coverage (now plus 7 days). It does not describe result shape or the effect of the 650-section limit, but for a read-only listing tool it is nearly complete.

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

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

Schema description coverage is 100%, so limit, event_id, sections, and include_history are all documented in the schema itself. The description adds no syntax, defaults, or filtering semantics beyond what the schema provides, so the 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?

States a specific verb and resource with scope: each section's prices and tickets, for one event, now plus the last 7 days. It also names the sibling it is not (get_event_sections_live), so an agent can distinguish it without opening schemas.

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

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

Explicitly routes the agent elsewhere for live/point-in-time/series needs: 'Use get_event_sections_live for seats open now, at a past moment (view at) or one section over hours (view series).' The alternatives are described by intent rather than exact tool names for the 'view at' and 'view series' cases, which slightly weakens the routing.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false). The description adds one genuinely useful behavioral fact beyond them — that this is a renamed/legacy entry point — but says nothing about whether calls still return data or are redirected.

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

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

A single sentence with zero waste, and the redirect (the most actionable information) is front-loaded.

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

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

For a renamed alias with only two fully-documented parameters and no output schema, the redirect is the essential content and it is present. Missing only whether the tool remains callable and whether its parameters match the replacement's.

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

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

Schema description coverage is 100%, so both `at` and `event_id` are already documented with format and defaults. The description adds only the mapping of the view name "at", which is marginal; 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 never states a verb+resource for this tool itself; it only points at get_event_sections_live with view "at". From that an agent can infer this reads event sections at an instant, but the purpose is conveyed indirectly through the redirect rather than stated.

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 names the alternative tool and the exact configuration to use instead (view "at"), which is real routing guidance. It stops short of saying whether this tool still works, is deprecated-but-functional, or will be removed.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds meaningful operational context by marking the tool as renamed/deprecated, but it does not disclose return format, pagination, or other behavioral traits.

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

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

The entire description is one short sentence with no wasted words. It front-loads the deprecation/redirect status, which is the only actionable information an agent needs.

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

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

The description is complete for routing an agent away from this deprecated alias, but it does not explain what the tool returns or how it behaves if called. With no output schema, a fuller description would normally be expected, though the rich input schema and annotations reduce the practical gap.

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

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

Schema description coverage is 100%, so all four parameters are fully documented in the schema, including detailed notes about bucket price approximation. The description adds no parameter meaning for this tool and merely refers to a parameter on the replacement tool, so baseline 3 is appropriate.

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

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

The description does not state what the tool itself does; it only says it has been renamed. The replacement tool and view name imply the original purpose (event section series) but this is inferred from the name and sibling, not explicitly stated. It is a vague purpose statement rather than a specific verb+resource description.

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

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

It explicitly names the replacement tool and the exact view parameter to use instead: get_event_sections_live with view "series". An agent is given an unambiguous instruction, which is the correct guidance for a deprecated alias.

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 only declare a safe read (readOnlyHint, non-destructive, non-open-world); the description adds genuinely non-obvious behavior: prices are exact only on the newest bucket and are approximations on earlier buckets ('Never present an earlier bucket's price as the price at that time'), and for GA 'added and removed are changes, not sales'. It also discloses time-window limits (90 days, 7 days) and the existence of a seat log as the data source.

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?

Front-loaded with the core purpose, then view-by-view, then alternatives and deprecations; every clause carries routing or caveat information, so little is wasted. The density of semicolon-chained clauses makes it slightly harder to scan than a fully structured list, but it is not padded.

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 12-parameter tool with no output schema, the description covers modes, time ranges, defaults, price caveats and alternatives well enough to call it correctly. It stops short of describing the response shape (e.g. per-section fields, pagination envelope beyond `next_cursor`), which is the only material gap.

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

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

Schema coverage is already 100%, but the description adds meaning the schema alone does not: it explains what each enum value of `view` actually returns, the 90-day cap on `at`, the 7-day cap and step sizes for `series`, the dependency that `section` is required for `series`, and the semantics of `bucket` price approximation. It also clarifies the page/`width` trade-off in prose.

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 ('Open seats per section of one event from the seat log') and then enumerates the four distinct views, so the agent knows exactly what each mode returns. It explicitly separates itself from get_event_sections and get_event_seats and names the three tools it replaces, which is precisely what an agent needs to disambiguate among the crowded sibling set.

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?

Gives explicit when-to-use guidance per view ('view now: ... view at: every section's open count at a past moment, up to 90 days back', 'view series: one section over up to 7 days'), including the workaround of calling 'at' twice and subtracting. It also names alternatives with their selection conditions ('Use get_event_sections for prices over 7 days and get_event_seats for single seats').

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, so the safety profile is covered structurally. The description adds nothing behavioral — no mention of deprecation behavior, whether the call still succeeds, or what it returns.

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

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

One short sentence with zero waste and the actionable instruction front-loaded. It is terse to the point of under-specification rather than padded.

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 deprecated alias the migration note is the essential content and it is present, but the description omits whether the tool still works, whether it errors, and what a caller gets if invoked anyway. With no output schema, that leaves real ambiguity.

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

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

Schema description coverage is 100% for the single event_id parameter, so the schema carries the parameter documentation burden. The description adds no parameter meaning beyond that, which is the expected 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 never states what the tool does or what it returns; it only announces a rename. An agent learns nothing about seller-concentration semantics from the text itself, and must infer the purpose from the title alone.

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

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

It explicitly routes the caller to the replacement, get_event_sellers, and even names the required view value ("now"). That is a concrete alternative plus condition, though it never says whether this tool still functions or when a caller could legitimately invoke it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered by structured data. The description adds one genuinely useful behavioral fact beyond annotations: the tool has been renamed and superseded. It says nothing about whether calls still succeed, error, or return stale data, so the disclosure is thin.

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

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

A single front-loaded sentence with zero filler; every word (rename, replacement tool, view value) is load-bearing and the agent gets the redirect immediately.

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 four-parameter tool with a full schema still exposed, the description omits key migration context: whether the tool remains callable, and how its parameters map to get_event_sellers view="market". No output schema exists, so return values need not be covered, but the unresolved replacement mapping leaves a gap.

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

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

Schema description coverage is 100%, so event_id, sellers, range, and section_ids are already documented in the schema, and the description adds no parameter syntax or constraints. It also does not explain whether these same parameters carry over to get_event_sellers with view "market", which is the migration detail an agent actually needs. Baseline 3 is appropriate.

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

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

The description never states what the tool does (read seller market series for an event); it only announces a rename and points to a replacement. The replacement name plus view "market" hints at the resource, but the agent must infer the actual purpose from the tool name and sibling get_event_sellers. It is a routing note, not a purpose statement.

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 names the tool to use instead, which is the strongest possible alternative guidance. However, it does not say whether this tool still functions, when it will be removed, or what condition (other than always) selects the alternative, leaving a small ambiguity about calling it.

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

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

Annotations already establish the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's job is to add context — and it does: sellers are anonymized into letters, letters reflect arrival order rather than rank, and they match the event page. It also discloses the 10-live-listing threshold and the 720-hour cap, though it says nothing about empty results or error behavior.

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

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

Front-loads the resource, then walks the three views in a compact parallel structure with the default flagged inline. It is dense and slightly run-on, but nearly every clause carries information an agent needs.

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 must carry the return-value burden, and it names the concrete metrics per view (active sellers, top shares, hhi, coverage; hour-by-hour movement; prices and listings per section). Coverage is good for a three-mode tool, though output shape and pagination remain only lightly sketched.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine semantics beyond the schema: letters are an arrival order not a rank and align with the event page, and the market view's 10-listing eligibility rule explains when the 'sellers' parameter can be populated at all.

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

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

States the resource precisely ('One event's sellers, anonymously and by letter') and enumerates three concrete views (now/series/market) with what each returns. It also names the three sibling tools it supersedes, so an agent can distinguish it from get_event_seller_concentration, get_event_seller_series, and get_event_seller_market without opening any schema.

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

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

Gives per-view selection criteria: 'view now (the default)' for concentration, 'view series' for hour-by-hour movement, 'view market' for chosen sellers' prices and listings. It also states the gating condition for the market view ('only a seller that reached 10 live listings can be chosen') and explicitly declares it replaces three named siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds no behavioral context of its own beyond the redirect – no return shape, no scope, no deprecation semantics beyond the word 'Renamed'. As a stub it is acceptable but contributes essentially nothing behavioral.

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

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

A single terse sentence with zero waste, and the redirect is front-loaded. It is appropriately sized for a deprecation stub, though it is arguably too thin to be self-sufficient.

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 renamed/deprecated alias the key need is telling the agent where to go, which it does. However it leaves gaps: it does not say whether calling it still works, and it gives no hint about the returned data, which an agent must resolve by opening get_event_sellers.

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 event_id and hours are fully documented in the schema; baseline 3 applies. The description adds no meaning about either parameter – notably it does not explain how 'series' related to event_id or hours.

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 never states what the tool itself returns; it only announces a rename and points elsewhere. 'view "series"' hints at the resource (seller series data), but an agent learns the purpose only indirectly. It is better than a pure tautology because it names the replacement, yet it does not describe the tool's own function.

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

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

It explicitly tells the agent not to use this tool and names the exact alternative plus the parameter value (get_event_sellers with view "series"). The when/when-not routing is unambiguous and requires no inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds one genuinely useful behavioral fact: the section map's saved view is app-only state and therefore not part of this payload. It says nothing about permissions, rate limits, or payload shape beyond that single exclusion.

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

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

A single short sentence with no padding, so it is not verbose. But the sentence leads with 'Removed:' rather than the tool's function, which is the opposite of front-loading the payload's purpose, and its content is thin relative to the space it occupies.

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 burden of explaining what an 'event workspace' contains, and it never does — it only documents an exclusion and a redirect. For a read tool whose return value is entirely opaque, this leaves an agent guessing about the payload it will receive.

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

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

Schema description coverage is 100% for the single event_id parameter, which the schema already documents as 'The event to read.' The description adds no syntax, format, or semantics beyond the schema, so the 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 never says what get_event_workspace returns or does; it only announces that a 'section map's saved view' was removed and points elsewhere for section data. From the text alone an agent cannot tell what a 'workspace' here contains, other than that it is not section data. It gestures at the resource but never gives a verb-plus-resource statement of purpose.

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

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

It does name an explicit alternative and condition: 'Use get_event_sections for the section data,' which routes the agent away from this tool for one specific need. However, it gives no positive guidance on when to call get_event_workspace itself or what question it answers. Implied usage only, not a real when/when-not rule.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds nothing about behavior — no note on pagination (limit/offset), what a returned issue contains, or the email-vs-file distinction it raises. The "Removed:" prefix is noise that risks misreading the tool's status.

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 text is short, but the leading "Removed:" fragment is pure waste and actively misleading, and the substantive sentence about reading the Digest is not front-loaded. Two sentences that a reader has to mentally repair is not effective conciseness.

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

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

With no output schema, the description carries the burden of explaining what an issue read returns, and it does not. It also says nothing about pagination behavior or how view_id and issue_id relate, leaving an agent without enough context to use the tool confidently.

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

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

Schema description coverage is 100%, so all four parameters (view_id, issue_id, limit, offset) are already documented in the schema, which sets the baseline at 3. The description adds no parameter meaning and introduces an "email or its file" dichotomy that maps to none of the actual 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 the fragment "Removed:", which suggests the tool has been deleted and actively undercuts an agent's confidence that get_issue is callable. The remainder ("Read the Digest email or its file") gives a verb and resource but never states that it reads a single issue identified by view_id/issue_id, nor distinguishes it from list_issues or list_digests.

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

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

There is no when-to-use guidance and no mention of the sibling alternatives (list_issues, list_digests) that an agent would need to choose between. The only routing hint — "email or its file" — refers to a choice that has no corresponding parameter in the schema, so it cannot guide invocation.

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, so the safe-read behavior is covered. The description adds the important redirect behavior (this tool is superseded), which is not in the annotations, but says nothing about this tool's own behavior, errors, or auth.

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

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

Single short sentence, front-loaded with the key fact. It is efficient and unambiguous, though terse to the point of omitting any statement of purpose.

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

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

For a deprecated tool whose job is to redirect, the critical information is present. However, it never states whether the tool still functions or what it returns, and with no output schema an agent gets no confirmation of behavior.

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

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

Schema description coverage is 100% and there is one required parameter, so the baseline is 4. The description adds a hint that match_id comes from list_matches, which is consistent with the schema and mildly useful, but not beyond structured fields.

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 does not state what the tool does. It only says 'Renamed: use list_matches with match_id,' which is a deprecation notice, not a purpose. An agent cannot tell from this text what get_match retrieves or why it existed.

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 routes the agent to list_matches and even names the argument to use (match_id). That is exactly the guidance needed for a deprecated tool: what to use instead and how.

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 the safety profile (readOnlyHint=true, destructiveHint=false), so the bar is lower. The description adds genuinely useful semantics beyond that: 'as they read now' conveys snapshot behavior, and 'higher rank is better and null means unranked, not zero' disambiguates a subtle data trait that annotations cannot express.

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?

Front-loads the core output ('One performer's numbers as they read now') before drilling into range semantics and routing. Slightly dense and the range sentence is a touch awkward, but nearly every sentence carries useful 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?

With no output schema, the description does the work of naming returned fields and the range semantics. For a read-only analytics tool with full schema coverage and covered annotations, this is essentially complete, though explicit 'when not to use' guidance is absent.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value over the schema by clarifying what 'range' actually governs — the performer's popularity rank over time, one row per date — which the schema only vaguely frames as a 'lookback window over snapshot_date'.

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 ('get performer analytics') and enumerates exactly what it returns: popularity rank, average prices, listings, X activity, playoff odds, and prediction markets. It explicitly routes the agent away from get_event_analytics and names the sibling it replaces (get_performer_rank_chart), so it is distinguishable without opening a schema.

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

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

It names the alternative ('Use get_event_analytics for one event') and declares itself the replacement for get_performer_rank_chart, which gives clear routing context. However, it does not spell out an explicit when-not-to-use condition for this tool beyond the sibling pointer.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context at all — no note on whether the tool still works, what it returns, or how the redirect interacts with existing callers.

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?

Eight words, front-loaded with the most important fact for an agent (this tool is superseded). It is genuinely concise rather than padded, but the terseness borders on under-specification given it is the entire documentation for a live three-parameter tool.

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

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

For a tool that still appears in the active tool list with a required performer_id and two optional behavior-altering parameters, the description omits whether calls still succeed, what a rendered vs. data-only response contains, and what happens to existing integrations. The routing hint is present but the definition is not complete enough to invoke the tool knowingly.

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

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

Schema description coverage is 100%, so the schema already documents performer_id, range (with its enum and default), and render. The phrase 'with range' adds only a hint that the range parameter carries over to the replacement, which is marginal value over the schema. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description never states what the tool does; it only announces that the tool was renamed and points elsewhere. The name suggests a performer rank chart, but the text itself conveys no verb+resource purpose and gives no distinguishing detail versus siblings like get_performer_chart or get_performer_analytics.

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 routes the agent to an alternative ('use get_performer_analytics with range'), which is the single most useful instruction an agent could get for a superseded tool. It stops short of a 5 because it never states when, if ever, calling this tool itself is still appropriate, nor whether it remains functional.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds behavioral value beyond that: ordering (soonest first), the fields returned (sale dates, get-in price, roof, forecast), and a deprecation/migration note. It does not cover rate limits or auth, hence not a 5.

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?

Core behavior is front-loaded in the first sentence, followed by tightly packed routing constraints. Every clause carries information (return content, alternatives, deprecation) 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?

For a 9-parameter, optional-only tool with no output schema, the description covers what gets returned and which mode to use, and flags that find_venue is superseded. Remaining gaps (seed parameter interplay, pagination) are minor.

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

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

Schema coverage is 100%, so the baseline is 3. The description meaningfully supplements the schema by explaining the two view modes and, notably, the 'official name, not a nickname' rule for venue_name — semantics the schema's maxLength/minLength text 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?

Opens with a specific verb and resource ('Shows the upcoming events at one venue'), states ordering (soonest first) and return content (sale dates, get-in price, roof, 7-day forecast). It then explicitly separates itself from the venue-search mode and names sibling find_venue, so an agent can distinguish the two without opening schemas.

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

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

Gives explicit routing: use view=venues to find venues (by name, state, country, capacity), use screen_events to rank a venue's events, and notes this 'Replaces find_venue'. It also warns to use the official name, not a nickname — a concrete when-to/how-to constraint.

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, destructiveHint=false, so safety is covered; the description reinforces this with 'sends nothing' and adds a genuinely new behavioral constraint, the 24-hour lookback window. It does not describe whether the preview is rate-limited or how large the preview can get.

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 short sentences, purpose front-loaded, no filler. Each sentence carries distinct information: what it does, the no-send guarantee, sequencing, and alternative routing.

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

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

For a one-parameter read-only preview with no output schema, the description conveys the temporal scope and what the preview represents. It stops short of describing the preview's shape (e.g., counts vs. full email bodies), which is the only meaningful gap.

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

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

Schema coverage is 100% and the single view_id parameter is already documented as a UUID sourced from list_views. The description's phrase 'one View' and 'owner's current settings' adds only marginal context beyond the schema, so the 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?

States a precise verb and resource: it previews what a View would have emailed in the last 24 hours, under current owner settings. It also distinguishes itself from list_matches, which answers the different question of what was actually recorded/sent.

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?

Gives explicit sequencing ('Call it after create_view or update_view') and routes a neighboring use case to the correct sibling ('Use list_matches for the Matches it recorded and whether each was sent'). An agent knows both when to call it and when to call something else.

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 only declare a safe read (readOnlyHint=true, destructiveHint=false, openWorldHint=false), which would mislead an agent into thinking this is a functioning read. The description adds the crucial behavioral fact that the tool no longer exists. It does not say whether a call errors or returns empty, so it stops short of full transparency.

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

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

A single sentence, front-loaded with the decisive 'Removed:' marker so the agent gets the critical fact first. 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 zero-parameter, no-output tool this covers everything an agent needs: it is gone and where the setting now lives. The only gap is the runtime behavior of an actual call and whether the related set_watch_defaults sibling is similarly affected.

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 takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly makes no attempt to describe 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 states a specific, actionable fact about the tool: it has been removed and watch defaults are now an account setting. That is clear and prevents a wasted call, though it never says what the tool originally did and does not differentiate this stub from the still-listed sibling set_watch_defaults.

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 when-not (the tool is removed) and an explicit alternative destination ('Change them in the Ticker web app under Settings'), leaving nothing for the agent to infer about where to go instead.

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, so safety is covered. The description goes beyond them by disclosing the return payload (id, paused, plan limit/used) and flagging that creation happens externally in the web app, which is genuinely useful context. Pagination behavior is unmentioned, a minor gap.

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

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

Three tight sentences with the core purpose front-loaded, followed by sibling routing and the external-creation caveat. Every sentence carries information; nothing is 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?

No output schema or parameters exist, and annotations cover the safety profile, so the description's job is mainly to describe what comes back and how it relates to siblings. It does that adequately, leaving only pagination/volume behavior unspecified.

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

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

The tool takes zero parameters, so the baseline is 4; there are no parameter semantics for the description to add or omit.

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 (Lists) and resource (the account's alert destinations), and clarifies scope by naming the channel types (Slack, Discord, non-email) and the returned fields (id, paused, plan limit/used). An agent can distinguish this from list_views and list_digests without opening a schema.

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

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

Points to list_views for the related question of which Views deliver to each destination, and notes that new destinations are added in the Ticker web app rather than via any tool (there is no create_destination sibling). Clear routing context, though it never states an explicit 'use this when' trigger.

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, destructiveHint=false, openWorldHint=false. The description adds no additional behavioral context (no return shape, no note that the call is a no-op or deprecated). It only implies the underlying concept was removed, without clarifying what invoking it does.

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?

It is short, but the leading "Removed:" fragment is confusing and not front-loaded with a purpose statement. The sentence structure reads like a changelog note rather than tool documentation.

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 should at least state what is returned or whether the tool is still callable. Instead it is a cryptic deprecation note that leaves an agent unsure whether to invoke it or defer to list_views.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter semantics are required or missing.

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 "Removed:", a tombstone that never states what list_digests actually does or returns. It obliquely explains what a Digest is ("an email and a file") but gives no usable statement of purpose for this tool; an agent cannot tell what calling it would accomplish.

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 does route the agent elsewhere by naming list_views as the source of digest information ("list_views says which Views send one"), which is a usable alternative pointer. However, it never says when this tool itself should be used, so the guidance is partial and ambiguous.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so safety needs no elaboration. Instead of adding behavioral context, the description inserts a 'Removed:' claim that implies the tool is unavailable, which is misleading for a live callable read endpoint and contributes nothing about pagination or 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?

It is short, but brevity here reflects under-specification rather than economy. The front-loaded 'Removed:' is misleading and the following sentence does not earn its place by clarifying the tool's function.

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 three-parameter list tool with no output schema, the description should at minimum explain the resource being listed and how results are scoped. It provides none of that, leaving the agent with no usable context beyond the title and 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?

Schema description coverage is 100%, and all three parameters (limit, before, view_id) are individually documented in the schema. The description adds no parameter meaning whatsoever, so the baseline of 3 applies.

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

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

The description never states what the tool does. Instead of a verb+resource for listing a View's Digest Issues, it leads with 'Removed:' and then talks about the Digest being an email and a file, which is misleading rather than descriptive. An agent cannot tell from this text that the tool lists issues.

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 only guidance offered is 'Read the Digest email or its file,' which steers the agent toward non-tool behavior instead of explaining when to call list_issues versus siblings like get_issue or list_digests. No preconditions, no exclusions, and the 'Removed' framing actively discourages 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?

Annotations already cover the safe read profile (readOnlyHint/destructiveHint/openWorldHint), yet the description adds real behavior: newest-first ordering, that match_id returns the event and its numbers frozen at View-entry time, and the delivery-status truth rule. It does not mention pagination limits or the heavy-payload risk of snapshots, which live only in the 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?

Front-loads the default behavior, then the two modifier modes, then the delivery-status rule, ending with the replacement note. Four dense sentences with no filler; the 'Replaces get_match' clause is terse but useful rather than 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?

No output schema exists, but the description covers the primary mode semantics, ordering, and the critical delivery-status interpretation, so an agent can call it correctly. The remaining gaps (event_id's effect, pagination behavior) are minor for the common paths.

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?

At 50% schema coverage the description carries part of the load: it explains what view_id and match_id change about the response, which the schema only types. The richest parameter semantics (delivery_status enum meanings, include_snapshot heaviness) sit in the schema itself, and event_id/page/limit remain unexplained in both.

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?

Specific verb+resource ('Lists the events that entered the caller's Views') with ordering (newest first) and a clear disambiguation of its three modes keyed by view_id and match_id. It also names the sibling it replaces (get_match), so an agent can route without opening either schema.

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

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

Gives explicit conditions for each mode ('with view_id it adds...', 'With match_id it shows one Match in full') and a firm usage rule ('Read delivery_status, never a timestamp'), plus the replacement relationship to get_match. It stops short of stating when NOT to use it or naming a live alternative for the single-match case.

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 the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the description's job is to add what they don't: that a 'venue's name is v.venue_name' (a concrete naming gotcha), and that multiple search words should be passed together in one call rather than looped. It does not discuss result volume or rate limits, which is the remaining gap.

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

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

Dense but front-loaded: the resource and payload come first, then the search tactic, then the precondition and the alternative. The semicolon chain packs a lot into few sentences with no wasted clauses, though the density borders on cramped.

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 still describes the return contents (meaning, unit, plan) and the description/schema pair covers pagination via the offset parameter and meta.next. For a two-parameter read-only lookup tool, nothing an agent needs to call it correctly 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?

Schema coverage is 100%, so baseline is 3. The description still adds value by naming candidate search terms (price, demand, inventory, rank, date, category) and by directing that all needed words go into a single call instead of being issued separately, which the schema's 'any of them' wording does not make obvious.

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 (Lists) and resource (every column a screen_events, create_view or update_view predicate can name), plus the return payload (meaning, unit, plan). It anchors itself to the exact sibling tools whose predicates consume these columns, so an agent can place it without opening a schema.

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

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

Explicit precondition: 'Call it before you write a predicate; column names must be used exactly.' Explicit alternative: 'Use get_event_analytics for the values on one event.' Both the when-to-use and the when-to-use-something-else are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description goes further by enumerating what the response contains, which is meaningful since no output schema exists, though it says nothing about pagination or result-size behavior.

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

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

Dense but front-loaded, leading with the verb and resource before the field list. The field enumeration is a long run-on clause, but no sentence is pure waste; 'Replaces list_view_targets' is useful migration context.

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

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

With no output schema, the description carries the return-value burden well by listing the fields returned. It stops short of explaining pagination behavior or whether view_id bypasses paging, a minor gap for a 4-param listing tool.

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

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

Schema description coverage is 50%: 'enabled' and 'view_id' are documented in the schema, while 'page' and 'limit' are not. The description reinforces view_id's read-one-View semantics but adds nothing about paging or limit, so it only partly compensates for the coverage gap.

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

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

Names a specific verb and resource ('Lists the caller's saved Views') and enumerates the returned fields (predicate, on/paused state, member_count, Matches in last 7 days, destinations, Digest), which distinguishes it clearly from siblings like list_matches and get_view_alert_preview.

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?

Routes the agent conditionally: 'Use list_matches for which events entered them, and get_view_alert_preview for what one View would email', and explains that view_id reads one View instead of a page. It also flags that it 'Replaces list_view_targets', which is present as 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=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact not in the annotations — that this tool is deprecated/superseded — but says nothing about return contents or failure behavior.

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

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

One short sentence, front-loaded with the essential instruction and zero waste. It is appropriately sized for a deprecated alias, though it is terse to the point of saying nothing about the tool's actual behavior.

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 superseded tool, telling the agent where to go is arguably the minimum viable content, and the rich schema covers the parameter. However, it omits whether the tool still works, what it returns, and any error behavior, so an agent lacks the full picture.

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 there is a single parameter, so the schema carries the semantics, including the notable constraint that destination posting URLs are never returned. The description adds nothing about view_id beyond the schema. 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 never states what the tool does; it only announces a rename and points elsewhere. The function is inferable only from the tool name and title, not from the description text itself. It is not misleading, but it is a redirect rather than a purpose statement.

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 the single most important routing instruction an agent needs: use list_views with view_id instead. The alternative is named explicitly. It stops short of 5 because it never says whether this tool still functions or under what conditions it should ever be called.

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, so the safety profile is covered. The description still adds real behavioral context: which fields are returned and the non-obvious rule that watches whose event ended more than a week ago are silently omitted unless include_archived is set. It does not mention pagination behavior for a paged list.

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 sentences: what it returns, the archival edge case, then the sibling pointer. Nothing is redundant and the most decision-relevant content leads.

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 usefully enumerates the returned fields, and it covers the key filtering caveat. It is slightly incomplete for a 6-parameter list tool with no pagination or sort/order semantics documented anywhere.

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 33% — search and include_archived are documented, while page, sort, limit and order are bare. The description reinforces include_archived's semantics ('left out unless include_archived is true'), which is genuine compensation, but the four pagination/sorting parameters remain unexplained in both places.

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 ('Lists the events the account watches') and immediately scopes the return payload (current prices, armed triggers, alert counts, alerts_live). It also explicitly distinguishes itself from list_views, so an agent can route between them without opening schemas.

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

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

Provides one explicit alternative and its condition: 'Use list_views for saved screens.' It also explains the default exclusion of old ended events and how include_archived changes it. No guidance is given on other watch-related siblings (list_watch_triggers, get_watch_defaults), so it stops short of full when/when-not coverage.

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, destructiveHint=false and openWorldHint=false, so safety is covered by structured data. The description adds the genuinely useful fact that the endpoint is removed, but does not say what happens if an agent calls it anyway (error vs. empty result) or what the replacement field contains.

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

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

Two short sentences with the deprecation status front-loaded in the first word, followed by the redirect. No filler and no ambiguity about the action to take.

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 zero parameters, no output schema and a removed endpoint, the description supplies everything an agent needs: do not call this, use watch_event's `triggers` input instead. There is no meaningful return value or parameter detail left unexplained.

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

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

The tool takes zero parameters and the schema correctly enforces that with additionalProperties=false, so there is no parameter semantics to explain. Baseline 4 applies; nothing in the description is needed or missing 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 does not describe the original listing behavior at all; instead it declares the tool removed and names the authoritative replacement field (watch_event's `triggers` input). For a tombstoned tool that is the relevant purpose, and it is unambiguous, though it never says what the tool used to return.

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

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

It states outright that the tool is gone and gives the exact alternative: read the `triggers` input of watch_event. An agent has a clear when-not-to-use signal plus a concrete redirection, with nothing left to infer.

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 destructiveHint=true and readOnlyHint=false, so the safety profile is covered. The description adds the critical behavioral fact that the tool has been renamed, which is not in annotations, but it does not describe what gets detached, required permissions, or whether the old endpoint still functions.

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

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

One short sentence, front-loaded with the key action word 'Renamed' and the alternative. Every word earns its place.

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

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

For a deprecated alias, the description gives the essential redirect, and annotations cover destructiveness. However, it omits whether this tool still works or will error, and doesn't restate the operation, leaving the agent to infer the deprecation's effect.

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 describes both view_id and delivery_target_id with sources. The description only mentions detach_destination, which belongs to update_view, so it adds no meaning to this tool's 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 does not state what remove_view_target does; it only announces a rename and points to update_view. It does distinguish the tool's replacement, so an agent can avoid the wrong tool, but the original operation (detach a destination) is left to the title. This is a vague purpose for the tool itself.

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 names the replacement and the parameter to use ('use update_view with detach_destination'), which is exactly the routing an agent needs. There is no ambiguity about when to use this tool versus the 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 declare openWorldHint=true and readOnlyHint=false, and the description adds behavior beyond them: results are a 24-hour cache, they are not live figures, and force bypasses the cache. It does not contradict annotations. Quota semantics live in the schema rather than the description, which is the only notable gap.

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

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

Two sentences, no filler, with the scope caveat ('not live figures') placed early and the routing guidance second. The first sentence is dense but each clause carries information.

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

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

Given no output schema and rich annotation/schema coverage, the description supplies what an agent most needs: what the tool returns, how long results persist, and when to reach for it versus a sibling. Only the output shape and source-selection nuance are absent, and those are partly covered by the 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?

Schema coverage is 100%, so the schema already documents event_id, sources, and force in detail, including the quota and cache-bypass behavior. The description only adds that force overrides the 24-hour save window, which is largely redundant with the schema text. Baseline 3 is appropriate.

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

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

States a specific verb and resource: recent cited news and social coverage explaining why one event may be moving. It explicitly distinguishes itself from get_event_analytics ('for the numbers'), so an agent can separate the qualitative-context tool from the quantitative one without opening schemas.

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

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

Gives an explicit trigger ('after screen_events or get_event_analytics flags a move') and names the alternative for the adjacent need ('use get_event_analytics for the numbers'). This is a textbook when-to-use/when-to-use-other 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 cover the safety profile (readOnlyHint/destructiveHint/openWorldHint), but the description adds substantial behavior beyond them: the auto-applied economic floor, mandatory exclusion of parking/no-admission SKUs and refusal of sub_category_id 75, the today-or-later freshness scope, absorption = delisting not sales, cost implications of count (~2x) and diagnostics (~5s), and SQL-side validation with clear 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?

It is front-loaded correctly (purpose and alternatives first), but the body is a single unstructured wall of DSL rules that in places restates what the predicate schema parameter already documents. For a 10-parameter DSL tool length is defensible, yet the lack of grouping and the duplication keep it from earning full marks.

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

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

Given a complex recursive predicate, 10 parameters and no output schema, the description covers the gates, exclusions, error semantics, cost tradeoffs and the performer-vs-event-name distinction, so an agent has what it needs to call the tool correctly without a return-value contract.

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 90%, so the baseline is 3; the description adds meaning by routing act/team asks to p.name rather than e.event_name, warning that '!=' compares whole values while not_contains removes by word, and clarifying the {days_ago}/{weekend} relative value forms. Much of this overlaps the predicate schema text, so it is additive but not fully independent of structured data.

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?

Specific verb+resource+scope: 'Finds and ranks upcoming events by price, demand and inventory' built on a predicate over the columns list_screen_columns names. It also explicitly distinguishes itself from siblings, routing 'which events' questions here, name lookups to search_events, and single-event metrics to get_event_analytics.

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?

Explicit routing: 'Use it for which events questions; use search_events ... get_event_analytics ...'. It also carries conditional usage guidance for individual flags (count only for cardinality asks, diagnostics only on empty, apply_floor false only for the raw universe, exclude_stale false only on explicit request), which is when-to-use at parameter granularity.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds non-obvious workflow context: that it hands back event ids and that a name match can be unnecessary when a link already exists. It stops short of describing pagination/truncation behavior at the top level, but that lives in the 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?

Three short sentences, each earning its place: purpose and scope, sibling routing, and a duplicate-work warning. The core capability is front-loaded before the alternative tool is mentioned.

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 19 optional parameters at 95% schema coverage and no output schema, the definition is nearly complete; it states that event ids are returned, partially covering the return surface. It does not, however, hint at pagination or truncation at the top level, leaving that burden entirely to the limit parameter description.

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 95% and the per-parameter descriptions are unusually detailed (search semantics, status retry behavior, sort implications, id formats). The description only restates the filter dimensions, adding essentially nothing beyond what the schema already supplies, so the 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?

States a specific verb (finds) and resource (events), enumerates the searchable dimensions (name, performer, venue, date, on-sale/presale/added dates), and names the return value (event ids). It explicitly separates itself from screen_events, so an agent can route correctly without opening schemas.

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

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

Names the alternative (screen_events) and the exact condition that selects it (rank or filter by price, demand, inventory). It also gives a negative rule of thumb — do not re-search for a link when rows already carry event_id and event_url — which is a concrete when-not-to-call case.

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 destructiveHint=true, openWorldHint=true and readOnlyHint=false. The description adds the non-obvious behavioral fact that the tool has been renamed/deprecated, which annotations do not convey, but says nothing about what happens if it is still invoked or what state it mutates.

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

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

A single sentence, front-loaded with the deprecation and immediately followed by the redirect. Nothing extraneous; for a tombstoned tool this is exactly the right size.

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 renamed/deprecated alias with no output schema, the description supplies the essential information an agent needs (stop using this, go here). It does not clarify whether the call still functions or how to map cadence/delivery_target_id onto update_view's attach_destination, a minor gap.

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

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

Schema description coverage is 100% (view_id, delivery_target_id, cadence all documented with sourcing hints and cadence semantics), so the baseline is 3. The mention of 'attach_destination' hints at a parameter of the replacement tool but adds no meaning to this tool's own 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 itself does not state what the tool does (attach a delivery destination to a view); that only comes from the title. It does communicate that the tool is renamed/deprecated and where the replacement lives, which is the most decision-relevant fact, but an agent reading the description alone gets no verb+resource description.

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

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

It explicitly names the alternative to use instead ('use update_view with attach_destination'), which is the strongest routing guidance possible for a deprecated tool. It omits whether calling this tool is still safe or errors out, but the when-not-to-use direction is unambiguous.

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

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

The annotations describe an active mutation (readOnlyHint=false, destructiveHint=true, openWorldHint=true), and the description adds the far more important behavioral fact that the capability has been removed — information the structured fields do not carry. It stops short of saying whether invocation errors or silently no-ops, which leaves a minor gap.

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

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

A single short sentence, front-loaded with the status change and followed immediately by the redirect. Zero waste; every clause earns its place.

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

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

For a removed tool, the description covers what an agent needs: don't call it, use Settings instead. The only omission is the exact behavior on invocation (error vs no-op), which matters somewhat given the annotations still advertise a destructive write.

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 input schema documents all three parameters (including the nested trigger structure) in detail, so the baseline of 3 applies. The description adds nothing about parameters, but nothing is needed since the tool is removed.

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 'Removed:' and identifies the resource (watch defaults), making the tool's actual status unambiguous. It doesn't restate what the tool used to do, but for a deprecated endpoint the operative fact — it no longer works — is stated plainly and distinguishes it from the live sibling get_watch_defaults.

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

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

It explicitly tells the agent when not to use it and where to go instead ('Change them in the Ticker web app under Settings'). That is a complete when-not plus alternative routing, the strongest form of usage 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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description goes further by disclosing concrete consequences: alerts stop immediately, unsent alerts are dropped (data loss), and past alerts remain in list_matches — exactly the kind of detail annotations cannot convey.

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

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

Two sentences with zero filler; the core action is front-loaded and the routing hint follows immediately. Every clause carries distinct 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 simple one-parameter mutation with no output schema and annotations covering safety, the description is nearly complete: it covers action, side effects, and the alternative. It stops short of mentioning error/not-found behavior or whether the event must currently be watched, a minor gap.

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

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

Only one parameter and schema description coverage is 100%, so the schema already documents event_id fully. The description adds no syntax, format, or edge-case guidance for the parameter; 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?

States a specific verb+resource ('Takes one event off the watchlist') and immediately distinguishes itself from the sibling watch_event. An agent can tell this apart from watch_event and update_watch without opening any schema.

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

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

Explicitly names the alternative ('Use watch_event instead') along with the condition that selects it ('to keep the star and turn triggers off'), making the when-to-use vs when-not 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?

The annotations declare readOnlyHint=false, destructiveHint=true, and openWorldHint=true, i.e. a live destructive write operation. The description states the tool has been removed and performs no such action, directly contradicting the declared write/destructive behavior. Per the rules this is an annotation contradiction.

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

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

A single short sentence with the most important token ('Removed:') front-loaded, so an agent skimming the description immediately learns the tool is gone. 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 retired tool, the description delivers the one fact an agent needs: don't call this, manage destinations in the web app. It omits whether invocation returns an error or silently no-ops, and references no in-surface replacement, but otherwise it is complete for its purpose.

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 67%, with label, enabled, and destination_id defined in the schema (enabled and destination_id carry their own descriptions). The tool description adds nothing about parameters at all, so it fails to compensate for the uncovered 'label' parameter.

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

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

The description never states what update_destination does; it only announces that the tool is removed. The verb+resource pairing is absent, replaced by a deprecation notice that redirects to the Ticker web app. It conveys the resource domain (alert destinations/settings) but not the operation, so an agent cannot infer functionality from 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?

It does give a use/don't-use signal: rename, pause, or delete destinations via Settings in the web app rather than this tool. That is actionable guidance, but it names no MCP sibling alternative (delete_destination still appears in the sibling list) and doesn't say what happens if the tool is invoked anyway.

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 supply the safety profile (destructiveHint=true, readOnlyHint=false, openWorldHint=true), so the bar is lower. The description adds genuine behavioral context beyond that: partial-update semantics ('Only the fields passed change') and that attach/detach govern delivery routing. It does not warn that predicate/channel replacement overwrites prior values, which is the destructive edge the annotation implies.

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, front-loaded with what the tool changes before the routing guidance. No filler, though the 'Replaces set_view_target and remove_view_target' sentence packs two facts that could be tighter.

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 15-parameter mutation with nested Digest objects and no output schema, the description covers purpose, patch semantics, routing, and delivery behavior; the deep field detail lives in the schema. It never states what a successful call returns or whether there are permission/plan gates, though the digest schema partially covers plan refusals.

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 73% with rich per-field descriptions (tags, color, digest, notification_mode, attach/detach), so the schema does the heavy lifting. The description lists field groups at a high level but adds no syntax or constraint detail beyond the schema, which is the correct baseline of 3.

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

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

States a specific verb ('Changes') and resource ('saved View'), then enumerates the updatable field groups (name, predicate, channels, email mode, destinations, paused state, Digest). It also names the siblings it is not (create_view, delete_view), so an agent can distinguish it without opening a schema.

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

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

Explicit routing: 'Use create_view for a new View, and delete_view to remove one for good,' plus 'Replaces set_view_target and remove_view_target.' This tells the agent both when to use this tool and which legacy/sibling tools it supersedes.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, i.e. a mutating write tool, yet the description says nothing about whether calls still mutate a watch, silently alias to watch_event, or hard-fail. For a superseded mutation endpoint, that ambiguity is the single most important thing to disclose. It adds no behavioral context beyond what annotations already imply.

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

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

One short sentence, front-loaded with the status and the redirect. Every word earns its place for a deprecation stub.

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 3-parameter tool with nested trigger objects, an agent needs to know whether the endpoint is live-but-deprecated or removed; the description leaves that unresolved. It also fails to state the effective cutoff for the old name, unlike the schema's own 'digest' note, so it is not complete for correct invocation.

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

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

Schema description coverage is 100%, with event_id, triggers, and notification_mode all documented in-schema (including trigger ranges and the 'digest' deprecation note), so the baseline is 3. The description adds nothing about parameters, which is acceptable but not additive.

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 never states what update_watch actually does — it only announces a rename. There is no verb+resource describing behavior for this entry, just a pointer. It does at least signal status (superseded), which keeps it from being purely misleading.

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 names the replacement tool ('use watch_event'), which is exactly the routing an agent needs when it lands on this entry. It lacks any statement of when a call here still works versus errors out, so it falls short of a 5.

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

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

Annotations already declare a destructive, non-read-only, open-world mutation, so the bar is lower. The description adds real value: 'only what you pass changes' clarifies this is a partial update rather than a destructive overwrite, and it documents that out-of-range trigger parameters are refused with an error and nothing is written. The 'dormanted' sentence hints at a return field but is opaque and references a field absent from the 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?

Front-loaded with the core action and compressed into a few dense clauses with little waste. The mid-sentence 'dormanted' aside interrupts the flow and is not obviously tied to any visible field, slightly reducing clarity.

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 nested, 3-parameter mutation tool with no output schema, the description covers the action, the partial-update semantics, validation failure behavior, and sibling routing. It does not mention return values or any permission/auth requirements, but the 'dormanted' note gives partial insight into output.

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 mostly restates what the schema already says ('the triggers input lists every trigger and its range', omit-to-use-defaults), adding only the partial-update framing. It does not disambiguate whether triggers must be supplied wholesale.

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+resource ('Stars one event and arms its alerts') and covers the update case ('changes the triggers or email mode of an event already starred'). It explicitly distinguishes itself from create_view and notes it 'Replaces update_watch', so an agent can route without opening a schema.

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

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

Names the alternative (create_view) and the selecting condition ('for alerts on every event a screen finds'), implying watch_event is for single events. It also flags the deprecated update_watch sibling, which is exactly the kind of routing an agent needs.

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