Discover Lake Michigan charter captains & boats, check availability, get quotes, and book.
Check a captain's or boat's availability. Provide exactly one of captainSlug or boatId. Omit date to get available dates for the next 90 days; provide both date (YYYY-MM-DD) and durationHours to get bookable time slots for that date. Each slot lists its offeredDurations, and every entry carries the durationId to pass to get_quote, create_booking, or create_boat_rental (null means that length is offered but not bookable through the API).
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| boatId | No | ||
| captainSlug | No | ||
| durationHours | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only and non-destructive, and the description adds genuinely useful behavioral detail: the two response modes, the 90-day horizon, the offeredDurations on each slot, and the subtle 'null means offered but not bookable through the API' rule. Nothing contradicts 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?
Three dense, front-loaded sentences with no filler: the core operation comes first, the mode selection follows, and the output/booking nuance closes. Every clause earns its place.
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?
Despite having no output schema, the description specifies the two response shapes, the durationId linkage, and the non-bookable null case, so an agent has enough to call the tool and interpret results. It is complete for a moderately complex two-mode lookup 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?
With 0% schema description coverage, the description carries the full parameter burden and does so well: it explains the captainSlug/boatId mutual exclusivity, the date format, and the role of durationHours in selecting the slot mode. It adds meaning the bare schema lacks.
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: 'Check a captain's or boat's availability.' It then clarifies the two distinct query modes, which separates it from sibling detail tools like get_captain/get_boat and from downstream booking tools like create_booking.
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?
'Provide exactly one of captainSlug or boatId' is an explicit parameter exclusion, and the description gives precise conditional instructions: omit date for a 90-day date list, provide both date and durationHours for slots. It also routes the resulting durationId to get_quote, create_booking, or create_boat_rental, explaining the downstream context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a bareboat boat rental and get a Stripe Checkout link for the charterer to complete payment. Requires captainChoiceRightAcknowledged: true (the charterer affirms their right to choose their own captain). Optionally attach a partner/affiliate code.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| Yes | |||
| phone | Yes | ||
| boatId | Yes | ||
| lastName | Yes | ||
| firstName | Yes | ||
| partySize | Yes | ||
| startTime | Yes | ||
| durationId | Yes | ||
| partnerCode | No | ||
| pricingTierId | Yes | ||
| specialRequests | No | ||
| captainChoiceRightAcknowledged | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint=false etc., so description carries some burden. It adds that a Stripe Checkout link is returned and that an acknowledgement is mandatory, which is useful. But it does not disclose whether the boat is reserved pending payment, whether any immediate charge/deposit occurs, or cancellation/idempotency 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?
Three concise sentences, each adding distinct value: the core action, the mandatory flag, and the optional partner code. No redundancy or 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 13 parameters and no output schema, this is a high-complexity tool. The description omits how to obtain key IDs (durationId, pricingTierId), what a successful response contains beyond a Stripe link, and handling of optional fields like specialRequests. Incomplete guidance for reliable invocation.
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 description must compensate. It only adds semantics for captainChoiceRightAcknowledged and partnerCode. The other 11 parameters, including opaque IDs like durationId and pricingTierId, get no added explanation about how to source or interpret them.
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 clear verb+resource: books a bareboat rental and produces a Stripe Checkout link. However, it does not explicitly distinguish itself from the similar create_booking sibling, so it lacks direct 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?
No when-to-use guidance relative to siblings like check_availability, get_quote, or create_booking. The only usage-ish note is a required parameter value (captainChoiceRightAcknowledged), which is a precondition, not a tool-selection criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Book a charter with a captain and get a Stripe Checkout link for the charterer to complete payment. Optionally attach a partner/affiliate code to credit a referrer.
| Name | Required | Description | Default |
|---|---|---|---|
| date | Yes | ||
| Yes | |||
| phone | Yes | ||
| harborId | Yes | ||
| lastName | Yes | ||
| firstName | Yes | ||
| partySize | Yes | ||
| startTime | Yes | ||
| durationId | Yes | ||
| captainSlug | Yes | ||
| partnerCode | No | ||
| pricingTierId | Yes | ||
| specialRequests | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses the key side effect—creating a booking—and the important output behavior: returning a Stripe Checkout link for the charterer to complete payment. It also explains the partnerCode behavior, adding value beyond the sparse boolean 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?
Two focused sentences with no filler. The primary action and output are front-loaded, and the optional partner code is clearly separated.
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?
The tool has 13 parameters, 11 required, no output schema, and no parameter descriptions. The description covers the high-level flow and one optional parameter, leaving critical details about required identifiers, payment-completion semantics, and prerequisites unspecified.
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 0% schema description coverage, the description should clarify required identifiers like captainSlug, harborId, durationId, and pricingTierId, but it only explains the optional partnerCode. Most of the 13 parameters receive no semantic guidance beyond their names.
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 uses a specific verb ('Book'), names the resource ('a charter with a captain'), and states the concrete output (a Stripe Checkout link). This clearly distinguishes it from siblings like create_boat_rental and get_quote.
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: use this when creating a captain-led charter booking and obtaining a payment link. It does not name alternatives or list exclusions, but the intended use case is unmistakable, including the optional referrer-credit scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a boat's full profile by id, enriched with a rating summary and the most recent reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| boatId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, indicating a safe read operation. The description adds value by specifying that the result is 'enriched with a rating summary and the most recent reviews,' providing behavioral context 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?
The description is a single sentence of 18 words, front-loading the core action and key enrichments. No wasted words; every phrase earns its place.
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?
Given the tool's simplicity (1 parameter, no output schema), the description covers the essential return content (full profile, rating, reviews). However, without an output schema, an agent might benefit from knowing the structure or defaults, but the description is adequate for basic selection and invocation.
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 compensate. It only says 'by id' but does not explain the format, origin, or validation of the boatId parameter. The agent receives no additional meaning beyond the schema's type and required constraint.
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 uses a specific verb ('Get') and resource ('boat's full profile'), clearly stating the action and what is included (rating summary, recent reviews). It distinguishes from sibling tools like search_boats (search vs. get by ID) and get_captain (different resource).
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 implies usage context: when you have a boat ID and need a detailed profile with ratings and reviews. It does not explicitly state when not to use or compare to alternatives, but the purpose is clear enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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.
Get a non-binding price quote (in cents) for a charter or rental. Provide exactly one of captainSlug or boatId, plus durationId and partySize. Pass date (YYYY-MM-DD) whenever you know it: the rate then comes from the operator's rate card for that day — weekday vs weekend vs holiday, including any per-date price the operator set — so the quote matches what checkout charges. Without a date, pass pricingTierId instead; the quote then reflects that tier and may differ from checkout for the actual day. Optionally pass a partnerCode to preview a discount. Returns currency, totalCents, depositCents, balanceCents, pricingModel, and (when a code is given) a discountPreview.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| boatId | No | ||
| partySize | Yes | ||
| durationId | Yes | ||
| captainSlug | No | ||
| partnerCode | No | ||
| pricingTierId | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds useful context: non-binding, pricing logic (date-based vs tier), and return of discountPreview only when code is given. No contradiction.
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?
Well-structured in logical order: purpose, required/exclusive parameters, optional date/tier, partnerCode, return fields. Slightly long but every sentence adds value.
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?
Covers all 7 parameters, explains return fields despite no output schema, and clarifies behavioral subtleties (e.g., date-based vs tier-based pricing). Complete for a read-only query tool with 2 required params.
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%, but description fully compensates by explaining each parameter's purpose, format, and mutual exclusivity (captainSlug vs boatId, date vs pricingTierId). Adds meaning beyond schema types.
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?
Clear verb ('get') and resource ('non-binding price quote') with specific scope ('charter or rental'). Distinguishes from siblings like create_booking (creation) and check_availability (availability checks).
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 parameter constraints: exactly one of captainSlug or boatId, plus durationId and partySize. Provides clear guidance on when to use date vs pricingTierId, and optional partnerCode. No confusion with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List active harbors, each with a count of active captains and listed boats operating there.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds that returned data includes counts of active captains and listed boats, clarifying the scope beyond schema.
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 with no unnecessary words; core information is 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?
Although no output schema exists, the description outlines the return structure (harbors with counts). It is sufficient for a simple list tool with no parameters.
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?
No parameters exist, so baseline is 4 per rules. Description does not need to add parameter info.
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 uses specific verb 'list' and a clear resource 'active harbors', and distinguishes from sibling tools like 'search_boats' by focusing on harbors with aggregated counts.
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 implies use for obtaining a harbor overview with captain and boat counts, but no explicit guidance on when to use this tool versus alternatives like 'search_boats' or 'get_harbor' (if existed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's 'Health check' reinforces that it is a safe, non-destructive operation. It adds minimal new behavioral context 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?
The description is extremely concise with two words, no wasted content, and front-loads the purpose. Perfectly sized for a simple 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?
For a tool with no parameters and no output schema, the description is adequate but could be improved by noting the expected return value (e.g., 'pong'). Given minimal complexity, it meets the minimum bar.
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 zero parameters and 100% schema coverage, the description does not need to add parameter details. The baseline of 4 applies as per guidelines.
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 'Health check' clearly indicates this tool tests system connectivity. It is specific and distinguishes from sibling tools like 'check_availability' which likely checks resource availability.
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 guidance is provided on when to use this tool versus alternatives. While the purpose is self-explanatory, explicit context about when not to use it (e.g., for checking specific resources) is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search listed boats, optionally filtered by harbor, type, minimum capacity, and max hourly price, with sorting and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | name | |
| type | No | ||
| limit | No | ||
| harbor | No | ||
| maxPrice | No | ||
| minCapacity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that results support sorting and pagination, which is useful behavioral context, but it does not disclose defaults, maximum page size, or response structure.
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 a single, front-loaded sentence with no filler. Every clause adds meaning: the resource, the optional filters, and the result-shaping behaviors.
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 search tool with seven optional parameters, the description plus schema is minimally viable, but no output schema exists and the description never mentions what a result looks like. An agent can invoke it correctly but would be guessing at the response shape.
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 compensate. It maps most parameters clearly ('harbor', 'type', 'minimum capacity', 'max hourly price', sorting/pagination), and 'max hourly price' clarifies maxPrice. However, it does not explain enum values, defaults, or constraints beyond what parameter names imply.
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 clear verb and resource, 'Search listed boats', and enumerates the filtering dimensions (harbor, type, min capacity, max hourly price). It does not explicitly contrast with siblings like search_captains or get_boat, but the resource and filter scope make its purpose recognizable.
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 'optionally filtered' implies this tool is for broad, filtered searches rather than direct lookups, which loosely distinguishes it from get_boat, but it never names alternatives or states when not to use it. Usage context is only implied, not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search bookable charter captains, optionally filtered by harbor, with sorting and pagination. Returns a paginated list with starting price and rating.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| sort | No | rating | |
| limit | No | ||
| harbor | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint true, and the description adds that results are paginated and include 'starting price and rating'. This enhances transparency beyond annotations without contradiction.
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 wasted words. First sentence states action and options; second describes output. Efficient and well-structured.
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?
Given 4 parameters, no output schema, and 0% schema coverage, the description covers harbor, sorting, pagination, and return fields. Missing details like default sort order or other possible output fields, but still provides a solid foundation for agent usage.
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 must compensate. It explains 'harbor' as an optional filter and mentions 'sorting and pagination', but does not detail enum values for sort or the exact meaning of page/limit. It adds value but leaves some interpretation 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 clearly specifies the verb 'Search' and the resource 'bookable charter captains'. It differentiates from sibling search_boats by targeting captains and adds 'bookable' context, making the purpose distinct and 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 states input options (harbor filter, sorting, pagination) but does not explicitly compare to alternatives like search_boats. It is clear on what the tool does, providing good context for when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
create_boat_rental1 field changedInput schema / properties / partySize / maximumPrevious value: -9007199254740991New value: +13create_booking1 field changedInput schema / properties / partySize / maximumPrevious value: -9007199254740991New value: +13search_boats1 field changedInput schema / properties / type / enumPrevious value: -[
- "SAILBOAT",
- "POWERBOAT",
- "PONTOON",
- "JETSKI",
- "KAYAK",
- "CANOE",
- "YACHT",
- "OTHER"
-]New value: +[
+ "SAILBOAT",
+ "POWERBOAT",
+ "PONTOON",
+ "JETSKI",
+ "KAYAK",
+ "CANOE",
+ "YACHT",
+ "OTHER",
+ "FISHING"
+]get_quote2 fields changedInput schema / properties / dateAdded value: +{
+ "pattern": "^\\d{4}-\\d{2}-\\d{2}$",
+ "type": "string"
+}Input schema / requiredPrevious value: -[
- "durationId",
- "pricingTierId",
- "partySize"
-]New value: +[
+ "durationId",
+ "partySize"
+]check_availabilitycreate_boat_rentalcreate_bookingget_boatget_captainget_quotelist_harborspingsearch_boatssearch_captainsClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Instant private jet charter price estimates and confirmed live quotes, worldwide.
Search Canadian hunting and fishing outfitters, check availability, and send price requests.
Ferry and fast-boat schedules, seats and fares, boat and fishing charters across Indonesia.
Discover and book 5,000+ curated local experiences across 500 US destinations.
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.
