Discover Lake Michigan charter captains & boats, check availability, get quotes, and book.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3.4/5.
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.
check_availabilityCheck AvailabilityACheck 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.
| 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 indicate readOnlyHint=true and destructiveHint=false, and the description adds context about the read-only behavior and return types (dates vs time slots). 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?
Two sentences with no wasted words. Front-loaded with purpose, followed by concise usage instructions. Every sentence serves a clear function.
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 no output schema, the description adequately describes the two possible return types (dates for next 90 days, time slots for specific date). Covers all necessary information for an agent to use 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 has 0% description coverage, but the description fully explains the parameters: mutual exclusivity of captainSlug/boatId, optional date, required durationHours with date, and date format. It compensates entirely for the schema 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 clearly states the tool checks availability for a captain or boat, using specific verbs and resource. It distinguishes from sibling tools like create_booking or get_captain by focusing on availability checking.
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 provides explicit guidance: require exactly one of captainSlug or boatId, and explain two usage modes (omit date for next 90 days, provide both date and durationHours for time slots). It effectively tells when and how to use parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_boat_rentalCreate Boat RentalBInspectBook 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 provide no safety cues; description discloses creation of booking and Stripe link, but doesn't mention idempotency, error handling, or authorization requirements. Adequate but not comprehensive.
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 concise sentences front-loading the primary function. Efficient but could benefit from structured bullet points for key parameters.
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 13 parameters with no schema descriptions and no output schema, the description fails to provide enough context for proper invocation, especially for required fields like boatId, date, and pricingTierId.
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 coverage, the description only explains captainChoiceRightAcknowledged and partnerCode, leaving 11 other parameters (e.g., date, durationId, pricingTierId) completely unexplained. Insufficient compensation.
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 explicitly states 'Book a bareboat boat rental' and 'get a Stripe Checkout link', providing a clear verb, resource, and outcome. It distinguishes from sibling 'create_booking' by specifying bareboat rental and payment link.
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 mentions a prerequisite (captainChoiceRightAcknowledged must be true) and optional partner code, but does not specify when not to use this tool compared to siblings like 'create_booking' or 'get_quote'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_bookingCreate BookingAInspectBook 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?
Annotations provide no safety hints (all false). The description discloses primary behavior (create booking, return checkout link) but omits details like idempotency, error handling, or side effects. No contradiction with 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 sentences, front-loaded with primary action and key output. No wasted words, efficient for agent parsing.
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) and no output schema. Description covers main purpose and one optional parameter, but lacks explanation of required parameter details, return structure beyond checkout link, and error scenarios. Adequate for simple cases but gaps exist.
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 description must add value. It explains partnerCode and overall booking purpose, but does not detail date format, time format, specialRequests, or other required params. Adds some semantic meaning but insufficient for full compensation.
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 states the tool creates a booking and returns a Stripe checkout link, using specific verbs like 'Book a charter' and 'get a Stripe Checkout link'. It distinguishes itself from siblings like create_boat_rental by focusing on captain-led charters.
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 does not explicitly state when to use this tool versus alternatives like check_availability or get_quote. It implies usage for finalizing a booking after availability checks, but lacks when-not guidance or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_boatGet BoatAGet 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_captainGet CaptainAGet 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_quoteGet QuoteAGet 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_harborsList HarborsAList 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.
pingPingBHealth 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_boatsSearch BoatsASearch 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 description adds minimal behavioral context. It mentions 'listed boats' but does not elaborate on pagination limits or response structure beyond the 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?
The description is a single concise sentence that front-loads the main action and covers key aspects. No unnecessary words.
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 search tool with 7 optional parameters and no output schema, the description adequately covers input options and hints at output ('Search listed boats'). It mentions pagination and sorting, but does not explicitly state that results are lists or that empty results are possible.
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 lists 4 of 7 parameters (harbor, type, minCapacity, maxPrice) and references sorting/pagination but omits default values, allowed enum values for sort and type, and the exact names of pagination parameters (page, limit).
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 states the tool's action ('Search listed boats') and lists the filter options (harbor, type, min capacity, max price). It also mentions sorting and pagination, distinguishing it from siblings like get_boat (single boat) or search_captains (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?
Usage is implied ('Search listed boats') but no explicit guidance on when to use this tool vs alternatives like check_availability or get_boat. No when-not or sibling comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_captainsSearch CaptainsASearch 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.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!