Sedna Genesis

boat_details

Read-onlyIdempotent

Return yacht details and CDN-backed public URLs for yacht media.

This is the primary tool to call after search_boats whenever the customer asks to see yacht photos, a gallery, plans, videos or documents, or asks about layout, capacity, dimensions, equipment, description, crew or itinerary. When the client supports MCP Apps, render the attached inline Sedna gallery; otherwise display the public URLs returned under media.header, media.photos, media.plans, media.images, media.videos and media.documents. All media in this public tool comes through Sedna's CdnManager; missing CDN media is returned as an empty field and never replaced by a legacy DB URL. id_boat must be copied exactly from search_boats. This tool does not return date-specific prices, extras or availability; use booking_detail for those. Length and beam are optional fleet-supplied facts. When absent they are omitted, never returned as zero or estimated. Do not ask for either value or exclude a yacht unless the customer explicitly requires that dimension.

Input Schema

Name	Required	Description	Default
`id_boat`	Yes	Exact yacht ID returned by search_boats. Never guess it.
`language`	No	ISO language code supported by Sedna, for example en or fr.	en
`sheet_type`	No	bareboat or crewed. Use crewed for crew and itinerary data.	bareboat

Output Schema

Name	Required	Description	Default
`boat`	Yes
`media`	Yes
`schema_version`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedOct 19, 2026

addedOutput schema / properties / boat / properties / bathrooms
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / boat / properties / beam_ft
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / boat / properties / beam_m
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / boat / properties / build_year
```
Added value: +{
+  "type": "integer"
+}
```

addedOutput schema / properties / boat / properties / cabins

Added value: +{
+  "additionalProperties": false,
+  "properties": {
+    "bunk": {
+      "type": "integer"
+    },
+    "double": {
+      "type": "integer"
+    },
+    "double_berth": {
+      "type": "integer"
+    },
+    "front_peak": {
+      "type": "integer"
+    },
+    "salon": {
+      "type": "integer"
+    },
+    "single": {
+      "type": "integer"
+    },
+    "total": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / boat / properties / crew_capacity
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / boat / properties / deposit
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / boat / properties / flag
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / boat / properties / heads
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / boat / properties / is_crewed
```
Added value: +{
+  "type": "boolean"
+}
```
addedOutput schema / properties / boat / properties / length_ft
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / boat / properties / length_m
```
Added value: +{
+  "type": "number"
+}
```
addedOutput schema / properties / boat / properties / passenger_capacity
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / boat / properties / refit_year
```
Added value: +{
+  "type": "integer"
+}
```
addedOutput schema / properties / boat / properties / sailing_area
```
Added value: +{
+  "type": "string"
+}
```
addedOutput schema / properties / boat / properties / type
```
Added value: +{
+  "type": "string"
+}
```

Changed1 schema field changedOct 16, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "boat": {
+      "additionalProperties": false,
+      "properties": {
+        "id": {
+          "type": "integer"
+        },
+        "model": {
+          "type": "string"
+        },
+        "name": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "name",
+        "model"
+      ],
+      "type": "object"
+    },
+    "media": {
+      "additionalProperties": false,
+      "properties": {
+        "header": {
+          "anyOf": [
+            {
+              "format": "uri",
+              "type": "string"
+            },
+            {
+              "type": "null"
+            }
+          ]
+        },
+        "images": {
+          "items": {
+            "format": "uri",
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "photos": {
+          "items": {
+            "format": "uri",
+            "type": "string"
+          },
+          "type": "array"
+        },
+        "plans": {
+          "items": {
+            "format": "uri",
+            "type": "string"
+          },
+          "type": "array"
+        }
+      },
+      "required": [
+        "header",
+        "photos",
+        "plans",
+        "images"
+      ],
+      "type": "object"
+    },
+    "schema_version": {
+      "const": "1.0",
+      "type": "string"
+    }
+  },
+  "required": [
+    "schema_version",
+    "boat",
+    "media"
+  ],
+  "type": "object"
+}

First observedSep 10, 2026

TDQS

A4.4/5.0

Behavior4/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All Sedna Genesis tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?