AI-native Caribbean vacation-rental registry: pricing, licensing, availability, source-linked.
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 15 of 16 tools scored. Lowest: 2.7/5.
Most tools target distinct actions, but the presence of both 'search' and 'rental_search' could cause confusion, and 'fetch' overlaps slightly with 'rental_property'. However, descriptions clarify the differences.
While most tools use a 'rental_' prefix, two tools ('fetch', 'search') lack it, and the naming style varies between verb-noun and noun-only (e.g., 'rental_availability' vs 'rental_search'). This inconsistency could confuse an agent.
With 16 tools, the set covers a comprehensive range for a Caribbean rental assistant, including search, property details, pricing, availability, licensing, market intelligence, and session management. Each tool serves a clear purpose.
The tool set covers the core lifecycle (search, view details, create sessions, add picks), but lacks session update/delete functionality. Also, 'fetch' and 'search' seem redundant with rental-focused tools. Overall, the domain is well-covered for an agent workflow.
fetchAInspectFetch the full record for an id returned by search — a rental property (by RIN) or an island venue.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The id from a search result (a RIN or a venue id) |
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 states 'Fetch the full record' implying a read operation, but does not mention whether the operation is safe (non-destructive), any authentication needs, or rate limits. Minimal but adequate.
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 action and resource. Every word earns its place, with no wasted text.
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 tool with one parameter and no output schema, the description adequately explains the input and the action. It could be more complete by hinting at the return structure, but given the context, it is sufficient.
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 'id' in the schema is described as 'The id from a search result (a RIN or a venue id)'. The description adds the clarification that it returns a full record, but otherwise does not add meaning beyond what the schema provides. Schema coverage is 100%, so baseline is 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 verb 'Fetch', the resource 'full record for an id', and distinguishes from siblings by specifying that the id comes from search and can be a RIN or venue id. It contrasts with the many rental-specific tools.
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 that this tool is to be used after obtaining an id from a search, but does not explicitly mention when not to use it or list alternative tools. The implication is strong, earning a 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_availabilityBInspectCheck availability for a rental property on specific dates.
| Name | Required | Description | Default |
|---|---|---|---|
| rin | Yes | Rental Identification Number | |
| check_in | No | Check-in date (YYYY-MM-DD) | |
| check_out | No | Check-out date (YYYY-MM-DD) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the tool returns a boolean, list of available dates, or requires both check_in and check_out. This lack of transparency makes it harder for an AI agent to predict the tool's 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?
Single concise sentence with no unnecessary words. The structure is efficient and easy to parse.
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?
No output schema is provided, and the description does not specify the return format (e.g., boolean, list of dates, availability message). This gap makes the tool less complete for an agent to understand its behavior fully.
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 100% with descriptions for all three parameters. The description adds only a generic reference to 'specific dates', not enhancing understanding beyond the schema. Baseline score of 3 is appropriate.
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 verb 'check', the resource 'availability for a rental property', and the scope 'on specific dates'. It distinguishes this tool from siblings like rental_search or rental_property, making its purpose 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?
No guidance on when to use this tool versus alternatives (e.g., rental_search, rental_property). The description lacks context about prerequisites (e.g., having a specific rental ID) or situations where this tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_compare_platformsAInspectCompare pricing for the same property across different platforms (Airbnb, VRBO, local agencies, direct booking). Shows rate spread and savings.
| Name | Required | Description | Default |
|---|---|---|---|
| rin | Yes | Rental Identification Number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It indicates a read operation (compare/show), but does not disclose data freshness, API limits, or behavior if property not on all platforms. Adequate for a simple tool but lacks depth.
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, focused sentence of 16 words. No redundant information. Efficient and clear.
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?
No output schema, but description hints at return format ('shows rate spread and savings'). Context signals are good (1 param, 100% coverage). Could mention whether results are tabular or comparative, but sufficient for a simple 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 100% for 'rin' (Rental Identification Number). Tool description does not add additional meaning beyond schema. Baseline 3 is appropriate.
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 specific verb 'Compare pricing' and identifies the resource 'same property across different platforms'. Clearly distinguishes from siblings like rental_price_history (price over time) and rental_property (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?
States the tool compares pricing across platforms and shows rate spread/savings, but does not explicitly mention when to use this tool versus alternatives like rental_price_history or rental_sources. Context is clear but lacks explicit comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_license_lookupBInspectLook up government tourism accommodation license for a property. In Cayman Islands, unlicensed operation carries $100,000/day fine.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | License number, property name, or address to search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions only the tool's basic function and a legal context (Cayman Islands fine), but omits important details like authentication requirements, rate limits, or behavior when no license is found. This leaves the agent with limited behavioral understanding.
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 long, with the key action front-loaded in the first sentence. The second sentence, while providing useful context, is not strictly necessary for tool selection. Overall, it is efficient but could be trimmed without losing core purpose.
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 is simple (one parameter, no output schema), yet the description fails to explain what the tool returns (e.g., license details, owner name, status). It also leaves ambiguity about whether the tool is exclusive to Cayman Islands. Without annotations, these gaps hinder the agent's ability to interpret results.
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 100% with a single 'query' parameter described as 'License number, property name, or address to search.' The description does not add new parameter-level meaning beyond the schema; it only provides extra context about the Cayman Islands jurisdiction. Baseline of 3 is appropriate as the schema already does the heavy lifting.
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: 'Look up government tourism accommodation license for a property.' It uses a specific verb ('look up') and resource ('license'), and differentiates from siblings like rental_property or rental_search that handle broader property information.
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 explicit guidance on when to use this tool versus alternatives is provided. The description implies usage for license checks but does not specify when-not or name sibling tools as alternatives. Given the absence of such direction, the score is 3 (implied only).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_marketsAInspectGet market intelligence for Caribbean rental markets: average rates, occupancy estimates, property counts, seasonal patterns.
| Name | Required | Description | Default |
|---|---|---|---|
| island | No | Island name | |
| country | No | Country code: KY or LC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states the tool provides market intelligence data, implying read-only behavior, but does not explicitly confirm non-destructiveness, auth requirements, or rate limits. The description adds value by listing return data types but lacks comprehensive behavioral context.
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, efficient sentence using a colon to introduce the data list. It is front-loaded with the action and resource, with no wasted 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?
The description lists returned data types but does not clarify default behavior when no parameters are provided, whether results are aggregated for all islands, or the output structure. With no output schema, more detail on return format would improve completeness.
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 100% with both parameters having descriptions ('Island name' and 'Country code: KY or LC'). The tool's description adds 'Caribbean' context but does not significantly augment parameter meaning beyond the schema. Baseline 3 is appropriate.
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 verb 'Get' and specifies the resource as 'market intelligence for Caribbean rental markets,' listing specific data points (average rates, occupancy estimates, property counts, seasonal patterns). It distinguishes itself from sibling tools like rental_search and rental_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?
The description implies usage for retrieving Caribbean rental market data but does not provide explicit guidance on when to use this tool versus alternatives like rental_stats or rental_price_history. No when-not-to-use or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_orientationAInspectGet orientation context. READ THIS FIRST. You are the buyer's agent. The workflow is: (1) rental_search, (2) rental_session_create, (3) rental_session_add your picks, (4) share the bridge URL with your human.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 implies a read-only info tool but does not explicitly state that it is safe, idempotent, or has no side effects. The description lacks transparency about its behavioral traits.
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: one sentence followed by a numbered list. Key information is front-loaded ('READ THIS FIRST'). Every sentence serves a purpose with zero waste.
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 provides the essential workflow context. However, it does not explain what the tool returns or how to interpret the 'orientation context,' leaving some ambiguity for a first-time agent.
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 input schema has no parameters, so schema coverage is 100%. Per the rubric, the baseline is 3. The description adds no parameter information, but none is needed.
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 states 'Get orientation context' and positions itself as the first tool to read, clearly indicating its purpose as an introduction. It distinguishes from siblings by being the initial step.
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 explicitly says 'READ THIS FIRST' and outlines the exact workflow sequence: (1) rental_search, (2) rental_session_create, (3) rental_session_add, (4) share bridge URL. This provides excellent guidance on when to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_price_historyAInspectView nightly rate history for a property over time.
| Name | Required | Description | Default |
|---|---|---|---|
| rin | Yes | Rental Identification Number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of disclosing behavioral traits. It merely states 'View', implying a read-only operation, but fails to mention potential constraints like data range, pagination, or required permissions. The description is insufficient for safe usage.
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 communicates the tool's core function without extraneous words. Every word serves a purpose.
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 one parameter and no output schema, the description is adequate but minimally complete. It does not describe the return format (e.g., list of prices with dates) or any edge cases, leaving some uncertainty about what the agent can 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?
The schema already provides full coverage (100%) for the single parameter rin with description 'Rental Identification Number'. The tool description adds no further semantic value beyond what the schema defines, so a baseline score of 3 is appropriate.
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 the specific verb 'View' and clearly identifies the resource as 'nightly rate history' for a property over time. It effectively distinguishes this tool from siblings like rental_availability, rental_property, or rental_stats by specifying its focus on historical pricing.
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 provide explicit guidance on when to use this tool versus alternatives like rental_availability or rental_stats. It only implies usage for viewing historical rates, but no context about prerequisites or limitations is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_propertyAInspectGet full details for a rental property by its RIN (Rental Identification Number). Returns property info, all platform listings, reviews, license status, and price history.
| Name | Required | Description | Default |
|---|---|---|---|
| rin | Yes | Rental Identification Number (e.g., RIN-abc123def456) |
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 clearly describes what the tool returns (property info, listings, reviews, license status, price history), which is sufficient for a read operation. It does not mention potential side effects or restrictions, but being a read-only lookup, this is adequate.
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 that efficiently conveys the tool's purpose and output, with no wasted words or 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?
Given the tool's simplicity (one parameter, no output schema), the description is complete: it explains what data is returned and the input required. It provides sufficient context for an agent to understand the tool's role among siblings.
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 100% with a single parameter 'rin' that includes an example. The description does not add additional meaning beyond the schema, so 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 explicitly states 'Get full details for a rental property by its RIN' and enumerates the kinds of data returned (property info, listings, reviews, license status, price history), making the purpose clear and distinct from sibling tools that focus on subsets.
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 (retrieve comprehensive property details) but does not explicitly state when not to use or mention alternatives like rental_reviews or rental_price_history for more specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_reviewsBInspectGet aggregated review data for a property across all platforms.
| Name | Required | Description | Default |
|---|---|---|---|
| rin | Yes | Rental Identification Number |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not cover behavioral traits like rate limits, pagination, caching, or whether the data is real-time or aggregated snapshots. For a tool with no annotations, the description should compensate but only states the basic purpose.
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 with no redundancy. Every word adds value, and the most critical information (verb, resource, scope) 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?
Given the lack of output schema and annotations, the description is incomplete. It does not explain what 'aggregated review data' entails (e.g., average rating, distribution, sample counts) or any limitations. For a tool returning complex data, more detail is needed.
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 100% with a clear description for 'rin' ('Rental Identification Number'). The description adds context ('aggregated review data') but does not provide additional parameter semantics beyond the schema. Baseline of 3 is appropriate.
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 clearly identifies the resource ('aggregated review data') and scope ('for a property across all platforms'). It effectively distinguishes from sibling tools like 'rental_property' (property details) and 'rental_stats' (statistical data).
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, such as 'rental_reviews' vs. 'rental_stats' for review summaries. There is no mention of prerequisites, restrictions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_searchAInspectSearch vacation rental properties in the Caribbean. YOU ARE THE BUYER'S AGENT — search on behalf of your human. After searching, create a session (rental_session_create) and add your best picks (rental_session_add). Share the bridge URL with your human.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text search across name, description, region | |
| limit | No | Results per page (default 20, max 50) | |
| island | No | Island name: Grand Cayman, Cayman Brac, Little Cayman, St. Lucia | |
| region | No | Region: Seven Mile Beach, North Side, Rum Point, West Bay, Soufriere, Rodney Bay, etc. | |
| sleeps | No | Minimum guests the property sleeps | |
| amenity | No | Required amenity: pool, beach_access, ocean_view, wifi, kitchen, ac, parking | |
| country | No | Country code: KY (Cayman Islands) or LC (St. Lucia) | |
| bedrooms | No | Minimum bedrooms | |
| max_price | No | Maximum nightly rate in USD | |
| min_price | No | Minimum nightly rate in USD | |
| property_type | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description identifies it as a search operation (read-only) but does not disclose any behavioral traits like rate limits, caching, or response format. Minimal added value beyond purpose.
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 plus workflow instruction. Every sentence adds value: purpose, role, follow-up actions. 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?
With 11 parameters, no output schema, and no annotations, the description covers the essential usage flow. Missing details about output structure or special behavior, but the workflow guidance compensates.
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 high (91%), so the schema already documents parameters well. Description adds no extra meaning or usage hints for individual parameters.
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 'Search vacation rental properties in the Caribbean' with specific verb and resource. Distinct from siblings like rental_property (single property) and rental_availability (availability check).
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 instructs the agent to act as buyer's agent, search, then create session and add picks, sharing bridge URL. Provides clear workflow context and distinguishes from subsequent steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_session_addAInspectAdd a property to your human's bridge page. Include a score (1-10) and explain WHY this property fits their needs. You are their buyer's agent — only recommend properties you believe match. The human sees your score and notes on their page.
| Name | Required | Description | Default |
|---|---|---|---|
| rin | Yes | Property RIN to add | |
| notes | No | Why this property matches | |
| score | No | Fit score 1-10 | |
| session | Yes | Session hash | |
| agent_id | No |
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 does disclose that the human sees the score and notes, implying the action is visible to the user. However, it does not mention side effects, limits, reversibility, or any required permissions for the mutation.
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 relatively concise but includes instructional text directed at the agent ('You are their buyer's agent...') which, while useful, could be trimmed. The main action is front-loaded. Overall, it's well-structured but not perfectly minimal.
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 5 parameters and no output schema, the description provides some context (e.g., the human sees the notes) but lacks explanation of the bridge page concept, what happens after adding, and how the session parameter is used. Sibling tools like rental_session_read hint at follow-up actions but are not mentioned.
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 80%. The description reinforces the meaning of parameters (e.g., 'Include a score (1-10)') but adds little beyond the schema's own descriptions. For the undocumented parameter agent_id, the description offers no additional semantic context.
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 action: 'Add a property to your human's bridge page.' It specifies the tool's purpose as recommending properties as a buyer's agent. The verb 'add' is specific, and the resource 'bridge page' distinguishes it from sibling tools like rental_session_create or rental_session_read.
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 clear guidance on when to use this tool: when recommending a property the agent truly believes fits the human's needs. It emphasizes the agent's role as a buyer's agent and instructs to include a score and notes. However, it does not explicitly mention when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_session_createAInspectIMPORTANT: Create this FIRST when helping someone find a rental. Returns a shareable URL (bridge page) where your recommendations appear. Your human opens this page to see your curated picks, photos, pricing, and inquiry buttons. After creating, add properties with rental_session_add, then SHARE THE URL with your human.
| Name | Required | Description | Default |
|---|---|---|---|
| guests | No | ||
| agent_id | No | Your agent identifier (claude, gpt, grok, etc.) | |
| check_in | No | YYYY-MM-DD | |
| check_out | No | YYYY-MM-DD | |
| budget_max | No | Max nightly rate USD | |
| preferences | No | Free text: beachfront, pool, quiet, family-friendly, etc. | |
| bedrooms_min | No | ||
| destination_island | No | ||
| destination_country | No | KY or LC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the return value (shareable URL) and the follow-up actions, but does not discuss potential side effects (e.g., whether the session is temporary) or permission requirements. Overall adequate.
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, front-loaded with 'IMPORTANT,' and conveys the critical workflow in just a few sentences. Every sentence serves a purpose 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?
Given the tool's complexity (9 parameters, no required ones, no output schema), the description covers the essential workflow and return value. It could briefly mention what the session object is, but the overall guidance is sufficient for correct 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 67% (6 of 9 parameters documented). The description does not add additional meaning beyond what the schema already provides. Baseline at this coverage is 3, and the description does not compensate by explaining parameter relationships.
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 purpose: 'Create this FIRST when helping someone find a rental.' It explains what it returns (a shareable URL) and how it fits into the workflow, distinguishing it from siblings like rental_session_add.
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 usage guidance: create first, then add properties, then share the URL. While it clearly indicates when to use this tool, it does not explicitly state when not to use it or provide alternatives beyond the sibling context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_session_readCInspectRead a bridge session: see all added properties, messages, and status.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session hash | |
| agent_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description minimally indicates a read operation but fails to disclose behavioral traits like read-only guarantee, authentication needs, rate limits, or side effects.
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 extra words. However, it sacrifices completeness for brevity.
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 annotations, incomplete schema documentation, and no output schema, the description is insufficient. It lacks information on return structure, error states, or usage constraints needed for correct 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 50% (only 'session' has a description). The tool description adds no parameter meaning beyond 'see all added properties, messages, and status', which does not clarify 'agent_id' or how to format 'session hash'.
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 reads a bridge session and displays added properties, messages, and status. It distinguishes from sibling tools like rental_session_add and rental_session_create by indicating a read operation, but does not explicitly differentiate.
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 on when to use this tool versus siblings or other tools. No context about prerequisites or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_sourcesAInspectView all tracked data sources with AI-readability assessment. Shows which rental sites AI can read, which are partially readable, and which block AI entirely.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It explains the output (readability categories) but omits side effects (none expected), authentication needs, rate limits, or data freshness. The read-only nature is implied but not explicitly stated.
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?
A single sentence that is front-loaded and conveys all necessary information. No redundant words; every part 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 (no parameters, no output schema, straightforward read operation), the description is sufficiently complete. It covers the tool's purpose, output, and scope without requiring additional 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?
The tool has zero parameters and 100% schema description coverage, so the description need not add parameter meaning. The baseline score for 0 parameters is 4; the description adds no extra parameter info but that is acceptable.
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 purpose: 'View all tracked data sources with AI-readability assessment.' It specifies the resource (tracked data sources) and the assessment categories (readable, partially readable, blocked). This distinguishes it from sibling tools like rental_search or rental_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 implies use when checking AI-readability of rental sites, but provides no explicit guidance on when to use or avoid this tool versus alternatives. No usage examples or exclusions are given, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
rental_statsAInspectGet database statistics: total properties, by country, by island, platform coverage, source counts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only lists output categories but does not mention whether the tool is read-only, requires authentication, or has any side effects or performance implications.
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 that front-loads the action ('Get database statistics') and efficiently lists the topics. Every word contributes meaning.
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 parameters and no output schema, so the description must explain return values. It lists categories but does not specify the structure (e.g., object vs. array) or format of the counts. For a simple stats tool, it is minimally adequate but could be more explicit.
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 input schema has no parameters, so schema coverage is 100%. The baseline for 0 parameters is 4, and the description adds value by listing the output categories, clarifying what statistics are returned.
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 states 'Get database statistics' with a clear verb and resource, and lists specific categories (total properties, by country, by island, platform coverage, source counts), distinguishing it from sibling tools like rental_property or rental_search.
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 that this tool is for aggregate database statistics, but it does not provide explicit guidance on when to use it vs. siblings (e.g., rental_compare_platforms) or when not to use it. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
searchAInspectSearch Turks & Caicos rentals and island venues (restaurants, dive shops, marinas, attractions) by keyword. Returns results with id, title, and url. Then call fetch with an id for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Keywords, e.g. "beachfront villa", "dive shop", "italian restaurant near Grace Bay" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes output shape (id, title, url) and workflow direction (call fetch for detail). No annotations exist, so description carries full burden; it adequately discloses the tool's behavior without contradictions.
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 clear sentences, no wasted words. Front-loaded with purpose, then output and follow-up. Perfect structure 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?
Given simplicity (1 param, no output schema), the description is mostly complete: tells what it searches, what it returns, and what to do next. Lacks details on pagination, errors, but adequate for a straightforward search.
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 one parameter (query) with 100% schema coverage and example in the schema. Description adds marginal value by repeating 'e.g. "beachfront villa"', but baseline 3 is appropriate since schema already provides meaning.
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 verbs and resources: 'Search Turks & Caicos rentals and island venues...by keyword'. It clearly distinguishes from siblings like 'fetch' (which retrieves full detail by id) and 'rental_search' (which likely focuses only on rentals).
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?
Tells when to use: for keyword search across multiple listing types. Explicitly instructs to 'Then call fetch with an id for full detail', providing clear next-step guidance. However, it doesn't specify when not to use or contrast with other sibling tools beyond fetch.
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!
