Boat Day

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

Annotations already declare readOnly, idempotent and closed-world, so the safety profile is covered. The description adds real value beyond them: the returned band structure, an attached method and confidence, and a disclaimer that this is not a formal appraisal — a material behavioral/legal constraint 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?

Two tight sentences, front-loaded with what the tool returns and followed by the accepted input combinations. No filler or repeated schema content.

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

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

For a seven-parameter, all-optional estimation tool with no output schema, the description covers output shape, input alternatives and scope limitations well. It does not say what happens when no valid input combination is supplied (error vs. degraded estimate), which is the 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 each parameter is already labeled, giving a baseline of 3. The description goes further by stating the alternative OR-combinations of parameters, which the schema (all optional, zero required) cannot convey on its own.

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

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

The description names a specific verb and resource ("used-boat value estimate") and even previews the output shape (low/mid/high band with method + confidence). It is distinguishable from siblings such as estimate_total_cost_of_ownership, though it never names them explicitly.

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 concrete invocation paths — modelId, or make+model+year, or loaFt+boatType, or a HIN — which tells the agent how to call it with whatever data is on hand. It adds a scope caveat ("Educational, not an appraisal") but offers no explicit when-not-to-use or sibling 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 declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so 'side-effect free' is largely redundant. The description does add real context beyond annotations by listing the cost categories included in the calculation and stating results come back 'as bands', which matters since there is no output schema — but it never explains what a band is (range, confidence interval, low/high).

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 compact sentence, front-loaded with the computed quantity and the cost components, closing with the output form and safety note. No filler or repetition of the name.

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

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

For a tool with ten optional parameters, no required fields, and no output schema, the description covers what is computed but not how to call it well: no statement of behavior with zero parameters, no unit/currency or region-vs-state precedence guidance, and 'bands' is left undefined. Adequate but with clear gaps an agent would have to probe.

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 ten parameters are already documented and the baseline is 3. The description adds only indirect mapping — depreciation implies purchasePrice, hold-period implies holdYears, fuel implies hoursPerYear — but gives no guidance on defaults, which inputs dominate, or which are optional-but-recommended.

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 computation (annual and hold-period total cost of ownership) and enumerates the cost components included (storage, insurance, maintenance, fuel, fees, depreciation), plus the output form ('as bands'). That clearly separates it from the value-oriented sibling estimate_boat_value, though no sibling is named explicitly.

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: 'annual + hold-period' signals that holdYears drives the second figure and that this is an estimate/planning tool. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as estimate_boat_value or get_seacoast_costs for simpler cost lookups.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: it explains a data-provenance distinction (public-web listings vs. partners/endorsements) and discloses that the founding partner roster is currently empty, which prevents the agent from overstating results.

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

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

Three short sentences with zero filler, and the resource list is front-loaded so the agent knows scope immediately. The closing sentence about the empty partner roster is terse to the point of being slightly opaque, but it is still efficient.

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 six-parameter, fully optional lookup with no output schema, the definition covers result provenance and a key caveat, but it never explains the shape of returned entries, how partner vs. outbound records differ structurally, or how this tool relates to find_yards and get_yard. Adequate but with visible gaps.

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

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

Schema description coverage is 100%, so all six parameters (q, limit, state, region, category, waterway) are already documented, including a category slug example. The description adds no additional syntax, format, or interaction rules for parameters, 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?

Opens with a specific verb and an enumerated set of resources: "Find marinas, yards, surveyors, insurers, suppliers." That is far more concrete than the tool name alone. It does not, however, distinguish itself from the sibling find_yards, even though 'yards' is one of its own categories, leaving overlap for the agent to resolve.

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 clear guidance on how to present results — outbound 'Find them online' entries must be flagged to the human for verification — which is genuinely useful usage context. It never states when to choose this tool over find_yards or get_yard, nor any exclusions, so routing guidance is only implied.

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

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

Annotations already declare this a read-only, idempotent, closed-world search, so the description correctly spends its budget on data semantics: winterStoragePrice is a yard-confirmed 2026–27 price carrying confirmed_at and verification_event_id, or null when unconfirmed. That provenance detail is genuinely additive and tells the agent not to treat null as a missing-data error.

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 scope and the confirmed/null price rule are front-loaded, which is the right ordering. The closing sentence stacks three guide references, which is useful routing but the densest part of the definition; the whole thing remains tight with no filler.

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

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

With an output schema present, the description needn't document return values, and it covers the one thing the schema cannot: the meaning of the null-vs-confirmed price field. Annotations, schema, and description together leave nothing an agent needs 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 the baseline is 3, but the description adds real meaning for the confirmed flag by defining what 'confirmed' means (yard-confirmed price with confirmed_at and verification_event_id) rather than just restating the field label. Other parameters (q, limit, region, category) are left entirely to the schema.

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

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

Opens with a specific verb and resource plus geographic scope: 'Find Seacoast ME–NH and Casco Bay boatyards, marinas and storage'. The parenthetical '(public-web listings, not partners)' distinguishes it from sibling find_boating_businesses, and the singular/plural naming makes clear it is the list counterpart to get_yard.

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 agents elsewhere for adjacent needs: posted prices to get_seacoast_costs or the winter-storage guide, ramps and tides to two named guides. It does not explicitly state when to call get_yard instead, but the list-vs-single distinction plus the named alternatives give clear context.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is covered. The description adds value annotations cannot: it discloses the fields returned (burden flags, TCO estimate band, Quality Boat Day notes, canonical URL), which matters because there is no output schema. It stops short of stating absence/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?

One sentence, front-loaded with verb and resource, then a tight colon-delimited list of return contents. No filler, no repetition of the tool name, and the most decision-relevant information (single model, by id) comes first.

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-record getter with a fully documented one-parameter schema, the description covers what an agent needs: identity of the resource, the input, and the shape of the return. The enumeration of returned fields compensates for the missing output schema; only failure/absence handling is unaddressed.

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 'id' parameter is already documented as coming from search_boat_models. The description only restates that a single id is required, adding no format, validity, or provenance detail beyond the schema. Baseline 3 applies 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 ('Get one boat model by id') and enumerates the payload (specs, burden flags, TCO estimate band, Quality Boat Day notes, canonical URL). The singular 'one ... by id' framing implicitly separates it from search_boat_models, but it never names that sibling explicitly, so the differentiation is inferred 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?

The 'by id' phrasing implies a follow-up lookup after a search, and the schema notes the id comes from search_boat_models. There is no explicit when-to-use or when-not guidance, and no signal about what to do if the id is unknown or the model is absent.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds that params are passed through to pre-fill the target tool, which is useful behavioral context. It does not state what the returned link looks like, whether validation occurs, or what happens when params do not match the target tool.

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

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

The description is two compact sentences with no filler. The primary action is front-loaded, and the enum list and param examples are presented directly without unnecessary prose.

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 link-builder with no output schema, the description covers the main action and target tools. It leaves gaps around the return value, since it only implies a deep link is returned, and around how params map to each target tool. These gaps matter because params is a free-form nested object.

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

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

Schema description coverage is 0%, so the description must carry the burden. It repeats the tool enum already present in the schema and gives examples of pass-through params such as hin, modelId, make, model, year, category, and state. It does not explain which params are meaningful for which target tool or how the nested params object is validated.

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

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

The description states a specific verb and resource: "Build a deep link" that sends a human to a pre-filled Boat Day tool. It enumerates the supported target tools, making the purpose clear. It does not explicitly contrast this handoff-link builder with sibling data tools such as estimate_boat_value or get_boat_model, so it stops short of full sibling differentiation.

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

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

The phrase "sends a human straight to a pre-filled Boat Day tool" implies this is for human handoff rather than direct data retrieval. However, there is no explicit when-to-use or when-not-to-use guidance, and no stated alternative for agents that need the underlying data themselves.

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

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

Annotations already declare readOnlyHint, idempotentHint, and closed-world, so the safety profile is covered. The description adds genuine behavioral context by explaining the two response modes (overview vs. single checklist's items). It does not describe output shape, ordering, or how 'stage' affects results.

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

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

Two tight sentences with the resource named first and the parameter behavior front-loaded. The compact 'stance/pillars' phrasing is slightly cryptic but no sentence 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 two-parameter, read-only, output-schema-less tool, the description covers the main mode switch but leaves the return structure vague ('items') and the stage filter unexplained. An agent can call it correctly by omitting or supplying slug, but cannot predict what it will get back in much detail.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning for 'slug' (it selects one checklist and returns its items) but says nothing about 'stage' beyond the schema's bare 'Ownership stage filter', leaving the filter's accepted values and effect unexplained.

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

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

The description names the resource (boating safety stance/pillars and checklists) and the concrete checklist types (pre-departure, winterize), and its second sentence explains the mode switch. It is clear enough to distinguish from siblings like get_state_boating_rules or search_guides, though the pairing of 'stance/pillars' with 'checklists' under one tool is a bit muddled.

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 through the 'Pass slug for one checklist's items' sentence: omit slug for the overview, supply slug for a specific checklist. There is no explicit when-to-use versus siblings, no mention of what the 'stage' filter is for, and no guidance on when this beats get_state_boating_rules.

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, closed-world), so the description's job is to add contextual behavior, and it does: prices carry source_url and the date read, some are yard-confirmed versus merely posted, and results are advisory rather than binding quotes. That disclaimer and provenance information materially affect how an agent should present results. It stops short of describing pagination or how many yards are typically covered.

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 resource and scope are front-loaded, followed by the advisory caveat and the parameter hint. It is dense with parentheticals and the trailing guide-URL sentence is long, but each part carries information an agent would otherwise have to guess. Minor tightening is possible rather than necessary.

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 still flags that each price record carries source_url and read date. With the advisory caveat, the filter explanation and a pointer to explanatory material, an agent has everything needed to call and interpret this tool correctly.

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

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

Schema coverage is 75%, and the description adds real meaning beyond it: loa_ft is not just a length filter but the trigger for per-foot arithmetic, and the service types are enumerated in prose (storage, winterize, haul, spring commissioning). The state and yard_id filters are not explained at all, leaving those to the schema.

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

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

The description names a specific resource and scope: posted storage, winterize, haul and commissioning rates for Seacoast ME–NH yards, plus yard-confirmed storage prices. That is far more precise than the tool name alone. It does not explicitly differentiate itself from neighbors like find_yards, get_yard or estimate_total_cost_of_ownership, which keeps it from a 5.

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

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

Usage is implied by the resource description: call it when you want winter-job pricing for a yard or region. The only explicit guidance is 'Advisory, not quotes' and 'Pass loa_ft to filter by boat length,' which is parameter instruction rather than when-to-use/when-not-to-use advice. No sibling alternative is named, so an agent must infer that find_yards handles discovery and this tool handles pricing.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description adds a real behavioral fact the schema cannot convey: omitting the code returns an index rather than erroring or defaulting to a single state. It does not describe response shape or whether results are cached/static, but for a read-only lookup the mode disclosure is the material item.

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, front-loaded sentences with no filler; the content list comes first and the mode instruction second. Nothing is wasted, though the sentence is a fragment and could have used a verb to make the action unambiguous.

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, annotation-covered, read-only lookup with no output schema, the description covers what is returned topically and how the absent-parameter case behaves. An agent has enough to call it correctly; only the exact return structure is unstated, which is a minor gap given the listed content categories.

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 ('code') is already documented with an example ('NH'). The description's 'omit code for the index' adds meaning about the optional case that the schema does not state, but it gives no format guidance or error behavior for invalid codes, so it sits at the baseline-plus level.

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

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

The description names the resource (US state boating rules) and enumerates the specific content covered: registration, titling, boater education, BUI, PFD notes, agency links. That is enough to distinguish it from siblings like get_safety_checklists or get_waterway. It lacks an explicit verb ('retrieve'/'look up'), which keeps it just short of 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?

The only usage instruction is 'Omit code for the index', which usefully explains the no-parameter mode. There is no statement of when to prefer this over the other lookups (get_waterway, get_safety_checklists) or any prerequisite context; the sibling separation is implied by the topic list rather than 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 readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds useful substance by naming the content categories returned (seasonality, hazards, ramps/marinas, playbooks), but says nothing about result shape, whether a passed slug that doesn't exist errors or returns empty, or how large the list response is.

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

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

Two sentences, zero padding, with the mode-switching rule placed last where it is easy to act on. The example slug is embedded rather than given its own sentence, which keeps it tight.

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

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

For a single-parameter, read-only lookup with no output schema, the description covers the essential question of what the agent gets back and how to get the overview list. The only missing piece is failure behavior for an invalid slug, which is minor at this complexity.

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 goes beyond the schema's bare "Waterway slug": it shows the slug format via an example (piscataqua-seacoast) and explains the meaning of omitting the optional parameter entirely, which the schema does not state.

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 gives a specific resource (waterways) and enumerates the content returned: seasonality, hazards, ramps/marinas context, playbooks. It even includes a concrete example slug, so an agent knows what the tool resolves. It stops short of a clean verb-first statement ("Focus waterways" is loose), but no sibling tool overlaps, so differentiation isn't needed.

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?

"Omit slug for the list" is a genuine usage rule that tells the agent how to switch modes, which is real guidance. Beyond that there is nothing about when this tool is the right choice versus get_state_boating_rules or get_safety_checklists, both of which touch adjacent regulatory/safety content.

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 read-only, idempotent, closed-world lookup, and the description does not contradict them. Beyond that, it discloses the meaningful behavioral nuance that winterStoragePrice is 'yard-confirmed, or null when unconfirmed' — a null-semantics warning the schema and annotations do not convey, and one that prevents the agent from treating null as an error or as zero. It does not discuss any not-found behavior for a bad id, 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?

One sentence, front-loaded with the verb and resource, with the routing hint and return-field detail packed into parentheses rather than separate clauses. No sentence is redundant against the schema or annotations.

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

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

For a single-parameter lookup with an output schema present and read-only annotations, everything the agent needs is present: the id source, the resource identity, and the one field whose semantics are ambiguous (nullable winterStoragePrice). No further explanation of return shape is required because the output schema carries it.

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 worked example ('meta-great-bay-marine'), so the baseline is 3. The description adds genuine provenance for the single required id parameter — that it must originate from find_yards — which is meaning the schema does not express and which prevents guessed or fabricated 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 ('Get one yard listing by id') and immediately identifies the sibling that produces valid ids ('from find_yards'), so the agent can separate this lookup from the search tool without opening either schema. It also names the returned fields (website, phone, source note, winterStoragePrice), which sharpens what 'a yard listing' actually contains.

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

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

The parenthetical 'from find_yards' encodes the prerequisite: this tool is the second step after a yard search has yielded an id. It stops short of stating when-not to use it (e.g. that it is not a search or bulk-fetch endpoint), so it is clear context rather than a full use/exclude matrix.

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

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

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is carried structurally. The description adds nothing behavioral beyond that: it doesn't say what happens with an empty query, whether results are ordered by date, whether an 'upcoming' default exists, or how filters combine.

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 terse fragments, no filler, with the content scope front-loaded before the filter list. It is efficient, though the telegraphic style borders on under-specification rather than elegant brevity.

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

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

For a nine-parameter search tool with zero required parameters and no output schema, the description covers what to filter on but not the defaults that matter: result ordering, behavior with no filters supplied, and what a result record contains. It is minimum viable rather than 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 89%, so the schema already documents nearly every parameter, and the description merely restates the filter names (q, state, region, type, waterway, from/to, upcoming) without adding meaning. Useful details such as whether 'q' searches name only or description too, or whether filters AND together, are absent.

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

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

The description names the resource concretely by enumerating the event categories covered (boat shows, regattas, safety courses, rendezvous), which tells an agent exactly what records this tool searches. It does not differentiate from siblings such as find_boating_businesses or search_guides, but the domain scope is unambiguous.

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

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

The description gives no when-to-use guidance, no prerequisites, and no named alternatives, even though the sibling list contains several other search tools an agent could confuse it with. The only implicit usage hint is the 'upcoming' flag, which suggests limiting to future events but never states it as guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so safety is covered. The description earns credit for disclosing that specs are demo/educational and flagged demoData, a data-quality caveat not present in structured fields. It says nothing about result ordering, pagination beyond the schema's default 25, or what an empty result set looks like.

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

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

Two compact fragments, with the corpus scope front-loaded before the filter list. The trailing field enumeration is slightly redundant with the schema but is short and scannable.

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 8 optional parameters and no output schema, the description should say roughly what comes back (a list of model records with demoData flags) and what happens with no filters. It covers scope and facets but leaves the return shape and default-call behavior to inference.

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 88%, so the schema already documents q, type, brand, length bounds, propulsion and trailerable. The description merely restates the same field names and adds no format or matching-semantics detail (e.g. whether q matches brand+model, whether type is an exact id). 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 gives a specific verb and resource ('Search the Boat Day boat model graph') and scopes the corpus to US recreational models, which clearly separates it from the singular 'get_boat_model' sibling by implication. It stops short of explicitly naming the sibling or stating that a single-model lookup belongs elsewhere.

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 facet list ('Filter by q, type, brand, length, propulsion, trailerable'), which tells an agent this is the multi-result browse tool. However there is no explicit when-to-use statement, no mention of when to prefer get_boat_model, and no note that an unfiltered call returns the default page of results.

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

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

The annotations already declare readOnlyHint, idempotentHint, and openWorldHint=false, so the safety profile is fully covered. The description adds the return shape (titles, summaries, canonical URLs), which is useful, but says nothing about result ranking, pagination, or what happens when filters conflict—minor gaps for a simple read 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?

Two sentences, zero waste, with the resource and scope front-loaded and the return fields stated second. Nothing is redundant with the name or with structured fields.

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

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

For a four-parameter, non-destructive search tool with no output schema, the description covers purpose, topical scope, and return fields—enough for an agent to call it correctly. The remaining gap is the semantics of the stage and category filters, which neither the description nor the schema resolves.

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. However, the schema's own parameter descriptions are thin ("Stage id", "Category"), and the description does not clarify what a stage id means or how category relates to the parenthetical topics, so it adds no compensating 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?

The description gives a specific verb+resource ("Search Boat Day ownership guides") and illustrates the topical scope with parenthetical examples (buying, winterizing, insurance, docking, weather). This distinguishes it from siblings like search_boating_events and search_boat_models, though it never names those siblings explicitly, so the differentiation is inferred 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?

Usage is only implied: an agent can infer it should call this for ownership-guide content, but the description says nothing about when NOT to use it or which sibling to prefer for adjacent queries (e.g., safety checklists or state rules). It also gives no guidance on combining or omitting the stage/category filters.

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