Experience Bamfield

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

Annotations already establish readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real behavior beyond that: the call validates the cart and reports which lines open, which would be left out and why, and the totals. It also discloses the downstream flow (guest pays by card, booking confirmed at payment), which tells the agent the link itself is not the booking.

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

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

Four sentences, front-loaded with what the tool produces, then its validation output, the guest flow, and finally the critical charter carve-out. Every sentence carries information; the only slack is the full domain name, which is arguably needed to identify the generated link.

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 details need not be spelled out, yet the description still summarizes what the check yields. Annotations cover the safety profile, and the description supplies the two things structured data cannot: the guest hand-off flow and the charter exclusion. Nothing an agent needs before calling is missing.

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

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

The reported schema description coverage for the top-level parameter is 0%, and the description only refers obliquely to 'the chosen lines' without describing the line object or the required productId/startDate/endDate trio. The nested item schema does document fields like guests, quantity, endTime and boatLengthFt, which mitigates the gap, and the description adds the useful semantic that some submitted lines may be dropped. That is enough to clear the floor but does not compensate for the reported coverage gap.

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

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

The description names a specific verb and artifact ('Builds the one link that puts the chosen lines in the guest's cart on experiencebamfield.com') and states the tool also validates the result. The deliverable ('Give the guest the url') is unambiguous and clearly distinct from quote/price siblings. It does not, however, name any sibling tool it should be chosen over.

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 a clear usage context (hand the url to the guest, who reviews and pays by card) and a genuine exclusion: a fishing charter is not carried by the link and is added from its own page. It stops short of naming an alternative tool for that case (e.g. quote_trip or get_trip_summary), so the routing is not fully closed.

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 carry the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower. The description adds genuine behavioral context by disclosing that a permit is informational rather than a purchasable cart item. It omits ordering/permission details, but with annotations covering safety this is solid.

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 dense topic sentence plus a short clarifying exclusion; no filler. The opening is a topic list rather than a front-loaded statement of what the tool does, which slightly blunts the lead.

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 annotations cover safety. The topical enumeration sets expectations adequately for a zero-parameter lookup, leaving little an agent still needs to know.

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 schema has nothing for the description to compensate for — baseline 4 applies. Nothing in the text misrepresents the parameterless nature of the call.

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?

Enumerates exactly the permit facts it returns (where needed, issuer, cost, max stay, processing time, sites, application location), which makes its resource clear. It also distinguishes itself from the cart-building siblings by stating 'The permit is not a line in the cart.' No explicit verb, but the 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?

Usage is implied: consult this when a guest asks about camping permits. The only stated boundary is the negative 'not a line in the cart,' which steers away from build_cart_link but doesn't say when or when not to call it versus check_availability or get_product.

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, non-destructive and closed-world, so safety needs no restating. The description adds real behavioral context beyond them: per-day granularity and the counting semantics (units left; for moorage, feet free and longest boat that fits). It stops short of noting limits such as max range or pagination, so it is not a full 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?

Two sentences, no filler, and the capability statement is front-loaded before the alternative routing. The first sentence is dense with parentheticals, which costs a little readability, but nothing is wasted.

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

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

With an output schema present, the description need not explain return shape, and it covers scope, counting semantics, and routing. Minor ambiguity remains around products where nothing is 'counted' and around the boatLengthFt requirement, but overall it is sufficient to call the tool correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining what the counts mean per product type and by tying the moorage case ('feet free and the longest boat that fits') to the otherwise thin boatLengthFt parameter.

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

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

The description states a concrete operation (day-by-day availability across a date range) plus what is returned per day, and explicitly distinguishes itself from the sibling quote_trip. An agent can tell immediately that this is the range/calendar tool, not the point-quote tool.

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

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

It names the alternative (quote_trip) and the exact condition that selects it: a yes/no on exact dates plus a unit count. The day-by-day-between-two-dates framing defines the condition for using this tool by contrast, 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is fully covered structurally. The description adds no behavior beyond that — no auth requirements, error/not-found behavior, or performance notes — but it also does not contradict anything. It provides only the content scope, which is adequate given the annotation coverage.

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

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

A single front-loaded sentence with no filler or preamble. It is slightly long because it enumerates return fields that the output schema already defines, but every clause is on-topic and readable.

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?

Since an output schema exists, the description does not need to enumerate return values — yet nearly all of it does exactly that, making it somewhat redundant. What is actually missing is usage context relative to list_products and check_availability. It is adequate for a simple single-record lookup but not 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?

With one parameter at 100% schema description coverage, the schema fully documents productId, including its format pattern and the note that it comes from list_products. The description adds no syntax, origin, or constraint detail beyond the schema, so the baseline of 3 is correct.

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

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

The title and description make clear this returns the full detail record for a single product, enumerating the specific content areas (description, amenities, rules, rate table, photos). It is distinguishable from list_products by its singular scope. It stops short of explicitly stating the verb-with-ID relationship or naming the sibling it complements, so it is clear rather than differentiating.

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

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

There is no when-to-use guidance: nothing says to call this after list_products to drill into a chosen product, nor when get_trip_summary or check_availability would be preferred instead. The 'product id from list_products' hint lives in the schema, not the description, so the description itself offers no routing 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?

Goes well beyond the readOnly/idempotent annotations: it discloses return semantics ('unknown' for unknown facts, null for unstatable amounts, never read as yes/no/0), freshness via staleAfterSeconds, that no names or contact details are included, that nothing can be changed, and what happens with wrong/expired/disabled links. This is precisely the extra context 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 key framing ('After the booking.') and each sentence carries distinct operational information, but the money clause is a long run-on list and the overall prose is dense. Efficient in content, slightly heavy in delivery.

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 lookup with an output schema, the description still supplies everything an agent needs: freshness guidance, null/unknown interpretation rules, the not_reconciled escalation instruction, and the refusal behavior for bad links. No material gap remains.

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 are already well described in the schema (whole link format, 43-character key, 'send this or key'). The description restates the either/or choice but adds no format or validation 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 and resource ('returns a read-only summary of that one trip') and enumerates exactly what is returned — readiness, tasks, deadlines, booked lines, and money movements. The 'After the booking' framing cleanly separates it from pre-booking siblings like quote_trip without needing 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?

Gives clear timing context ('After the booking') and an operational habit ('Read it again each time you are asked'), which tells the agent when to call and how often. It does not explicitly name an alternative tool or state when this one should not be used, so it falls short of a full when/when-not treatment.

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, non-destructive, and closed-world, so the safety profile is fully covered. The description adds only that each photo carries a description and an address, which is output content also available in the output schema, plus it says nothing about auth, limits, or ordering. Modest added value over the 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?

One front-loaded sentence with no filler. It loses a point because the trailing phrase 'an address that can be shown to the guest' is vague and reads as a stray detail rather than useful information.

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

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

With an output schema present the description needn't explain return values, and annotations cover the safety profile, so the tool is callable as-is. Still, the tool is described as a bare noun phrase with no statement of the retrieval operation and no usage context, leaving gaps the structured fields do not fill.

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 'business' parameter, including a format example and source ('from list_products'), so the schema carries the semantics. The description adds no parameter detail at all, which is the expected baseline 3 when the schema does the heavy lifting.

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

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

The description names a specific resource (photographs of a business and its products) and what each item contains, which combined with the name list_photos makes the retrieval action clear. It does not differentiate from any sibling, though no sibling appears to cover photos either, so the ambiguity risk is low.

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 mention of alternatives. The only hint about context ('business slug from list_products') lives in the schema, not the description, so an agent gets nothing from the prose about when this tool is the right call.

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

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

Annotations already declare the read-only, idempotent, non-destructive, closed-world profile, so the safety bar is met structurally. The description adds genuine behavioral context by listing what each record contains and by disclosing the important caveat that a cottage's price depends on dates, which steers the agent away from trusting the returned price for cottages.

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

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

Two sentences, front-loaded with the verb and the inventory it exposes, followed by the routing instruction. Every clause earns its place; no filler or repetition 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 still previews the record shape helpfully. Combined with the entry-point guidance and the price_cottages caveat, an agent has everything needed to select and call 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 description coverage is 100% and both filters (business slug, category enum) are fully documented in the schema, including the kayak/accessory clarification. The description adds no filter syntax or semantics beyond that, so the baseline 3 applies.

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

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

States a specific verb+resource ('Every product on sale') and enumerates the concrete product kinds (cottages, kayaks, parking, moorage, charters) along with the fields returned (id, business, capacity, count, published price). It is immediately distinguishable from get_product (single lookup) and price_cottages (date-dependent pricing).

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?

'Start here: every other tool takes a product id from this list' explicitly positions the tool as the entry point and explains its relationship to every sibling. It also names the alternative for the one case it doesn't cover — cottage pricing varies by date, so use price_cottages.

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 non-destructive, so the safety profile is covered. The description adds real behavioral context beyond that: results are per-cottage, flag free stays and party fit, and explicitly exclude the cleaning fee and taxes. This is meaningful cost-semantics disclosure that 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?

Two sentences, no filler. The output scope is front-loaded and the cost caveat/routing note is compressed into a single clause after the colon.

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 description covers the two things an agent cannot get from structured fields: what the figures exclude and which sibling to use for a total. 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. The description earns above baseline by explaining that the guest count is used to evaluate 'whether it sleeps the party' — a semantic purpose the schema's 'How many people.' 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?

The description states a specific resource and scope: 'Every cottage's price for a stay', plus two derived outputs (whether it is free, whether it sleeps the party). It also distinguishes itself from the sibling quote_trip by reserving the all-in total for that tool. An agent can tell exactly what this returns without opening a schema.

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

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

It names the alternative tool (quote_trip) and the condition that selects it ('the all-in total'), which is solid routing guidance. It stops short of an explicit when-to-use/when-not framing (e.g. comparing cottages vs. committing to a booking), so it is clear context rather than full 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 readOnly, idempotent and non-destructive, so the safety bar is pre-cleared. The description adds real domain context beyond that: pricing mirrors checkout ('the way checkout charges it'), the basket includes cleaning fee, taxes and refundable deposits, and it explicitly 'saves nothing and holds nothing.' It does not cover permissions or rate limits, but for a closed-world read-only quote the disclosure is solid.

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 scope, then detail, and short overall. A couple of the fragmentary noun-phrases ('for those dates in that number') are slightly elliptical, and enumerating the basket contents partially duplicates the existing output schema, keeping it just short of a 5.

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 complex nested parameter with full annotations and an output schema, the description covers the essentials: no persistence side effects, what the quote contains, and the charter tripType special case. Return-shape detail is not strictly required given the output schema, but the lack of any sibling-routing guidance leaves one small 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?

The only top-level parameter (lines) is undocumented in the schema, and the description compensates by explaining that each line resolves to a price and a free/non-free status for the given dates and quantity. It also supplies a conditional routing hint the schema doesn't give: a fishing charter line takes tripType (half-day or full-day). The nested item fields are otherwise covered by 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 states a clear operation: it prices a whole basket of lines, the way checkout charges it, so an agent can distinguish it from price_cottages (which prices cottages only). The verb is implied rather than named outright ('quote/price'), and no sibling is named explicitly, but the multi-line 'whole basket' 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?

There is no explicit 'use this when' and no alternative tool is named, so guidance is inferred rather than stated. 'Saves nothing and holds nothing' does signal this is a non-committing preview versus a booking tool like build_cart_link, which is a useful implicit usage cue, but the when-not conditions and siblings are left for the agent to infer.

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