ski-france.com Agent Search
Server Details
Search about 9,000 ski apartments plus ski passes, prices, availability and destinations.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.4/5 across 10 of 10 tools scored.
Each tool has a clearly distinct purpose: separate tools for different entity details (accommodation, ski area, resort), distinct search vs. list operations, and specialized tools for ski pass prices and search vocabulary. No overlapping functionality.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_accommodation_detail, list_ski_areas, search_apartments). Verbs are appropriately chosen (get, list, search, resolve), and there are no mixed conventions.
With 10 tools covering destination discovery, accommodation details, apartment search, pricing, and search utilities, the count is well-scoped for a ski accommodation search domain. No unnecessary tools or missing essentials.
The tool set covers the full user journey: vocabulary setup (get_search_options), keyword resolution (resolve_search_keywords), destination lists (list_ski_areas/resorts), accommodation lists (list_accommodations), detailed info (get_*_detail), apartment search with pricing (search_apartments), and ski pass pricing (get_ski_pass_prices). No obvious gaps for an information/query-focused server.
Available Tools
10 toolsget_accommodation_detailGet accommodation detailARead-onlyIdempotentInspect
Return accommodation-level context, apartment list, images, detail information and weekly availability for one public accommodation. Use this after search results to inspect all apartments belonging to one accommodation and to explain location, descriptions and detail notes. For price and bookability comparison for a specific week, prefer search_apartments with weekId.
| Name | Required | Description | Default |
|---|---|---|---|
| accommodationId | Yes | Accommodation id from search results or list_accommodations. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds operational detail beyond annotations, such as returning weekly availability and apartment list. Annotations already confirm read-only, idempotent, non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with zero waste: first defines output, second gives usage context, third provides alternative. Well-structured and 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 no output schema, the description covers key return contents (context, apartments, images, detail, availability) and usage context. Could optionally mention pagination or size limits, but adequate for the tool's simplicity.
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 fully describes the only parameter with 100% coverage. The description mentions the parameter source but adds no new format or constraint info beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it returns accommodation-level context, apartment list, images, detail information, and weekly availability for one public accommodation. It distinguishes from sibling tools like search_apartments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states when to use: after search results to inspect apartments of one accommodation. It also provides an alternative: prefer search_apartments for price comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_search_optionsGet search optionsARead-onlyIdempotentInspect
Return the current search vocabulary before building a structured search: fixed winter arrival weeks with weekId values, party-size guidance, feature filter values, supported language subdomains and discovery links. Use this first when you need valid weekId, filters or language options.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful context about the returned data (weeks, filters, etc.), which is consistent with annotations and useful for an agent.
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 short, focused sentences. The first sentence states the purpose and output; the second gives usage guidance. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description adequately covers what the tool returns (weeks, party-size, filters, language, discovery links). For a simple tool with 0 parameters, this is complete and actionable.
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 (0 params, 100% schema coverage). The description correctly does not need to add parameter info. Baseline of 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 clearly states the tool returns 'current search vocabulary' and lists specific items (weekId values, party-size guidance, filter values, language subdomains, discovery links). It distinguishes itself from sibling get/list tools by focusing on search options.
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 advises to 'Use this first when you need valid weekId, filters or language options,' providing clear contextual guidance. No exclusion of alternatives, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ski_area_detailGet ski area detailARead-onlyIdempotentInspect
Return public ski area information, facts, images, ski maps and related ski resorts. Use this for destination context and recommendations, not for apartment prices or availability; use search_apartments for live week-specific accommodation results.
| Name | Required | Description | Default |
|---|---|---|---|
| skiAreaId | Yes | Ski area id from list_ski_areas. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description does not add any behavioral traits beyond these. No mention of authentication needs, data freshness, or output characteristics, but the annotations sufficiently cover the core behavioral aspects.
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, front-loads the core function, and provides usage guidance without any unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema), the description adequately covers what the tool returns and when to use it. A slight improvement would be to mention the output format or typical data structure, but it's not critical for a straightforward read endpoint.
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% (the only parameter 'skiAreaId' has a description in the schema: 'Ski area id from list_ski_areas.'). The tool description adds no additional meaning for the parameter, so the 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 it returns public ski area information including facts, images, ski maps, and related resorts. It identifies the resource as 'ski area detail' but does not explicitly distinguish from sibling tools like get_ski_resort_detail or get_accommodation_detail, though the exclusion of apartment prices provides some differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('for destination context and recommendations') and when not to use it ('not for apartment prices or availability'), and provides a direct alternative: 'use search_apartments for live week-specific accommodation results.' This is excellent guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ski_pass_pricesGet ski pass pricesARead-onlyIdempotentInspect
Return ski pass weeks, durations and price tables with listPrice, discount and discountedPrice. Restrict by skiAreaId, skiResortId or accommodationId for destination-specific ski pass discovery. A global request without destination scope must provide weekId to avoid an overly broad price matrix. Omit durationDays to discover available durations with prices.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Result page, starting at 1. | |
| limit | No | Results per page. Maximum is 50. | |
| weekId | No | Optional fixed weekly winter arrival date id. Required when no skiAreaId, skiResortId or accommodationId is provided. Omit it only for destination-scoped ski pass discovery. | |
| skiAreaId | No | Optional ski area id from list_ski_areas. | |
| skiResortId | No | Optional ski resort id from list_ski_resorts. | |
| durationDays | No | Optional ski pass duration in days. Omit it to return all available durations with prices. Default website duration is 6 days. | |
| accommodationId | No | Optional accommodation id from search_apartments, list_accommodations or get_accommodation_detail. Uses the accommodation ski resort. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: return pricing, requires weekId if no destination scope, omitting durationDays gives available durations. No 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?
Three concise sentences, front-loaded with core function, then constraints. 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 main logic: return pricing, destination scoping, weekId rule, durationDays behavior. Pagination not explained but typical. Complete enough for the tool's purpose.
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%, baseline 3. Description adds context beyond schema: explains why to omit durationDays, ties parameters together (weekId required without destination IDs).
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 ski pass weeks, durations, and price tables with specific fields. It distinguishes from sibling tools by mentioning destination-specific scope and global request requirements.
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?
Provides explicit guidance on when to use destination IDs vs weekId, and when to omit durationDays. Lacks explicit when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_ski_resort_detailGet ski resort detailARead-onlyIdempotentInspect
Return public ski resort information, location, facts, images and ski maps. Use this for explaining and comparing destinations, not for apartment prices or availability; use search_apartments for live week-specific accommodation results.
| Name | Required | Description | Default |
|---|---|---|---|
| skiResortId | Yes | Ski resort id from list_ski_resorts. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint. Description adds context that info is 'public' and lists specific content (images, maps), but does not fully detail behavior beyond that. Contradiction is false.
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: first states purpose, second provides usage guidance. Front-loaded, no unnecessary 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?
For a simple tool with one parameter and no output schema, the description covers purpose, content, and usage context completely. No additional information 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 clear description for the single parameter (skiResortId from list_ski_resorts). Description does not add further meaning, so 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?
Description clearly states it returns public ski resort information (location, facts, images, ski maps) with specific verb 'Return' and resource. It distinguishes from siblings by stating it is for explaining/comparing destinations, not for apartment prices/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?
Explicitly provides when to use (explaining/comparing destinations) and when not to use (not for apartment prices/availability), and directs to alternative tool 'search_apartments' for live week-specific results.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accommodationsList accommodationsARead-onlyIdempotentInspect
List public accommodations for catalogue discovery, optionally filtered by ski area, ski resort or district ids from the destination tools. This list intentionally has no prices, availability or bookability. Use search_apartments with weekId for price and availability comparison, and get_accommodation_detail after a result for accommodation context.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Result page, starting at 1. | |
| limit | No | Results per page. Maximum is 200. | |
| skiAreaId | No | Optional ski area id from list_ski_areas. | |
| districtId | No | Optional district id from accommodation or search-scope data. | |
| skiResortId | No | Optional ski resort id from list_ski_resorts. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds value by stating the list intentionally excludes prices, availability, and bookability, which is a behavioral trait not covered by 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: first states purpose and filters, second states omissions and alternatives. Extremely concise and front-loaded 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?
Given no output schema and 5 optional parameters, the description fully explains the tool's scope (public accommodations), limitations (no prices), and ties to sibling tools (destination tools for IDs, search_apartments for comparisons, get_accommodation_detail for context). Agent has sufficient information to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the description does not add meaning beyond the schema. It reiterates optional filters but does not provide additional syntax or semantics.
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 lists public accommodations for catalogue discovery with optional filters, distinguishing it from sibling tools by explicitly noting it lacks prices/availability/bookability and directing to search_apartments for those.
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?
Explicit when-to-use (catalogue discovery), when-not-to-use (prices/availability/bookability), and alternatives (search_apartments for comparisons, get_accommodation_detail for context). Also references destination tools for filter IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ski_areasList ski areasARead-onlyIdempotentInspect
List public ski areas in France for destination discovery and comparison. A ski area groups one or more ski resorts and can be used as a destination scope for apartment search. Parent regions only bundle ski areas and do not have a separate detail endpoint.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds that the list is public and limited to France. For a parameterless tool, this is adequate transparency, though it could mention if results are static or paginated.
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 front-load the core purpose and explain key relationships without waste. Every sentence serves a clear 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 simple list tool with no parameters or output schema, the description provides sufficient context about the domain and usage. It could briefly mention the expected output format, but overall it is complete enough to guide an 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?
With zero parameters and 100% schema coverage, no parameter explanation is needed. Baseline 4 is appropriate as the description adds no param information, which is acceptable given the absence of 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?
The description clearly states the tool lists public ski areas in France for destination discovery and comparison. It distinguishes from siblings by explaining that ski areas are groups of resorts and that parent regions lack a detail endpoint, making the tool's 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?
The description provides context on when to use the tool (for destination discovery and as a scope for apartment search) and clarifies that parent regions do not have a separate detail endpoint. However, it does not explicitly state when not to use it or name alternative tools, though the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_ski_resortsList ski resortsARead-onlyIdempotentInspect
List public ski resorts in France for destination discovery, optionally filtered by ski area id. A ski resort is the local destination or village/resort used for accommodation search scopes and resort detail pages.
| Name | Required | Description | Default |
|---|---|---|---|
| skiAreaId | No | Optional ski area id from list_ski_areas. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, idempotentHint, destructiveHint. The description adds context about scope (public, France) and defines what a ski resort is, exceeding annotation coverage.
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 efficient sentences: first states action and scope, second defines the resource. No wasted words, front-loaded with key 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 simple input schema, annotations cover safety, and no output schema, the description adequately explains purpose and parameter. Could optionally describe return structure, but not essential for 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 has 100% coverage with skiAreaId description. The description adds the valuable context that the id originates from list_ski_areas, enhancing parameter 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?
Description clearly states the verb 'List', the resource 'public ski resorts in France', and the optional filter by ski area id, distinguishing it from sibling tools like list_ski_areas and get_ski_resort_detail.
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?
Description provides usage context ('for destination discovery') and indicates that skiAreaId comes from list_ski_areas, but does not explicitly state when not to use or name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_search_keywordsResolve search keywordsARead-onlyIdempotentInspect
Resolve a user phrase into concrete search-scope candidates such as parent regions, ski areas, ski resorts, districts or accommodations. Use the returned entityType and entityId in search_apartments when you want to restrict a later apartment search to a precise destination or accommodation. Broad searches can skip this and use keywords directly. Parent-region scopes are only for restricting searches, not for destination detail lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search phrase to resolve into possible destination or accommodation scopes, for example "Val Thorens", "3 Vallees" or an accommodation name. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only and idempotent; description adds that the output includes entityType and entityId, and explains that parent-region scopes are only for restricting searches, providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and every sentence adds value without 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 one parameter, complete annotations, and no output schema, the description adequately explains the tool's role, usage guidelines, and output (entityType/entityId) for effective use.
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 covers the single parameter completely with examples. The description reinforces the types of scopes but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool resolves a user phrase into concrete search-scope candidates (parent regions, ski areas, etc.) and distinguishes itself from siblings like search_apartments by specifying how the output is used to restrict searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (restrict to precise destination) and when to skip (broad searches use keywords directly). Also clarifies parent-region scopes are not for detail lookup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_apartmentsSearch ski apartmentsARead-onlyIdempotentInspect
Main apartment-level search for winter ski accommodation in French ski areas and ski resorts. Results are apartments, not whole accommodations. Put destination, ski area, ski resort or accommodation names into keywords. Put amenities such as sauna, pool, pets, fireplace, steam bath or whirlpool into filters. Put the traveller count into partySize, not keywords. Use weekId for a fixed weekly arrival date when you need concrete price, availability, bookabilityStatus and special-discount data.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Result page, starting at 1. | |
| weekId | No | Fixed weekly winter arrival date id from get_search_options. Required for week-specific price, availability, bookabilityStatus and special-discount comparison. | |
| filters | No | Comma-separated feature filter values from get_search_options, for example "sauna,pool". Use this for amenities such as sauna, pool, pets, fireplace, steam bath or whirlpool instead of adding those words to keywords. | |
| entityId | No | Optional precise search-scope entity id from resolve_search_keywords. Use together with entityType. | |
| keywords | No | Natural-language destination or accommodation keywords, for example a ski resort, ski area, accommodation name or free text. Do not put amenities such as sauna, pool or pets here when matching filter values exist; use filters for those. | |
| partySize | No | Traveller count. Results are restricted to apartments whose capacity is at least this party size within the matching website occupancy bucket. | |
| entityType | No | Optional precise search-scope entity type from resolve_search_keywords. Use together with entityId to restrict results to a resolved parent region, ski area, ski resort, district or accommodation. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by stating the scope (French ski areas) and that weekId is required for price/availability data. No contradictions, but could mention pagination or rate limits.
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 three sentences, front-loaded with purpose, followed by usage guidance. Every sentence adds value with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters and no output schema, the description covers core functionality well, including parameter usage and constraints. However, it could briefly mention the response structure (e.g., basic info plus optional price/availability) to enhance 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 description coverage is 100%, so baseline is 3. The description adds value by explaining how parameters work together (e.g., 'Put amenities... into filters' and 'Do not put amenities... when matching filter values exist'). This enhances understanding beyond individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Main apartment-level search for winter ski accommodation in French ski areas and ski resorts,' specifying the verb 'search', the resource 'apartments', and the context. It also distinguishes from siblings by noting 'Results are apartments, not whole accommodations.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on parameter usage: keywords for destinations, filters for amenities, partySize for traveler count, and weekId for concrete data. It implies when not to use certain parameters (e.g., avoid putting amenities in keywords). However, it does not explicitly name sibling alternatives for specific use cases.
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.
Discussions
No comments yet. Be the first to start the discussion!