alertcamp

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

Annotations only declare it is a non-read-only, non-idempotent, open-world write. The description adds far more: two independent quotas and how they are reported, refusal returning the same numbers in structuredContent, the webhook_secret returned once with signature/timestamp verification, SMS cost and silent dropping of tier-gated channels, and the non-editable nature of day_use_cells and activity_type.

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 purpose, then quotas, then the exclusion, then date modes — a sensible order for a 24-parameter tool, and most sentences earn their place. It is nonetheless very long, and the final two paragraphs argue the same point (resolve narrowing into explicit site_ids) twice, once for verifiability and once for position, which is redundant.

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 this complex — 24 parameters, nested objects, two enums, a quota system, three mutually exclusive date modes — the description covers every decision an agent must make before calling. An output schema exists, so return values are correctly left unelaborated beyond the refusal-shaped structuredContent note.

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 goes well beyond per-field docs by explaining cross-parameter interplay: nights vs entry-date vs day-use modes and which fields are derived or ignored in each, the ['all'] semantics for zone_ids/site_ids, and the warning that sub_equipment_id integers are per-provider. This is meaning the schema alone cannot carry.

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: 'Watch a park for cancellations and notify the user when a matching stay opens up.' The scope is further pinned by explicit exclusions (route backcountry → create_itinerary), so an agent can separate it from create_itinerary, update_alert and get_alert 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_itinerary) and the exact condition that selects it (get_park reports supports_routes: true), including the one-night-route nuance. It also gives the prerequisite call chain (list_park_campgrounds → list_campground_zones → list_zone_sites), the remedy when refused for size, and when each of the three date modes applies.

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 it is a non-read, non-destructive, non-idempotent, open-world writer, but the description adds traits annotations cannot carry: the window is a search window rather than the trip itself, a route counts as one alert against quota, its legs never surface in list_my_alerts, and refusals are non-retryable. That is material behavior a caller needs before invoking.

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 distinction and split into labeled sections (two ways, window, quota, refusals) so nothing important is buried. It is on the long side with heavy capitalization and emphasis, but nearly every sentence carries decision-relevant 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 10-parameter, open-world mutation tool with an output schema covering returns, the description supplies exactly the missing pieces: the two invocation modes, window semantics, quota accounting, notification cost caveats, and refusal behavior. Nothing an agent needs to call it correctly 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 coverage is 100% and the per-field descriptions are already strong (OR-set site_ids, notify_sms cost, inventory-matching party_size). The description still adds real meaning the schema lacks: the planned-vs-custom decision, that nights are omitted when route_id is given, and that route_id skips the adjacency check.

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 scope ('a MULTI-NIGHT TRAVERSE — a trip needing a different zone each night') and explicitly distinguishes itself from the sibling create_alert, which 'cannot express' this. An agent can route between this and create_alert 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 an explicit trigger ('use this whenever the user describes moving camp' with quoted examples), then ranks the two specification modes with 'PLANNED (prefer this)', and names the fallback when a custom route is refused. Alternatives, preferences, and failure handling are all spelled out.

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 idempotentHint=true, so the danger profile is partly covered structurally. The description still earns credit by disclosing consequences annotations cannot express: deletion is permanent and destroys scan history and accumulated odds, and a recreated alert restarts from zero, plus the 100-alert cap mechanics. It does not add much beyond that, and with rich annotations present a 3 is appropriate.

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 action and the preferred alternative before the justification, so an agent gets the decision rule first. The single dense paragraph is longer than typical but nearly every clause carries operational weight; it could be split for scannability but there is little true 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 destructive, irreversible tool the description covers reversibility, the alternative, the capacity constraint that forces deletion, and the confirmation obligation. With an output schema present it need not describe return values, and annotations plus the 100%-covered schema carry the rest.

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 schema already explains both fields in detail, including the exact-label requirement and why the label is needed for client-side approval. The description adds no parameter-level syntax or format beyond that, so the high-coverage baseline of 3 applies; its 'ask the account holder which alerts they mean' note is guidance, not parameter semantics.

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

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

States a specific verb and resource ('Permanently remove an alert from the user's list') and immediately names the sibling it must not be confused with, pause_alert. An agent can separate this from pause_alert, update_alert and delete_itinerary 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 alternative and the condition that selects it ('PREFER pause_alert when the user may want it back'), then states when deletion is genuinely required (the 100-alert cap including paused and expired). It also sets a procedural precondition: confirm which alerts the account holder means before deleting any the agent did not just create.

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 destructive=true and idempotent=true, so the bar is lower, yet the description still adds real context: what is lost (every night of the route), that the loss is irreversible, that nights cannot be rebuilt by editing, and that deletion must be confirmed with the account holder. This goes well beyond the annotation set.

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 correctly with the destructive action first and the alternative second, but the clause 'the nights cannot be rebuilt by editing' is repeated verbatim in consecutive sentences, which is dead weight in an otherwise tight description.

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

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

An output schema exists so return values need no explanation, and annotations carry the safety profile. For this complexity level the description covers purpose, irreversibility, the sibling alternative, and the confirmation prerequisite — nothing an agent needs 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 the schema already carries parameter meaning — including the cross-checked `route` label and its refusal behavior. The description adds no syntax or format detail for either parameter, 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 — 'Permanently remove a route and stop watching every night of it' — with the permanence qualifier that separates it from the pause/resume siblings. An agent can distinguish it from pause_itinerary 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 routes the agent: 'PREFER pause_itinerary when the user may want it back', gives the reason (reversibility), and adds a confirmation protocol ('Ask the account holder which routes they mean before deleting any you did not just create'). When-to-use, when-to-use-something-else, and a prerequisite are all present.

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/idempotent/destructive=false, so safety is covered. The description adds genuinely non-obvious behavioral context: scan_count and last_checked_at are a MINIMUM across phase-staggered polling targets, warning the agent not to misread a fresh multi-zone alert's zero count as a fault. That is real value beyond structured fields, though it omits auth or rate-limit behavior.

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

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

Purpose is front-loaded in the first clause, followed by a clearly labeled NOTE. Both sentences carry information — one about output shape and one about a subtle data trap — with little filler, though the sentence structure is dense.

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

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

For a read-only single-entity getter with an output schema present, the description covers the essential ambiguity (the counterlag explanation) and points at the site_limits payload. Nothing critical is missing, though the lack of any sibling routing keeps it just 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 coverage is 100% with a single alert_id parameter, so the schema fully documents the input. The description adds no syntax or constraint detail for alert_id, matching the baseline-3 expectation when structured data carries the load.

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

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

The description states a specific verb+resource (retrieving one alert) and describes its payload (scan metrics, site_limits contents), which is far better than a tautology. It does not, however, explicitly distinguish itself from the sibling list_my_alerts, leaving that separation to inference.

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 one actionable instruction — read site_limits before offering to widen a selection — which implies usage context. But it never says when to use get_alert versus list_my_alerts or update_alert, so the alternative-selection guidance is only implicit.

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

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

Annotations already declare readOnly/idempotent, so the description adds higher-value context instead of repeating them: the season appears only in the availability grid and shifts when the next season releases, each slot has its own cutoff so a future date is not necessarily live, and closed_cells must be skipped. This is real behavioral disclosure an agent could not infer.

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 and information-dense, but the middle paragraph about next_release_at and AlertCamp polling the drop is tangential to this read tool and inflates the definition. Some sentences explain alert mechanics rather than how to call this 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?

With an output schema present, the description needn't document return values, yet it still explains the non-obvious fields (max_span_days, closed_cells). A single-parameter read tool is fully specified: what it returns, why it's needed, and what to do with closed_cells.

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 there is a single parameter; the schema already states zone_id comes from list_campground_zones on DayUse parks. The description restates the DayUse precondition but adds no new format or derivation detail, 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 ('the dates a DAY-USE grid offers') plus the concrete return fields (start/end, max_span_days, closed_cells). It is clearly distinguishable from siblings like list_zone_sites and create_alert 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 says 'Call this before setting day_use_cells' and explains why (the season is not exposed anywhere else in the provider's API). It also routes the agent to list_zone_sites for next_release_at, giving a clear when-to-use and an 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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: it defines the three status values, ties them to list_matches' vocabulary, explains status_as_of as 'when we LOOKED', and warns there is no live check. This is exactly the freshness/liveness semantics an agent needs to interpret results correctly.

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 return shape, then the status vocabulary, then the usage note. Dense but every sentence carries meaning; only minor tightening is possible.

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 an output schema present, the description need not explain return values, yet it adds the status semantics and liveness caveat that make the output interpretable. It is complete for invocation, with the only gap being the unclear relation to the get_alert sibling and the alert-vs-itinerary naming.

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 single parameter is documented in the schema (its id comes from list_my_itineraries or create_itinerary). The description adds no parameter-level detail, 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 states precisely what the tool returns: one route with per-night legs, each night's zone, and openings with statuses. It is clearly singular and distinguishable from the list_* siblings, though the verb is implicit (a noun-phrase return description) and the title's 'route alert' wording sits awkwardly against the itinerary_id parameter.

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 explicit context for use — 'This is how to answer "is it still available" — there is no live check' — which tells the agent exactly when this tool is the right call. It does not, however, name exclusions or contrast with the retrieval sibling get_alert, so alternatives remain unaddressed.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered without the description. The description adds domain context (backcountry sold as zones vs numbered sites; entry-date vs nights semantics) but says nothing about the tool's own behavior — no error case for an unknown park_id, no note that missing parks return nothing — so it sits at the baseline-plus level.

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 that gets to the point immediately and then lists only fields that carry decision value (booking URL, zones-vs-sites, backcountry_is_entry_date). The field enumeration is dense but each item earns its place; no filler or restatement of the title.

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?

An output schema exists, so return values need not be explained — yet the description helpfully flags the two fields an agent must interpret (zones-vs-numbered-sites, backcountry_is_entry_date) for downstream alert creation, which is exactly the domain nuance that raw schema text would miss. The only real gap is the missing pointer to how one obtains a park_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?

One required parameter with 100% schema description coverage, though that schema text is only 'Park id.' The description never clarifies where a park_id comes from or what it looks like, so it adds nothing beyond the schema. Per the high-coverage rule, 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 ('Full detail for a single park') and enumerates the salient contents, which cleanly separates it from list-oriented siblings like search_parks, list_park_campgrounds and list_zone_sites. An agent can pick this over those siblings 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?

Usage is only implied: fetching one park's full record when the id is known. No alternative is named (e.g. 'use search_parks to find a park_id'), and no precondition is spelled out. The one useful routing hint is indirect — backcountry_is_entry_date determines whether an alert uses entry_dates or a nights range — but it is framed as a field explanation, not as when-to-use guidance.

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

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

Goes well beyond the annotations: discloses that the site numbers are 'OURS, not the provider's,' that every sheet carries an image_url usable in any client, that the tool cannot report whether the client displayed the image, and that absence of a map resolves to an explicit statement rather than a failure. These are exactly the operational traits 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 (image + coordinates) in the first sentence, which is the right structure. The body is long and mildly repetitive across five paragraphs, but nearly every sentence carries operational substance (naming convention, image fallback, absence handling), so little is pure 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?

An output schema exists, so return values need no prose. The description still covers the hard edges an agent needs — our-not-provider numbering, client display uncertainty, image_url fallback, and non-fatal absence — leaving no material gap for a 4-parameter read tool.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuine meaning beyond the schema by explaining the zone_id vs campground_id interaction ('Where a campground ships one sheet for all its zones, that sheet is returned for any zone within it'), which the schema does not state, and reinforces the round-trip workflow for highlight_site_ids.

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 — returns the drawn site map as an IMAGE plus the pixel position of every site — and immediately distinguishes it from the row-oriented sibling list_zone_sites. An agent can tell exactly what this returns versus what the row data gives.

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 frames the use case as 'questions the rows cannot answer in words: which sites sit by the water, at the end of a loop, away from the road,' names the alternative (list_zone_sites with real lat/lng for geographic inventories), and points to has_map on list_campground_zones for pre-flight checks. When-to-use, when-not, and the alternative are all present.

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, idempotent, openWorld, non-destructive), and the description adds behavior beyond them: it returns the caller's max_sites_per_alert cap and per-zone site_count, warns that park-wide is the wrong size fallback, and clarifies zone-vs-site scope. That is genuinely useful operational context not derivable from structured fields.

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 routing rule, and the sentences each carry information. It is somewhat verbose though: the Sandbanks parenthetical and the beach/quiet-loop examples restate the same zone-vs-site point twice, which dilutes the otherwise tight structure.

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 an output schema present, the description correctly avoids explaining return values, yet still surfaces the one return detail an agent must act on (site caps and site_count for sizing a selection). Combined with the downstream routing to get_zone_map/list_zone_sites/create_alert, an agent has everything needed to call it correctly.

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

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

There is a single parameter with 100% schema description coverage, so the schema already documents campground_id as coming from list_park_campgrounds. The description's 'pass the zone ids in campground_selections' refers to create_alert, not this tool's parameter, so it adds essentially no syntax or format meaning 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 first sentence states the verb and resource implicitly (listing zones within a campground) and immediately frames the granularity distinction from list_park_campgrounds. An agent can distinguish this from the sibling list_park_campgrounds without reading either schema, and the concrete Sandbanks example makes the resource concrete.

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 when-to-use ('Call this before create_alert whenever the user names a part of a park'), an explicit anti-pattern ('stopping at list_park_campgrounds can make a park look like a single undifferentiated site pool'), and named downstream alternatives (get_zone_map, list_zone_sites). This is the full when/when-not/alternatives set.

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, idempotent, non-destructive, openWorld), so the description's added value is the warning that a guessed integer silently selects the wrong option, plus the concrete ID-format example. It does not discuss auth or pagination, but for a read-only lookup that is 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 short, front-loaded blocks: what it returns, when to call it and why it matters, then the length-bracket rule. Every sentence carries information the agent cannot get from annotations or schema.

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?

An output schema exists so return values need no explanation, and the description still covers the ID semantics and the bracket interpretation rule that the output schema alone would not convey well. Nothing needed to call this 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% and both parameters (park_id, provider) are already documented in the schema, including the fact that provider is resolved from the park. The description adds no parameter syntax or precedence detail of its own, 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 ('the equipment vocabulary an alert can filter on, for the park's provider') and describes the exact entry shape (sub_equipment_id, name, kind). An agent knows precisely what this returns and that it is the vocabulary source for an alert filter, distinguishing it from every alert/itinerary sibling.

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 ('Call this whenever the user describes what they are camping IN — a tent, a van, a 30-foot trailer') plus the consequence of skipping it ('You cannot set the equipment filter without it, and guessing the integer sets the wrong one silently'). No sibling actually competes here, so naming an alternative is unnecessary.

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

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive, openWorld), and the description goes well beyond them: matches are point-in-time snapshots, the three status values are defined (rebooked, open_at_last_scan, unverified), and it warns that status_as_of is a look time rather than a live check. It even advises against calling a stored opening bookable because cancellations get rebooked within minutes. This is exactly the extra behavioral context the annotations cannot carry.

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 definition and the polling rationale, then moves to status semantics and finally the site-locating caveat. It is longer than typical, but the length is dense and largely justified by domain-specific status rules; only minor trimming would be possible.

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?

An output schema exists, so return values need not be re-explained, and the description still covers the cursor pattern, status interpretation, and timestamp caveats that an agent needs to use results correctly. Nothing material is missing for a read-only list 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 coverage is 100%, so baseline is 3, but the description adds real meaning for `since`: it is the cursor from a previous call, and omitting it returns recent matches that may already be seen/acted on. That clarifies the trade-off the schema only names. `alert_id` and `limit` are left to the schema.

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

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

States a specific verb and resource ('Openings the user's alerts have found') plus ordering ('newest first'), and frames it as the check-in mechanism for alerts an agent created. An agent can distinguish it from get_alert or list_my_alerts 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?

Explicitly explains why to call it (MCP cannot push, so polling is the only way to learn about matches), how to use it incrementally via `since` cursor, and what happens if you omit it. It also names alternatives for a related need (get_zone_map and list_zone_sites for locating sites), so routing 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?

Adds substantial behavior beyond the annotations: exact quota semantics (total_alerts includes paused/expired, max_total_alerts is a hard cap, remaining=0 makes create_alert fail and pausing does not free a slot), the exclusion of route legs, and the fact that no tool can change a plan. These are precisely the facts an agent needs to avoid mis-summarising or suggesting impossible remedies.

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 purpose and return contents, then uses labeled sections for the disambiguation blocks, so it is easy to skim. The PLAN NAMING and PLAN CHANGES material sits somewhat tangentially on a simple list tool, but each block guards against a plausible agent error and no sentence is purely redundant.

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?

An output schema exists, yet the description still supplies the interpretive context the schema cannot (French 'essai' = permanent free tier, tier_label is the display name, quota counters overlap paused/expired alerts). Nothing needed to call or correctly report on this tool 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?

Only one optional boolean (active_only) and schema coverage is 100%, so the schema already carries the meaning. The description references active status in its field list but adds no filter syntax or default behavior, matching the baseline for fully documented params.

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+scope: the signed-in user's cancellation alerts, ordered newest first, and enumerates the fields each carries (park, date window, nights, active status). It explicitly distinguishes itself from list_my_itineraries and list_routes, which an agent could otherwise confuse it with.

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 concrete routing guidance: 'Check it before summarising what they watch or suggesting something be deleted,' and points to list_my_itineraries for route alerts and quota.route_alerts for counts. Lacks explicit when-not-to-use framing against siblings like get_alert, but the context is clear.

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

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

The annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds substantial operational context: a route counts as ONE quota slot regardless of nights, legs are excluded from alert listings, there is no live availability check, and status_as_of is when the scan LOOKED. That is exactly the kind of behavior an agent cannot infer from annotations or schema.

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

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

Front-loaded with the definition and the sibling exclusion, and the quota and status explanations each earn their place. It is somewhat long with emphatic phrasing ('certainly before', capitalized LOOKED), but no sentence is pure 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?

An output schema exists, so return structure needn't be described, and the description still explains the status vocabulary (rebooked, open_at_last_scan, unverified) and points to status_meaning in the result. Combined with quota semantics and the no-live-check caveat, nothing needed to call or interpret this 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 two optional booleans whose descriptions already explain active_only and include_expired. The description only indirectly touches these (mentioning paused and deleted alerts in the status paragraph), adding little syntax or semantics beyond 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?

States a specific verb and resource — the user's multi-night ROUTE alerts (itineraries) — and defines what a route is (a parent plus one leg per night, each night a different site). It explicitly distinguishes itself from the close sibling list_my_alerts, which 'CANNOT show these', so an agent can pick correctly 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 when-to-call guidance ('call this too before telling the user what they are watching, before counting their quota, and certainly before suggesting they delete something') and names the alternative (list_my_alerts) plus why it fails. Both the trigger conditions and the routing are spelled out.

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, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds useful data-coverage context by naming Parks Canada day use and Recreation.gov permit areas as included sources, but does not disclose anything further about volume, pagination, or how the aggregated sources behave.

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 wasted words, and the scope statement is front-loaded before the conceptual clarification. Slightly fragmentary opening (no leading verb) but efficient overall.

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 an output schema present, annotations covering safety, and a single fully documented parameter, the description only needs to frame scope and the campground/zone/site model — which it does. A pointer to the downstream zone/site tools would make it fully complete, but nothing needed 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 description coverage is 100% for the single park_id parameter, so the schema already documents the only input. The description adds no syntax, format, or identifier guidance beyond what the schema provides, making the baseline 3 appropriate.

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

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

The description states the resource and scope ('Campgrounds within a park') and adds domain semantics — a campground is what an alert watches, while zones and sites are the bookable inventory — which helps separate it from list_campground_zones and list_zone_sites. It lacks an explicit verb in the description body, but the title supplies 'List', leaving the purpose unambiguous.

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

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

Usage is implied rather than stated: the hierarchy note ('its zones and sites are the bookable inventory') hints that an agent should call this before drilling into zones/sites, but no condition or alternative is named explicitly. There is no when-not guidance and no direct pointer to list_campground_zones or list_zone_sites.

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 read-only/idempotent safety, but the description adds non-obvious behavior: an empty list is the normal answer, curated routes skip the adjacency check by construction, and zone-adjacency providers will refuse custom routes unless the trail graph has been crawled. That is context an agent cannot derive from structured fields.

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 before routing guidance and edge cases, and each sentence carries distinct information. It is longer than most list-tool descriptions and slightly overstuffed, but no sentence is 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?

An output schema exists, so return values needn't be explained, and the description still tells the agent how to consume the returned id and how to interpret an empty result. For a read tool with sibling alternatives, 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 description coverage is 100% for both park_id and pets_only, so the schema carries parameter meaning and the baseline of 3 applies. The description mentions a 'variant's id' only as an output value, adding nothing beyond what the schema already documents for the input parameters.

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

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

States a specific verb and resource: pre-planned multi-night traverses for a park, grouped by trail with pace variants. The 'Rockwall, 4 nights' vs 'Rockwall, 3 nights' example makes the unit of return unambiguous and distinguishes it from siblings like get_zone_map or list_park_campgrounds.

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

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

Explicitly says 'START HERE for any multi-night trip,' names the downstream tool (create_itinerary) and the parameter to feed (route_id), and explains what to do when a custom route is refused. When-to-use and what-to-do-instead are both stated, not inferred.

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

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

Annotations already cover readOnly/idempotent/destructive/openWorld, but the description adds substantial behavior: pagination with total exceeding one page, next_release_at semantics and that AlertCamp polls on the drop, year-less repeating seasons that silently never match, and the critical 'absence means UNSTATED, not absent' caveat.

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 resource and its fields, and each paragraph carries distinct operational value (pagination, drop timing, seasons, amenities). It is on the long side and the closing position paragraph partially restates the lat/lng-vs-pixel point made in the opening, costing a point.

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?

An output schema exists, yet the description still gives the agent everything needed to interpret rows and act on them — geometry type, season semantics, sparse attributes, and paging. Nothing material is missing for a read-only 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 coverage is 100%, so baseline is 3; the description earns above that by explaining why offset is needed (zones of hundreds of sites) and by tying lat/lng vs map_x/map_y to whether the inventory is geographic or a drawn sheet. accommodation_type is not elaborated beyond the schema's 'Optional filter'.

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 ('Individual sites in a zone') and enumerates exactly what each row carries (id, number, camp type, position, season, amenity attributes). It is clearly distinguishable from get_zone_map, which it names for the pixel-sheet case.

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 results into create_alert ('pass the qualifying site_ids to create_alert') and names get_zone_map as the alternative for pixel maps. It gives strong conditional context, though it never states an explicit when-not-to-use case for the tool itself.

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 idempotentHint=true and destructiveHint=false, and the description is consistent with both. It adds real behavioral context beyond the annotations: configuration is retained and quota is not freed, plus an expiry qualifier. The 'until it expires' clause is left unexplained, which keeps it from 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?

Three short sentences, zero filler, with the core action and the non-deleting scope front-loaded before the reversibility note.

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?

An output schema exists, so return values need not be described; the safety profile is carried by annotations. The description covers the remaining decision-relevant facts (reversible, config retained, quota impact) for a single-parameter tool.

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

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

Schema description coverage is 100% and the alert_id description already names its source (list_my_alerts or create_alert). The prose adds no parameter-level detail 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 specific verb+resource ('Stop monitoring' of an alert) and immediately scopes it against the nearest sibling with 'without deleting'. An agent can distinguish pause_alert from delete_alert and resume_alert 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?

Names the reversal path explicitly ('Reversible with resume_alert') and implicitly steers away from delete_alert via 'without deleting'. It gives clear context but never states an explicit when-not-to-pause condition or prerequisite.

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

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

Goes well beyond the annotations: it discloses that no scanning or notification occurs regardless of each alert's is_active, that configuration is unchanged, and — crucially — that the pause is SILENT, so the user sees alerts listed normally but hears nothing. That silent-failure mode is exactly the kind of behavior an agent cannot infer from readOnlyHint/idempotentHint 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?

Three short paragraphs, front-loaded with the master-switch framing before the sibling comparison and the silent-behavior warning. Slightly verbose in the closing clause, but each sentence adds a distinct fact 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?

For a zero-parameter mutation with annotations and an output schema present, the description covers scope, effect on the scheduler, reversibility, config immutability, and the silent-observability caveat. Nothing material is left for the agent to guess.

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 no parameters, so per the rubric the baseline is 4; there is no parameter surface the description needs to compensate for.

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

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

Names a specific action and scope: the account-wide master switch that pauses everything, with the mechanic spelled out (scheduler skips the account entirely, overriding per-alert is_active). It explicitly distinguishes itself from the sibling pause_alert by calling itself 'the whole account, not one alert'.

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 when-to-use (end of a season, a trip booked — user is done looking) and an explicit when-not (not a way to quieten one noisy alert, use pause_alert instead). It also names the reverse operation, resume_all_alerts.

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 it a non-destructive, idempotent, open-world mutation, and the description adds value beyond that: it discloses reversibility via resume_itinerary and an atomicity requirement ('has to be atomic or the route keeps polling some nights'). The rationale is useful though awkwardly worded.

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 and the guidance (reversibility, sibling exclusion) is packed in, but the em-dash sentence is convoluted and the opening clause ('parent and every night together') is opaque, so structure is only adequate.

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 an output schema present, return values need no explanation, and the annotations carry the safety profile. The description supplies reversibility and routing context, leaving little an agent needs that is missing, though the semantics of 'atomic' pausing could be spelled out more clearly.

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 a single fully documented itinerary_id, so the schema does the heavy lifting. The description adds no syntax, format, or sourcing detail for the id beyond what the schema already states, 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 states the core action ('Stop watching a route') and the tool name plus sibling set make clear this pauses an itinerary route alert rather than an alert. However, the cryptic clause 'parent and every night together' muddies what exactly is being paused, so it is clear but not crisp.

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 away from a sibling: 'pause_alert does NOT work on a route,' implying this tool is the correct one for routes. It also names resume_itinerary as the inverse operation. No explicit when-to-pause guidance beyond that routing distinction.

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 idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait the annotations cannot express: resuming re-checks quota and may be refused if the tier is now full, which tells the agent to expect a possible failure path.

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 zero filler; the core action is front-loaded and the caveat follows immediately. 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?

With an output schema present and annotations covering idempotency and safety, the description only needed to add behavioral context, and it flags the quota-refusal path. It does not state that the alert must currently be paused or how a refusal surfaces, but those are minor omissions for a single-parameter 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?

Only one parameter exists and schema description coverage is 100% – the schema already explains that alert_id comes from list_my_alerts or create_alert. The description adds nothing about the identifier, 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 states a specific verb+resource ('Resume monitoring') and the title pins it to 'a paused alert', which separates it from resume_all_alerts and resume_itinerary. However, 'monitoring' alone is slightly abstract and the description never explicitly names the alert as the resumed object, so it relies on the title to close the gap.

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

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

Usage is implied by the verb (resume a paused alert) but the description gives no explicit when-to-use or when-not-to-use guidance, and does not route the agent to pause_alert, resume_all_alerts, or update_alert as alternatives. The refusal condition is a precondition, not usage 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?

The description adds substantial behavior beyond the annotations: openings found during the pause are NOT replayed, the first cycle after resuming is deliberately suppressed, and each alert retains its own is_active so individually paused alerts stay paused. These are exactly the non-obvious effects an agent could not derive from readOnlyHint/idempotentHint 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?

Three short, dense sentences with no filler, and the most decision-relevant surprise (no replay of paused openings) is front-loaded after the effect statement. The misleading 'back off' phrasing in sentence one is the only structural weakness.

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 annotations covering the safety profile and an output schema handling return values, the description supplies the behavioral caveats it must. The remaining gap is routing: it never states that this is the account-wide counterpart to pause_all_alerts rather than resume_alert.

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 is no schema content for the description to enrich or duplicate, and it correctly says nothing about nonexistent 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 second clause states the concrete effect — 'its alerts are scanned again' — and the scope ('account's', 'every alert' in the title) distinguishes it from the single-alert sibling resume_alert. However, the lead sentence 'Turn the account's master switch back off' is confusingly worded for a resume operation and briefly reads as the opposite of the tool name, which costs it a 5.

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

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

Usage is only implied: an agent infers this is the counterpart to pause_all_alerts and that there must be a prior pause, but no sentence says when to choose this over resume_alert or pause_all_alerts. No prerequisites or exclusions are stated.

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

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

Annotations already declare idempotentHint=true, openWorldHint=true, non-destructive and non-readOnly, so the safety profile is covered. The description adds no behavioral context beyond repeating 'start watching' – it doesn't say what resuming affects, whether alerts/notifications restart, or what side effects occur.

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. It is concise, though it could trade some brevity for the missing precondition and side-effect detail.

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

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

Against an output schema and full annotation coverage, the description is adequate only in the narrowest sense. It omits the paused-state precondition, side effects of resuming, and routing to sibling resume/pause tools, leaving real gaps for a state-changing 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 coverage is 100% and the itinerary_id parameter is fully documented in the schema, including where to obtain it, so the description needn't repeat it. Baseline 3 applies; the description adds no additional parameter meaning.

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 ('Start watching ... again') and resource ('a paused route'), distinguishing it from pause_itinerary and resume_alert by naming the paused-route scope. However, it conflates 'route' with 'itinerary' terminology used by the schema and siblings, which blurs the object it acts on.

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

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

No when-to-use guidance, no prerequisites, and no reference to alternatives like resume_alert or resume_all_alerts. It also fails to state that the target must currently be paused, which is the essential precondition.

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, idempotent, openWorld and non-destructive, so the description needn't restate safety. It instead adds behavioral semantics beyond the annotations: the meaning of backcountry_is_entry_date (sells an entry date, not nights) and DayUse in camp_types (parking slots, shuttle seats, daily vehicle permits). Return fields are covered by the output schema, so no credit needed there.

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 purpose and return shape, then a usage pointer, then two tightly scoped field-semantics notes. Every sentence carries information; the only mild cost is that the two trailing flag explanations are somewhat abruptly attached without connective framing.

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 an output schema and full annotation/schema coverage, the description supplies what structured fields cannot: how returned flags change downstream tool calls. Pagination behavior beyond the documented limit default is not addressed, which is a minor gap for a paginated search.

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 meaning beyond the schema: it explains that a DayUse value in camp_types indicates day-use inventory requiring day_use_cells, and that backcountry_is_entry_date changes alert semantics. That is semantic context the enum list alone does not convey.

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

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

States a specific verb and resource ('Find parks by name') plus scope ('across every supported provider') and enumerates what distinguishes coverage (Canadian provincial/federal plus US Recreation.gov, UseDirect, AspiraOne). This separates it cleanly from get_park (by id) and list_park_campgrounds (per park).

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 clear downstream routing ('Use the returned park id with the other tools') and explicitly names which tools consume which field semantics (create_alert's entry_dates, day_use_cells). It does not explicitly say when to prefer this over get_park or list_park_campgrounds, so it stops short of full when/when-not guidance.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description supplies the 'why': narrowing silently drops anything not listed, selections can only shrink so a growth edit would circumvent quota pricing, and SMS notifications cost real money and are silently dropped off-tier. It also states the omit-vs-null mutation contract, which is the core behavioral rule for a partial-update 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?

Well front-loaded — purpose, then alternatives, then the narrowing constraint, then the omit/null rule — and every paragraph earns its place. It loses a point for mild repetition between the delete-and-recreate warning in paragraph two and the same remedy restated at the end of paragraph three.

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 22-parameter partial-update tool with an output schema (so return values need no explanation) and full schema coverage, the description covers the remaining unknowns: mutation semantics, the narrowing-only invariant, quota and slot side effects, and the cost/silent-drop behavior of notification channels. Nothing needed 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 description coverage is 100%, so the baseline is 3 and the schema already carries field meanings. The description adds genuinely new semantics the schema lacks: the union-wide 'omit to leave alone, null to clear' rule and the hard constraint that campground_selections may only narrow and never change the park.

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

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

The opening sentence gives a specific verb and resource ('change an existing alert'), and the 'instead of replacing it' qualifier immediately separates it from delete-and-recreate and from create_alert in the sibling set. The follow-on sentence enumerates the editable field families, so an agent knows the scope 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?

Explicit when-to-use against two named alternatives: prefer this over delete-and-recreate (preserves scan history and odds, avoids an unwatched gap) and over a second alert (slot and 100-alert cap costs). It also gives the correct escape hatch when the user needs MORE coverage — create a second alert or delete-and-recreate — closing the loop rather than leaving the agent stuck.

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=false, destructiveHint=true, and idempotentHint=true, so safety and idempotency are covered. The description adds important runtime context not in annotations: that nights are validated as a whole and cannot be edited in isolation, and that window_start/window_end must be sent together or they are merged with stored values. This is valuable, but it doesn't discuss reversibility or failure modes beyond the merge behavior.

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

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

The description is front-loaded with the purpose, then the key constraint (nights), then the recommended action (window edit). It's three paragraphs and mostly earns its place, though the 'say that is what you did' instruction could be seen as slightly procedural. Still efficient for the amount of useful guidance conveyed.

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 an 8-parameter mutation tool with full schema coverage, an output schema, and rich annotations, the description covers the critical behavioral nuances (night immutability, window merge behavior) without needing to explain the return shape. The only gap is that it doesn't mention the destructiveHint implications or any permission requirements for notify channels beyond what the schema says, but those are largely covered in the schema descriptions.

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 meaning beyond the schema by explaining the interaction between window_start and window_end (must be sent together, one alone is merged and may leave the window too short) and by characterizing widening the window as the most useful edit. That's real semantic guidance not captured in schema descriptions.

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

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

The description opens with a specific verb and resource ('Change a route's window, party size, tent pads or notification channels') and distinguishes the tool from the sibling update_alert. It also explicitly names what it cannot edit (nights), which sharpens the boundary against related tools.

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

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

The description gives explicit when-to-use and when-not-to-use guidance: nights cannot be edited and the user should delete and recreate instead. It also recommends a workflow ('say that is what you did') and highlights the highest-value edit (widening the window), which is actionable guidance an agent can follow.

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