Verified facts and direct-booking handoff for five Travellers Group hotels in regional Australia.
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.5/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose: availability returns a pre-filled link, enquiries are separated by type, corporate info is separate from general property info, distances vs events vs rates vs room types vs town guide vs search vs recommendation. The only potential confusion is between create_enquiry and create_corporate_enquiry, but descriptions clarify the target audience. Overall, no ambiguity.
All tool names consistently follow a verb_noun pattern in snake_case (e.g., check_availability, get_distances, create_enquiry). The verbs are appropriate (check, create, get, recommend, search) and nouns clearly indicate the resource. No mixing of styles or vague verbs.
With 12 tools, the server is well-scoped for a hotel information and enquiry system. Each tool covers a distinct aspect of the domain without overlap or unnecessary bloat. The count is within the optimal range (3-15) for an MCP server.
The tool set covers core hotel information retrieval (property, rooms, rates, distances, events, town guide) and enquiry creation (general and corporate). However, there is no tool to complete a booking or confirm availability beyond a link. This is a minor gap; agents must hand off to the booking engine. Overall, the surface is mostly complete for its stated purpose.
check_availabilityBTier A handoff: returns a dated, pre-filled booking-engine link — LIVE availability and pricing are at that link. This tool never asserts that dates are available.
| Name | Required | Description | Default |
|---|---|---|---|
| adults | No | ||
| check_in | Yes | YYYY-MM-DD | |
| children | No | ||
| property | Yes | ||
| check_out | Yes | YYYY-MM-DD |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description clarifies that the tool never asserts availability and returns a pre-filled link, providing essential 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 extremely concise with two sentences, front-loading the key information without any 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 covers the main function but omits details like the exact return format and any required authorization or rate limits, leaving some ambiguity.
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 description does not explain any parameters. With only 40% schema coverage, the agent is left uncertain about the meaning of 'property', 'adults', and 'children'.
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 it returns a booking-engine link, not direct availability, which distinguishes it from tools like get_indicative_rates. However, it does not explicitly contrast with all sibling 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 lacks explicit guidance on when to use this tool versus alternatives like get_indicative_rates. The term 'Tier A handoff' is ambiguous, and there is no mention of 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.
create_corporate_enquiryAInspectCorporate-account or group-booking enquiry, routed to the Travellers Group corporate team. Requires guest consent, as with create_enquiry.
| Name | Required | Description | Default |
|---|---|---|---|
| company | Yes | ||
| contact | Yes | ||
| context_summary | Yes | ||
| consent_confirmed | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds consent requirement and routing information beyond annotations, but does not detail response, side effects, or failure modes. Annotations already mark as non-read-only, so description provides modest added 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?
Two concise sentences, front-loaded with purpose and key requirement. No fluff, but could be more detailed given parameter count.
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?
Fails to cover required parameters, nested object structure, output expectations, or failure behavior. Underwhelming for a 4-param 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?
With 0% schema description coverage, description should explain required parameters. It only touches on consent_confirmed, leaving company, contact, and context_summary unexplained. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a corporate-account or group-booking enquiry routed to the corporate team, distinguishing it from sibling create_enquiry for regular enquiries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for corporate/group bookings, with mention of consent requirement. Does not explicitly state when not to use, but the context of sibling tools and 'corporate' qualifier provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_enquiryAInspectSends a booking enquiry to the property team (groups, crews, blocks, weekly stays, functions). Requires the guest’s explicit consent to pass their details and conversation context to the property.
| Name | Required | Description | Default |
|---|---|---|---|
| dates | No | ||
| party | No | ||
| contact | Yes | ||
| property | Yes | ||
| context_summary | Yes | Party, dates, purpose, questions asked — so the team replies informed | |
| consent_confirmed | Yes | Must be true: the guest has consented to their details + context being sent to the property |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's not read-only and not idempotent; description adds that it sends to the property team and requires consent, which is useful context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and key requirement, 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?
Covers the essential action and consent requirement, but lacks information on error handling, confirmation, or when not to use, given the tool's complexity (6 params, nested objects).
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 low (33%) and the description only minimally elaborates on parameters beyond what's in the schema (e.g., context_summary 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 it sends a booking enquiry and lists covered areas (groups, crews, etc.), but does not differentiate from the sibling tool 'create_corporate_enquiry'.
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 mentions the prerequisite of explicit consent, but gives no guidance on when to use this tool versus alternatives like 'create_corporate_enquiry'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_corporate_account_infoBThe Travellers Group corporate-account answer as data: one account, five properties, direct billing and consolidated invoicing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds context about returned data (one account, five properties, direct billing, consolidated invoicing), but does not disclose behavior like response format, consistency guarantees, or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence but somewhat cryptic and not fully front-loaded. Could be more direct and concise.
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 zero parameters and no output schema, the description should clearly state the tool's purpose and return value. It mentions some features but is vague about what exactly is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter details. Baseline 4 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 mentions 'corporate-account answer as data' and lists features, but does not clearly state the action (e.g., 'Retrieve corporate account information'). It is distinguishable from siblings like 'get_property' by focusing on corporate accounts.
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 such as 'get_property' or 'search_content'. There is no mention of prerequisites or filtering context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_distancesBMeasured distances from a property (km, drive/walk minutes) to hospitals, mines, airports, venues, wineries. Fuzzy destination filter ('the zoo', 'hospital'). Serves published measured figures only.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | ||
| property | No | ||
| destination | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds behavioral context: 'Serves published measured figures only' indicates no real-time computation, and 'Fuzzy destination filter' indicates matching behavior. This goes beyond annotations with useful details.
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 brief and front-loaded with key information. No redundant sentences, but structure is somewhat fragmented (uses incomplete phrases like 'Serves published measured figures only.') that could be clearer.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides units of measure (km, minutes) but does not specify the return format (list vs. single value) or how results are structured. It covers the core functionality but lacks detail on response shape.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the 'property' and 'destination' parameters implicitly (property as origin, destination as fuzzy target), but 'town' is not explained. Lack of clarity on parameter roles and constraints reduces utility.
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 identifies the tool's purpose: measuring distances from a property to various points of interest like hospitals, mines, airports. It specifies units (km, drive/walk minutes) and mentions fuzzy destination filtering. However, it does not explicitly differentiate from sibling tools, though the context suggests it is unique.
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 when distances to fuzzy destinations are needed, but does not provide explicit when-to-use or when-not-to-use guidance. It does not mention alternatives among siblings, though the context signals help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_eventsBVerified events for a town. Serves only entries published with explicit dates — never extrapolates a date.
| Name | Required | Description | Default |
|---|---|---|---|
| town | Yes | ||
| to_date | No | ||
| from_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is read-only (readOnlyHint=true). The description adds behavioral context by stating it 'never extrapolates a date' and serves only 'published' entries, which is useful beyond annotations, but lacks details on error handling or response format.
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 no redundant words. It front-loads the core action ('Verified events for a town') and adds a critical constraint in the second sentence.
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 has 3 parameters (1 required) and no output schema, the description lacks details about parameter usage, return format, or potential edge cases (e.g., no events). This is insufficient for an agent to invoke the tool confidently.
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%, yet the description only mentions 'town' implicitly ('for a town') and does not explain the date parameters (to_date, from_date). The description fails to add meaning beyond the raw schema for any parameter.
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 'Verified events for a town' and specifies a key constraint: only entries with explicit dates are served. This provides a clear verb-resource pair and differentiates from potential sibling tools that might extrapolate dates.
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 the tool should be used when needing verified events with explicit dates for a town, but it does not explicitly state when to use or not use it, nor does it reference alternative tools like search_content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_indicative_ratesAIndicative rate ranges from the published, commercially-signed rate module only — framed as indicative, never a quote. Where no figure is published, returns the booking link instead (never an estimate).
| Name | Required | Description | Default |
|---|---|---|---|
| property | Yes | ||
| room_type | No | ||
| stay_band | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides significant behavioral context beyond the readOnlyHint annotation, clarifying that the tool never returns quotes, only indicative ranges, and that it may return a booking link. This is consistent with the annotations and adds 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 extremely concise with two sentences that convey the essential purpose and behavior. Every word contributes to understanding, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description explains the tool's output clearly, it fails to address the input parameters or provide usage context for the 3-parameter schema. Without output schema, the agent lacks complete information to correctly invoke the 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?
The input schema has 0% coverage for parameter descriptions, and the description does not mention any of the three parameters (property, room_type, stay_band) or their meanings. The agent receives no guidance on how to use these parameters, which is a critical gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool returns indicative rate ranges from the published, commercially-signed rate module, and distinguishes it from a quote. It also explains the fallback to a booking link when no figure is published, effectively differentiating it from sibling tools like 'check_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 explains when to use the tool (to get indicative rates) and what it returns (rate ranges or booking link). However, it does not explicitly mention when not to use it or compare it to alternatives, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_propertyBCanonical entity record for a Travellers Group property: address, contacts, quick facts, policies, booking URL, parent entity.
| Name | Required | Description | Default |
|---|---|---|---|
| property | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so no contradiction. Description adds context about the record being 'canonical' and lists data types, but fails to mention any permissions, rate limits, or response size. Acceptable but not excellent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence front-loads the core purpose and data list. Efficient, though the colon-separated list could be clearer. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description covers the basics. However, lack of parameter guidance and usage context makes it less complete, considering the sibling tool set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must explain parameters. It does not mention the 'property' parameter at all, leaving the agent to infer from the name and constraints. Should clarify what constitutes a property identifier (e.g., code vs name).
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 it retrieves a canonical property record with specific data categories (address, contacts, etc.), but does not explicitly differentiate from sibling tools like get_distances.
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 such as get_room_types or search_content. The description assumes the agent will infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_room_typesARoom catalogue for a property: occupancy, bedding, amenities, who-it-suits, booking deep link per room. traveller_context re-ranks honestly — it never invents inclusions.
| Name | Required | Description | Default |
|---|---|---|---|
| property | Yes | ||
| traveller_context | No | e.g. 'crew of 4, weekly' or 'couple, wine weekend' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true. Description adds specific behavioral detail: traveller_context re-ranks honestly and never invents inclusions, which is valuable beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise, front-loaded sentences with no waste. First sentence states primary output; second sentence clarifies a specific behavioral aspect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only catalogue tool with no output schema, the description covers core functionality and key param behavior. Minor missing details like result format are not critical.
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 50% (only traveller_context has description). Description adds meaning for traveller_context (re-ranking behavior) but no extra for property. Partially compensates for schema gaps.
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 specifies the tool returns room catalogue data (occupancy, bedding, amenities, etc.) and uniquely mentions traveller_context re-ranking. It is distinct from siblings like get_property and check_availability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternative siblings. The purpose is clear but without contextual when/when-not advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_town_guideATown knowledge layer: open-late, essentials, eat, with-kids, working-in, hospital-visitor, itineraries. Unbuilt topic returns 'not yet published' plus the town guide root.
| Name | Required | Description | Default |
|---|---|---|---|
| town | Yes | ||
| topic | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds useful behavioral info: unbuilt topics return 'not yet published' plus the town guide root. This complements annotations (readOnlyHint, openWorldHint). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no redundant words. Efficient.
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; description explains behavior for unbuilt topics but does not describe normal return structure or data format. Adequate but could be more 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?
Schema has 2 params with 0% description coverage. Description lists some topic enum values but not all (missing 'things-to-do'). Adds marginal value; does not fully compensate for lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the tool returns town guide content for specific topics, listing examples. It distinguishes from sibling tools like check_availability or create_enquiry.
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 vs alternatives. Does not mention when not to use or provide recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_propertyAHonest matching across the Travellers portfolio. If no Travellers property suits the need, says so plainly and names the accommodation category that does. Never oversells. [Templates DRAFT pending G1.]
| Name | Required | Description | Default |
|---|---|---|---|
| need | No | e.g. 'towing a caravan', 'pet friendly', 'crew of 6 near the hospital' | |
| town | No | ||
| context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds valuable behavioral context: the tool will be honest, not oversell, and recommend outside the portfolio if necessary. This is helpful for an agent to understand 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?
The description is brief (3 sentences) and front-loaded with the purpose. However, the note '[Templates DRAFT pending G1.]' is extraneous and reduces clarity for a production agent. Otherwise, each sentence 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?
For a recommendation tool without an output schema, the description explains the tool's philosophy but does not cover return format, parameter dependencies, or error cases. It is minimally adequate given the tool's simplicity, but gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 33% schema coverage, the description does not elaborate on the three parameters (need, town, context). It provides no hints on formatting or usage beyond the schema's example for 'need'. The description adds minimal value for parameter understanding.
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 matches across the Travellers portfolio honestly, distinguishes itself by admitting when no property suits and naming an alternative category. The verb 'matching' and resource 'portfolio' are specific, and the tie to sibling tools like 'get_property' is apparent.
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 property recommendations, but does not explicitly state when to use it versus alternatives like 'get_property' or 'check_availability'. No 'when not to use' or alternative names are given; usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_contentASearch the published six-site Travellers Group corpus (guides, hubs, FAQs, pages). Returns ranked answer capsules (≤120 words) with canonical URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| town | No | Bundaberg | Rockhampton | Emerald | Orange | Dubbo | |
| type | No | ||
| query | Yes | What the traveller wants to know, in their own words | |
| property | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds value beyond the annotations (readOnlyHint) by specifying the output format: ranked answer capsules (≤120 words) with canonical URLs. This tells the agent what to expect, though it omits details like pagination or response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that starts with the core action and resource. It is extremely concise, with no wasted words, and every element 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?
The description provides adequate context about what the tool searches and returns, but it lacks details on parameter usage, pagination, or sorting behavior. Given the moderate parameter count and no output schema, more explanation 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?
The schema description coverage is 50%, and the tool description adds no additional meaning to the parameters. It does not explain how parameters like 'type' or 'property' affect the search, leaving the agent to infer from enum values and parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches a specific corpus (six-site Travellers Group) of content types (guides, hubs, FAQs, pages). The verb 'search' and the resource are explicit, and the scope distinguishes it from sibling tools like get_town_guide or get_property.
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 no guidance on when to use this tool versus alternatives. It does not specify when not to use it or mention any prerequisites or context for invocation, leaving the agent without decision-support.
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!