Get Captain
get_captainGet a captain's full profile by tenant slug, enriched with a rating summary and the most recent reviews.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
get_captainGet a captain's full profile by tenant slug, enriched with a rating summary and the most recent reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=true and destructiveHint=false. Description adds that the profile is enriched with rating summary and most recent reviews, providing actionable behavioral detail beyond 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?
Single sentence of 15 words, front-loaded with key action and resource, no redundant 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?
Adequate for a read-only single-resource tool with one parameter. Lacks mention of error handling or what happens if slug is invalid, but enriched content hint provides useful completion context.
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 has 0% description coverage for the single 'slug' parameter. Description explains the parameter's role ('by tenant slug'), fully compensating for lack of schema documentation.
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?
Description clearly states verb ('Get'), resource ('captain's full profile'), and key parameter ('by tenant slug'). It also specifies the enriched content (rating summary and recent reviews), distinguishing it from sibling tools like search_captains.
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?
Implies use when a specific captain's slug is available and full details are needed. Does not explicitly exclude or recommend alternatives like search_captains, but context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action or resource: availability checks, bookings (with/without captain), data retrieval for boats/captains/harbors, quotes, and searches. The descriptions clearly differentiate similar tools like create_boat_rental vs. create_booking.
All tool names follow consistent verb_noun snake_case pattern (e.g., check_availability, create_booking, search_boats). No mixing of styles or ambiguous verbs.
10 tools is well-suited for a booking platform covering search, details, quotes, and booking creation. Every tool serves a clear purpose without redundancy.
The core booking workflow (search, check availability, quote, create) is fully covered. Missing tools for viewing existing bookings or cancellations, but these are minor gaps for a public-facing API.