Search boats for sale or rent, marinas and live market stats on Obato, Europe's boat marketplace.
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 3.7/5 across 11 of 11 tools scored. Lowest: 3.1/5.
Most tools have distinct purposes (search, stats, details, facts, comparison, marina search, QA), but get_market_stats, get_boat_pricing_stats, and market_snapshot all provide pricing/aggregate data, which could cause misselection. Descriptions help differentiate, but the general ask_bo tool overlaps conceptually with get_facts.
Most tool names follow the snake_case verb_noun pattern (e.g., search_boats, get_brand_info), but market_snapshot is a noun phrase and ask_bo is a verb_person rather than verb_noun. Slight deviation but overall consistent and readable.
11 tools is well-scoped for a boat marketplace information server. Each tool covers a distinct query type (search, detail, stats, comparison, marina, facts, QA) without feeling overly heavy or too sparse.
The surface covers core read-only workflows: searching boats and rentals, retrieving details, market stats, brand info, marina search, and general facts. Minor gaps like a dedicated region list or rental availability details are workable, but no critical dead-ends are evident.
ask_boAInspectAsk Bo, Obato's AI boat expert, any question about boats, watersports or the European boat market. Returns a cited answer grounded in Obato's live market data. Rate-limited (5 req/min/IP).
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | The question for Bo (max ~500 chars). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a cited answer grounded in live market data and mentions a specific rate limit (5 req/min/IP). This gives agents essential behavioral expectations. Missing details like whether it is read-only or how it handles out-of-scope questions are minor gaps, but the rate limit and grounded-citation guarantees are valuable transparency.
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 exceptionally concise: two sentences that immediately state the purpose and scope, then add return behavior and rate limit. No filler or repetition. The opening sentence is front-loaded with the core action, and every clause provides useful 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?
For a simple tool with one parameter, no output schema, and no annotations, the description is adequately complete. It covers purpose, scope, the nature of the response (cited, grounded in live data), and a limitation (rate limit). The only slight omission is guidance on what happens if the question is outside the described domains, but that is not critical for a task of this complexity.
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 schema description coverage is 100%: the single parameter 'question' has a description and a max length. The tool description adds no extra parameter semantics beyond what the schema already provides. Per the rubric, baseline is 3 when schema coverage is high, and the description does not need to compensate.
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 function: 'Ask Bo, Obato's AI boat expert, any question about boats, watersports or the European boat market.' It specifies the resource (Bo, an AI expert) and the scope of questions, distinguishing it from sibling tools that are more specialized (e.g., get_boat_details, search_boats). The purpose is unambiguous and action-oriented.
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 this tool is for open-ended questions and provides cited answers based on live market data, but it does not explicitly state when to use it instead of sibling tools. No exclusions or alternative commands are mentioned. It could be improved by noting that it handles free-form queries that are not covered by the structured search/stat tools, but this is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
compare_brandsBInspectCompare two boat brands head-to-head on Obato: listing counts, avg/median price, avg length, year range. Powers 'X vs Y' answer-engine queries (e.g. 'Bavaria vs Beneteau').
| Name | Required | Description | Default |
|---|---|---|---|
| brand_a | Yes | ||
| brand_b | Yes | ||
| type_boot | No | Optional category filter |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral aspects. While it outlines the metrics compared, it doesn't mention any side effects (likely read-only), data freshness, or performance considerations. It does add context beyond a simple 'compare' but lacks details on output format or notable behaviors.
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 concise, consisting of two sentences that efficiently convey purpose and use case. It front-loads the main action and includes a concrete example without unnecessary fluff.
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 comparison tool with 3 parameters and no output schema, the description covers the main purpose and main fields being compared. However, it lacks details on edge cases, such as how it handles brands with no listings or the exact format of the output. Given the lack of annotations, the description is adequate but leaves some gaps.
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 schema describes only 1 of 3 parameters (type_boot has a description), so coverage is low (33%). The description supplements by implying that brand_a and brand_b are boat brand names (e.g., 'Bavaria', 'Beneteau'), which adds value over the bare schema. However, the description does not fully compensate for the lack of detail on all parameters, such as valid formats for the brands.
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 compares two boat brands, listing specific comparison dimensions (listing counts, prices, length, year). It also distinguishes itself by explicitly mentioning it powers 'X vs Y' answer-engine queries, differentiating it from sibling tools like 'get_brand_info' or 'get_market_stats'.
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 a clear use case ('Powers X vs Y answer-engine queries') and examples, which implicitly suggests when to use it. However, it does not explicitly mention when not to use it or name a specific alternative tool, though the sibling tool list is available for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
find_marina_with_amenitiesAInspectFind European marinas (jachthavens) that match a set of amenities: electricity, water, fuel, wifi. Optional country/province filters. Returns up to 25 marinas.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| country | No | ||
| province | No | ||
| amenities | No | Required amenities. All listed must be present. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It does disclose the return limit ('Returns up to 25 marinas') and optional filters. However, it fails to explain what happens when no amenities are specified, whether all amenities are required (the schema says so, but the description doesn't), or how results are ordered. This leaves notable behavioral gaps.
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 two concise sentences that front-load the core purpose and key features. It uses only necessary words with no redundancy or vague phrasing, earning a perfect score.
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 no output schema or annotations, placing a heavy burden on the description. It covers the main search dimensions (amenities, country, province, limit) but omits interaction semantics such as the conjunctive requirement for amenities, default behavior with no filters, and result ordering. While basic functionality is clear, the return format and parameter edge cases are under-specified, making it only minimally complete.
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?
Only 25% of parameters have schema descriptions, so the description must compensate. It lists the amenity values and clarifies country/province as filters. However, it does not explain the 'limit' parameter's role, and the phrase 'Returns up to 25 marinas' could mislead because the schema default is 10. The compensation is partial, warranting a 3.
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 finds European marinas matching a set of specific amenities (electricity, water, fuel, wifi), with optional country/province filters. This distinguishes it from sibling boat/rental search tools by focusing on marinas and their amenities, using a specific verb ('Find') and resource ('European marinas').
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 when to use this tool: when searching for marinas with specific amenities. It provides clear context by specifying Europe and the amenity set, but it does not explicitly mention alternatives or exclusions (e.g., 'use search_boats for boats'). The absence of when-not-to-use guidance keeps it at 4 rather than 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_boat_detailsAInspectFetch detail of one boat listing by seo_slug or id.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | ||
| slug | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only says 'Fetch detail' and does not clarify what happens when neither id nor slug is provided, what fields the 'detail' response contains, error behavior, or whether there are any access restrictions. The read-only nature is implied by 'Fetch', but no additional context is disclosed.
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, tight sentence that delivers the core purpose and key parameters without any filler or repetition. It is efficiently front-loaded and easy to scan.
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 simple fetch-by-identifier tool, the description covers the essential action but leaves gaps around the requiredness of id/slug, the exact return structure, and behavior in edge cases. There is no output schema to fall back on, so those details are especially relevant. Overall it is minimally viable but not fully robust.
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 does clarify that the two string parameters correspond to an id and a seo_slug, and that either may be used to fetch a listing. However, it does not indicate whether exactly one is required, what precedence applies if both are supplied, or the expected format for the slug.
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 identifies the action ('Fetch detail') and the target resource ('one boat listing'), and specifies the lookup mechanism ('by seo_slug or id'). It is specific enough to distinguish this from sibling tools that search lists or provide statistics.
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 when to use it: when you need details about a specific boat already identified by slug or id. However, it does not explicitly say how it differs from related tools like search_boats or get_boat_pricing_stats, nor does it mention any when-not-to-use conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_boat_pricing_statsAInspectPricing statistics (count, avg, median, p25, p75, min, max) for a boat category, with optional region and length range. Powers commercial-intent answer-engine queries.
| Name | Required | Description | Default |
|---|---|---|---|
| regio | No | ||
| type_boot | Yes | ||
| lengte_max | No | ||
| lengte_min | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry transparency. It lists the output statistics (count, avg, median, p25, p75, min, max), which is good. However, it does not disclose any side effects, auth requirements, or behavior when inputs are invalid or no results exist. Since it's a read-only stats tool, the risk is low, but more detail on return format or edge cases would help.
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. The first states the core output (stats) and scope; the second adds context on use case. No wasted words, well 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?
The description covers the inputs and output metrics well, but lacks details on error handling, edge cases (e.g., no data), or performance. Since there is no output schema and no annotations, it could be more explicit about what happens with missing required params or how results are returned. It does cover the essential statistical outputs.
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 clearly maps parameters: 'boat category' implies type_boot, 'optional region' implies regio, and 'length range' covers lengte_min and lengte_max. This adds meaning beyond the raw names, though not exhaustive (e.g., units, formats).
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 computes pricing statistics (count, avg, median, p25, p75, min, max) for a boat category, with optional filters. The verb is implicit but the resource and outcome are specific. It doesn't explicitly differentiate from siblings like get_market_stats, but the focus on boat categories and pricing stats distinguishes it.
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?
It says 'Powers commercial-intent answer-engine queries,' giving a hint about when to use. However, it doesn't explicitly state when not to use or name alternatives, so the agent lacks clear exclusions. The hint is useful but not fully directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_brand_infoAInspectKnowledge-graph info about a specific boat brand or manufacturer on Obato: description, expert facts, authority score, active listing count.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Brand slug (lowercase, e.g. 'bavaria', 'jeanneau', 'bayliner'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly mention side effects or read-only nature. As a 'get' tool, it is implicitly read-only, but there is no explicit statement about safety or potential costs.
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 efficiently conveys the tool's purpose and output without unnecessary verbosity.
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 description sufficiently explains what the tool returns, making it adequate for basic use. However, it does not detail the return format or any nuances (e.g., data source), but this is acceptable given the simple output.
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 single parameter 'slug' is clearly described as a brand slug with concrete examples (e.g., 'bavaria', 'jeanneau'), fully covering its meaning and usage.
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 retrieves knowledge-graph information about a specific boat brand, listing the specific attributes (description, expert facts, authority score, active listing count). This distinguishes it from sibling tools like search_boats or get_boat_details.
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 brand-level information but does not explicitly state when to prefer this over alternatives or when not to use it. Guidance is implicit through the mention of brand-specific data, but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_factsAInspectCitable facts about boats and watersports from Obato's knowledge graph, ranked by authority score. Each fact includes a source citation suitable for grounded LLM answers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of facts to return. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does disclose that results are ranked by authority score and that each fact includes a source citation, which is valuable. It does not, however, explain edge cases like empty results, pagination, or the meaning of 'authority score', leaving some gaps.
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 two sentences, front-loaded with the core functionality, and contains zero filler. Every clause adds meaningful information: domain, source, ranking, and citation feature.
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 only one parameter and no output schema, the description is adequately complete. It explains what is returned, the ranking principle, and the citation structure. It doesn't mention behavior when no facts match or authentication requirements, but these are not critical for this simple use case.
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% for the single 'limit' parameter, and its description is 'Number of facts to return.' The tool description adds no additional parameter context, so the baseline of 3 applies.
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 identifies the tool as returning citable facts about boats and watersports from a knowledge graph, with ranking by authority. It distinguishes itself from entity-specific siblings like get_boat_details or get_brand_info by focusing on general facts. However, it lacks an explicit verb like 'retrieve' or 'list', so the action is implied rather than stated.
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 'suitable for grounded LLM answers' provides clear context for when this tool should be used: when the agent needs citable, authoritative facts. It does not explicitly name alternatives or exclusions, but the usage context is sufficiently clear for a simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_market_statsBInspectAggregate market stats (count, avg/min/max price) for a category and optional region.
| Name | Required | Description | Default |
|---|---|---|---|
| regio | No | ||
| type_boot | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of transparency. It discloses the computed statistics but does not describe edge-case behavior, such as how missing categories or regions are handled, what value formats are returned, or any rate/access considerations.
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 that communicates the tool's purpose, output metrics, and primary scoping dimensions without redundancy. 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?
For a simple two-parameter aggregator, the description covers the purpose, output metrics, and parameter roles. However, it lacks sibling differentiation and does not clarify return shape or edge-case behavior, which matters more because there is no output schema or annotation support.
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%, and the description partially compensates by interpreting type_boot as 'category' and regio as 'optional region'. However, it provides no accepted value formats, constraints, or an explicit mapping of each parameter beyond this general correspondence.
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 aggregates market stats and names the metrics (count, avg/min/max price), scoped by category and optional region. It is more specific than the tool name alone, though it does not explicitly differentiate from overlapping siblings like get_boat_pricing_stats or market_snapshot.
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?
There is no guidance on when to prefer this tool over alternatives, and the sibling list includes several potentially overlapping market/stat tools. The description implies a summary use case but gives no exclusions or comparison cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
market_snapshotAInspectReal-time snapshot of the European boat market on Obato — total listings, average prices by boat type, and regional distribution. Cached ~5 minutes.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses caching behavior ('Cached ~5 minutes') which is useful, but does not mention potential costs, rate limits, or any side effects. With no annotations, the description carries the burden, and while caching is noted, other behavioral aspects (e.g., how fresh data is, any auth requirements) are absent.
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, well-structured sentence that front-loads the purpose and includes the key caching detail. Every word adds value with no redundancy.
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 description fully specifies the output data (total listings, average prices, regional distribution) and the caching behavior. For a no-parameter tool with no output schema, this is complete and sufficient for an agent to understand what to expect.
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?
There are zero parameters, so per the rubric, the baseline is 4. The description does not need to add parameter information beyond the schema, and it appropriately leaves it out, focusing on output details.
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 function: a real-time snapshot of the European boat market on Obato, specifying the exact data points (total listings, average prices by boat type, and regional distribution). This is a specific verb+resource and distinguishes it from siblings like get_market_stats which may cover different scopes.
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 a market-level overview but does not explicitly state when to use it versus alternatives like get_market_stats or get_boat_pricing_stats. It mentions the European scope and caching, but no explicit when-not guidance or alternative references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_boatsAInspectSearch Obato's public marketplace for boats. Filters: free-text query, category (type_boot), region, brand, price range. Returns up to 25 listings.
| Name | Required | Description | Default |
|---|---|---|---|
| merk | No | Brand name | |
| limit | No | ||
| query | No | Free-text search (title, description, brand) | |
| regio | No | Region / province | |
| prijs_max | No | ||
| prijs_min | No | ||
| type_boot | No | Category, e.g. motorboot, zeilboot, sloep |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It does disclose that the search targets a public marketplace and returns up to 25 listings, but it does not mention sorting, pagination, default limit behavior, or whether filters are combined.
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 the action and resource, followed by a clean filter enumeration. Every sentence earns its place with no redundant phrasing.
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 and no annotations, the description covers purpose, filter dimensions, and result cap, which is enough for basic invocation. Missing details like sorting and pagination prevent a perfect score, but this is close to complete for a simple search 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 description coverage is 57%, and the description helps compensate by naming the filter groups: free-text query, category, region, brand, and price range. It also adds meaning for 'limit' with 'Returns up to 25 listings', though it does not restate all schema-level details.
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 uses a specific verb ('Search'), identifies the exact resource ('Obato's public marketplace for boats'), and lists the filter dimensions. This clearly distinguishes it from sibling tools like search_rentals and get_boat_details.
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 clearly implies use for searching public boat listings and names the available filters, providing enough context for selection. It does not explicitly mention when not to use it or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_rentalsAInspectSearch Obato's rental fleet (verhuur) for boats available to rent. Filters: free-text query, boat type, region/country, capacity, max price per day, optional date (YYYY-MM-DD) to filter on available days. Returns up to 25 rental boats with default daily price.
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | Optional YYYY-MM-DD; only returns boats with no 'booked'/'blocked' status on that date | |
| type | No | Rental boat type, e.g. sloep, motorboot, zeilboot | |
| limit | No | ||
| query | No | Free-text (name, location) | |
| region | No | Region or province | |
| country_code | No | ISO country code, e.g. NL, DE, FR | |
| min_capacity | No | ||
| max_price_per_day | No | Maximum EUR per day |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses key behaviors: returns up to 25 boats, uses a default daily price, and filters on date for available days. However, it does not mention sorting, pagination, or potential side effects (though a search is inherently read-only). The description is adequate but not rich; it adds some context beyond the schema (return limit, default price) but misses details like result ordering or error handling.
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 that efficiently lists filters and return characteristics. It is not overly verbose and covers the essential purpose. However, it lacks structural elements like headers or bullet points, which could improve scannability for an agent. Still, it's appropriately concise and wastes no 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?
Given there is no output schema, the description should explain the return structure more fully. It mentions returning up to 25 rental boats with default daily price, but does not specify what boat fields (e.g., name, type, location) are included. The tool has 8 filters, and while the description covers them, the lack of return-field details leaves some uncertainty. It is minimally sufficient but not complete for a tool with no output schema.
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 75%, so most parameters already have clear descriptions in the schema. The description adds a bit of context (e.g., 'free-text query', 'capacity', 'max price per day') but largely paraphrases the schema. It does not add new meaning or clarify types or formats beyond what the schema provides. Since the schema is already informative, the description meets the baseline but doesn't compensate for the missing 25% (e.g., 'limit' and 'min_capacity' lack descriptions).
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 searches Obato's rental fleet for available boats, with a specific verb (search) and resource (rental fleet). It distinguishes itself from siblings like search_boats by focusing on rentals, and the mention of 'verhuur' clarifies domain context. This is unambiguous and differentiates it from the broader search_boats tool.
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 when to use this tool (for rentals) but does not explicitly state when not to use it or mention alternatives like search_boats. It lists filters, but no guidance on choosing between this and other search tools. The purpose is clear enough that usage is inferred, but explicit exclusions or alternative mentions are missing.
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!