Sedna Genesis

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed-world). The description adds genuinely new behavioral constraints beyond that: do not fabricate yacht/price facts, stay neutral between fleets, and copy IDs verbatim. These are useful guardrails, though they are workflow rules rather than properties of this specific call.

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 core purpose is front-loaded in the first sentence, which is good. However, several numbered rules (notably rule 3 about copying `id_tbf1`/`id_boat` from `search_boats` results, and rules 1-2) pertain to the broader yacht-search workflow rather than to invoking `Base_list`, so they dilute focus on a no-argument listing 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 no output schema, the description must convey the return shape, and 'lists available bases grouped by country' plus the note about using the returned base name does that adequately. The prerequisite relationship to `search_boats` is also stated, leaving little an agent would need that is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is no parameter surface for the description to clarify or obscure.

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 — it lists available bases grouped by country — plus it carries operating guidance. Sibling differentiation is partly handled by rule 5, which positions it as a prerequisite to `search_boats`, though the purpose statement itself doesn't contrast it with `boat_details` or other siblings.

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

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

Rule 5 gives an explicit when-to-use directive: call `Base_list` before `search_boats` and use the returned base name. That is a concrete sequencing rule, but there is no when-not guidance or discussion of alternatives for other cases.

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, so the safety profile is covered; the description adds real behavior beyond that: all media flows through Sedna's CdnManager, missing CDN media is returned as an empty field and never backfilled with a legacy DB URL, and the rendering path branches on MCP Apps support vs. returning public URLs. Slight overlap with the output schema (enumerating media.header/photos/plans/etc.) keeps this 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?

Content is front-loaded: purpose, trigger, rendering behavior, parameter rule, then exclusions, with the length/beam caveat last. Nearly every sentence carries actionable information, though the media-field enumeration and the id_boat repetition slightly overlap structured data and could be trimmed.

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 rich annotations, a fully covered input schema, and an output schema that needn't be re-explained, the description fills every remaining gap an agent needs: when to call it, sibling routing, CDN-only media semantics, empty-vs-missing behavior, and how to handle optional fleet dimensions. Nothing required for correct invocation 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 all three parameters are described in the schema, so the baseline is 3. The description adds only marginal meaning: reinforcing that id_boat must be copied exactly from search_boats (schema already says 'Never guess it') and indirectly hinting that sheet_type=crewed unlocks crew/itinerary data, but it never ties that mode switch to the parameter by name or explains the language 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?

States a specific verb and resource ('Return yacht details and CDN-backed public URLs for yacht media') and immediately scopes what content types it covers: photos, gallery, plans, videos, documents, layout, capacity, dimensions, equipment, description, crew, itinerary. It distinguishes itself from search_boats (must be called after it) and from booking_detail (which handles prices/extras/availability), so an agent can route correctly 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 states the primary trigger ('after search_boats whenever the customer asks to see yacht photos...'), names the exclusion set (no date-specific prices, extras, or availability) and routes those to booking_detail. It also warns not to ask for or exclude a yacht over missing length/beam, which is genuine when-not-to behavior, not just implied 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 declare the safety profile (not read-only, open-world, non-idempotent, not destructive), and the description adds genuinely non-obvious behavior: the call re-prices, saved_extras verification is the source of truth for what was actually selected, full client details are mandatory, and the AI must not fabricate customer information. These are meaningful additions beyond the annotations, though the consequence of the non-idempotent re-submit is not spelled out.

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?

Content is front-loaded with purpose, then the critical selected_extras rule, then the client-detail rule. Most sentences earn their place, but the trailing bolded rule with stray formatting markers ('**** strong rule') and inline quotes is untidy and slightly redundant with the client-details sentence above it.

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

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

For a 15-parameter mutation tool with no output schema, the description covers the two highest-risk requirements (complete extras, real client data) and the preview-vs-submit distinction. It leaves the optional arrival/departure/currency/port-pay parameters and the saved_extras verification field unexplained, but no critical calling detail 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?

With schema coverage at 67% and 15 parameters, the schema documents the primitives but the description adds real semantics for the highest-risk field: selected_extras must repeat every extra with exact id_opt and quantity, and [] is valid only when nothing was chosen. It also reinforces that client_name/email/phone are required. The four pagination/currency/port-pay optional parameters are left unexplained in both places.

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

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

States a specific verb ('submits a request') and both resources ('booking' or 'option'), and explicitly contrasts itself with the sibling booking_detail_mod, which is a stateless preview. An agent can distinguish this from booking_detail and booking_detail_mod 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 clear context for use: this is the tool that persists and re-prices, whereas booking_detail_mod does not store selections, and it names the alternative explicitly. It does not spell out when to pick 'option' mode over 'booking' mode, but the mode parameter plus default covers that gap.

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

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

Annotations only declare a safe read (readOnlyHint, idempotentHint, non-destructive). The description goes well beyond: image content here is supplemental vs boat_details being canonical, totals must come from customer_cost_summary.full_customer_cost, and deposits are returned separately and excluded from that amount. That is meaningful behavioral context annotations cannot convey.

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

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

Front-loaded with the purpose, then dense workflow guidance with no filler. It is on the long side and packs several distinct topics (IDs, media, extras, totals, deposits, follow-up actions), but each sentence carries actionable 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?

No output schema exists, yet the description surfaces the key return field (customer_cost_summary.full_customer_cost) and the deposit caveat, plus the workflow transition to booking_detail_mod and the final booking/option request. An agent has everything needed to call and act on this 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 the baseline is 3. The description adds real meaning on top: id_boat and id_tbf1 must be used 'exactly as returned by search_boats,' which constrains their source in a way the schema descriptions do not.

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 ('Return date-specific availability, pricing, extras and booking choices') and immediately scopes it to 'a selected yacht and charter period.' It distinguishes itself from siblings by name, telling the agent it is not boat_details and that booking_detail_mod handles modifications.

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

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

Gives explicit alternatives with conditions: do not call for photos, call boat_details with the exact id_boat; after extras/pax/currency/ports/payment change, call booking_detail_mod and use only its server-calculated totals. Both when-to-use and when-not-to-use are covered.

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 readOnlyHint=true, destructiveHint=false, and idempotentHint=true, and the description adds meaningful behavioral context beyond those: it is a stateless preview, it does not save the selection, Sedna is the only pricing source of truth, and the server recalculates totals. It also specifies how to present returned financial fields (customer_cost_summary.full_customer_cost, payable_now, payable_at_base, refundable deposit) which goes beyond what the annotations provide.

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

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

The description is longer than a typical tool definition, but it is front-loaded with the core purpose and then flows into operational guidance without filler. Each sentence contributes either a routing instruction or a behavioral rule. It loses a point because some instructions (e.g., repeating "never add them in the LLM" and separately warning about totals) could be tightened without losing meaning.

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

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

There is no output schema, so the description carries the burden of explaining return handling, and it does so: it tells the agent to present the complete updated summary, quote customer_cost_summary.full_customer_cost, explain payable_now and payable_at_base separately, and keep the refundable deposit separate. Combined with the stateless preview warning and the booking_create handoff, it is complete enough for correct invocation in this workflow.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters, including required IDs, dates, pax, selected_extras, currency, ports, and payment options. The description reinforces a few mappings (e.g., "Copy id_boat and id_tbf1 from search_boats" and "Send selected extras, passenger count, currency, ports and payment options here") but adds no new syntax or constraints beyond the schema. Baseline 3 is appropriate 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 opens with a specific verb and resource: "Apply customer selections and return server-recalculated booking details." It further scopes the tool as a "stateless price preview" and distinguishes it from booking_create by noting that booking_create is used when the customer proceeds. This is enough for an agent to identify the tool 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?

The description gives clear context: copy id_boat and id_tbf1 from search_boats, send selections here, then repeat selected_extras in booking_create if the customer proceeds. It also clarifies that this tool does not save the selection, implicitly telling the agent to use booking_create for persistence. It does not explicitly address when to use this modified tool versus the sibling booking_detail, which prevents a 5.

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

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

Annotations already declare read-only, idempotent, closed-world, non-destructive, so safety is covered. The description adds genuinely non-obvious behavior: deposits are always reported separately from full customer cost, and missing length/beam are omitted rather than zeroed, nulled or estimated, explicitly without affecting availability.

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 one-line purpose, then a scannable parameter list, then output semantics. Every sentence is substantive, though the second paragraph drifts into return-value detail that the output schema already covers and could be trimmed.

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 present, the definition supplies enough to call the tool correctly for a comparison query. Only edge behavior (invalid/duplicate ids, currency unsupported, date range without pricing) is left 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 0%, so the description carries the full burden and does: it gives the 2..4 bound on boat_ids (absent from the schema), explains that pax feeds booking_detail pricing, enumerates the currency values EUR/USD/CNY with the EUR default, and fixes the date format as YYYY-MM-DD.

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+resource+scope: 'Compare 2 to 4 boats using Sedna's date-specific customer pricing.' That framing inherently separates it from search_boats (discovery) and boat_details (single yacht), and it further anchors itself by referencing the booking_detail pricing it mirrors.

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?

Conveys the operating context (2-4 boats, optional date window, dated vs undated comparisons) and ties output to booking_detail's preview, but never states when to prefer this over search_boats or boat_details, nor any exclusions or error conditions such as fewer than 2 or more than 4 ids.

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 behavioral constraints beyond the annotations: do not invent facts, stay neutral between fleets, copy id_boat and id_tbf1 exactly, clarify missing years, and never generalize availability to other dates. These are meaningful operational rules for the agent. The annotations already establish read-only and idempotent behavior, and the description does not contradict them.

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

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

The content is a structured numbered list with the most important constraints near the top. Each item appears to earn its place as actionable guidance, though some entries are longer than necessary. Overall it is organized and reasonably front-loaded.

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

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

For a zero-parameter guidance tool with no output schema, the description supplies a fairly complete set of behavioral rules. It covers fact sourcing, neutrality, call ordering, identifier handling, date clarification, media retrieval, and availability scope. It does not explain what the tool returns, but with no output schema that is less critical.

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

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

The tool has zero parameters, so parameter semantics are inherently simple and the schema coverage is 100%. The description does not need to explain parameter meaning, and it correctly does not introduce any. Baseline 4 applies for a no-parameter tool.

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

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

The description opens with 'Sedna guidance for public yacht-search conversations,' which is more of a topic label than a specific tool action. It never states a verb like 'returns' or 'provides guidance text,' and it does not distinguish this readme tool from the search, booking, or detail siblings. An agent can infer it is a guidance document, but the purpose is not crisply defined.

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 numbered rules give clear operational context, such as calling Base_list before search_boats and using boat_details for media. However, they do not explicitly say when to call the readme tool itself versus when to skip it, nor do they state exclusions or alternatives for this guidance tool. Usage is therefore implied rather than specified.

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

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

Annotations already declare read-only, idempotent, non-destructive, closed-world, but the description adds genuinely new behavior: results have passed Sedna planning/block and pricing checks, results intentionally omit images, and there is a 30-result threshold with defined agent behavior. These are operational traits an agent could not infer from the annotations.

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

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

Four paragraphs with a clean front-loaded core (what it does, prerequisite, result thresholds) followed by media routing and data-quality caveats. Slightly long, but nearly every sentence carries actionable rules; nothing is padding.

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

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

With 13 parameters, no output schema, and a complex availability workflow, the description covers prerequisites, result thresholds, sibling routing for media and pricing, and edge-case handling of incomplete fleet facts. An agent has everything needed to call it and act on results correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds interpretive value: 'base' must be an official name from Base_list, and it explains how missing length/beam must be treated (omitted, never zeroed, never used to exclude). It does not explain the 'option' or 'page' semantics beyond the schema, so it stops short of a 5.

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 ('Search Sedna for yachts available for the exact requested dates') with the availability scope nailed down. It is immediately distinguishable from siblings: boat_details is for media, booking_detail for date-specific pricing, Base_list for resolving the base name.

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

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

Explicitly routes the agent: call Base_list first and use an official base name, use boat_details for photos/plans/documents, use booking_detail for prices/extras/ports. It also gives result-handling rules for >30 matches, <=30 matches, and zero matches, so the agent knows exactly what to do on each branch.

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