Skip to main content
Glama
dumyCq

Jinko Hotel Booking MCP Server

by dumyCq

get-facilities

Retrieve facility IDs for hotel amenities like pet-friendly, WiFi, and pools. Use these IDs with the search-hotels tool to filter hotels based on user requirements. Essential for accurate hotel searches.

Instructions

IMPORTANT: ALWAYS USE THIS TOOL FIRST when a user mentions ANY specific hotel amenities or requirements.

This tool must be called BEFORE search-hotels whenever the user mentions requirements like:

  • Pet-friendly or traveling with pets/dogs/cats

  • WiFi or internet access

  • Swimming pools

  • Parking (free or paid)

  • Air conditioning or heating

  • Fitness center or gym

  • Restaurant or room service

  • Family rooms

  • Non-smoking rooms

  • Any other specific hotel features

The tool returns facility IDs that MUST be used with the search-hotels tool's facilities parameter to properly filter hotels. Without using this tool first, searches will not correctly filter for user-requested amenities.

Example workflow:

  1. User asks for "pet-friendly hotels in Paris"

  2. Call get-facilities to find the facility_id for "Pets allowed"

  3. Use that facility_id in the search-hotels facilities parameter

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
languageNoLanguage code for facility names (en, es, it, he, ar, de)en

Implementation Reference

  • The async handler function for the 'get-facilities' tool. Fetches facilities data for the specified language using getFacilitiesByLanguage, parses the JSON response, and returns a formatted success or error message with the facilities list.
      async (params) => {
        const lang = params.language || "en";
        // Create a mock URL for the getFacilitiesByLanguage function
        const uri = new URL(`hotel://facilities/${lang}`);
        const result = await getFacilitiesByLanguage(uri, lang);
        
        // Extract the facilities from the result
        let facilities = [];
        try {
          facilities = JSON.parse(result.contents[0].text);
        } catch (e) {
          return {
            content: [{
              type: "text",
              text: JSON.stringify({
                status: "error",
                message: "Failed to parse facilities data"
              })
            }]
          };
        }
        
        return {
          content: [{
            type: "text",
            text: JSON.stringify({
              status: "success",
              facilities: facilities,
              message: `Retrieved ${facilities.length} hotel facilities in ${lang} language. 
    IMPORTANT: You MUST identify the facility_id values that match the user's requirements and include them in the facilities parameter of the search-hotels tool. 
    For example, if the user wants pet-friendly hotels, find the facility_id for "Pets allowed" in this list and include it in your search-hotels call.`
            })
          }]
        };
      }
  • The Zod input schema for the 'get-facilities' tool defining the optional 'language' parameter.
    {
      language: z.string().default("en").describe("Language code for facility names (en, es, it, he, ar, de)"),
    },
  • The server.tool call registering the 'get-facilities' tool, including its name, detailed description instructing usage before searches, input schema, and inline handler implementation.
    server.tool(
      "get-facilities",
      `IMPORTANT: ALWAYS USE THIS TOOL FIRST when a user mentions ANY specific hotel amenities or requirements.
    
    This tool must be called BEFORE search-hotels whenever the user mentions requirements like:
    - Pet-friendly or traveling with pets/dogs/cats
    - WiFi or internet access
    - Swimming pools
    - Parking (free or paid)
    - Air conditioning or heating
    - Fitness center or gym
    - Restaurant or room service
    - Family rooms
    - Non-smoking rooms
    - Any other specific hotel features
    
    The tool returns facility IDs that MUST be used with the search-hotels tool's facilities parameter
    to properly filter hotels. Without using this tool first, searches will not correctly filter for 
    user-requested amenities.
    
    Example workflow:
    1. User asks for "pet-friendly hotels in Paris"
    2. Call get-facilities to find the facility_id for "Pets allowed"
    3. Use that facility_id in the search-hotels facilities parameter
    `,
      {
        language: z.string().default("en").describe("Language code for facility names (en, es, it, he, ar, de)"),
      },
      async (params) => {
        const lang = params.language || "en";
        // Create a mock URL for the getFacilitiesByLanguage function
        const uri = new URL(`hotel://facilities/${lang}`);
        const result = await getFacilitiesByLanguage(uri, lang);
        
        // Extract the facilities from the result
        let facilities = [];
        try {
          facilities = JSON.parse(result.contents[0].text);
        } catch (e) {
          return {
            content: [{
              type: "text",
              text: JSON.stringify({
                status: "error",
                message: "Failed to parse facilities data"
              })
            }]
          };
        }
        
        return {
          content: [{
            type: "text",
            text: JSON.stringify({
              status: "success",
              facilities: facilities,
              message: `Retrieved ${facilities.length} hotel facilities in ${lang} language. 
    IMPORTANT: You MUST identify the facility_id values that match the user's requirements and include them in the facilities parameter of the search-hotels tool. 
    For example, if the user wants pet-friendly hotels, find the facility_id for "Pets allowed" in this list and include it in your search-hotels call.`
            })
          }]
        };
      }
    );
  • Helper function loadFacilitiesData that loads the hotel facilities data from facilities.json file, used indirectly by the getFacilitiesByLanguage function called in the tool handler.
    export function loadFacilitiesData(): any[] {
      try {
        if (fs.existsSync(FACILITIES_PATH)) {
          const data = fs.readFileSync(FACILITIES_PATH, "utf-8");
          return JSON.parse(data);
        } else {
          console.warn("facilities.json not found at:", FACILITIES_PATH);
        }
      } catch (error) {
        console.error("Error loading facilities data:", error);
      }
      return []; // Return empty array on error or if file not found
    }
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the tool's role in the workflow (returns IDs for filtering), the necessity of using it before search-hotels, and the impact on search results. However, it lacks details on rate limits, error handling, or response format, which would be helpful for a tool with no output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded with the most critical information ('IMPORTANT: ALWAYS USE THIS TOOL FIRST'). It uses bullet points and an example workflow efficiently, though it could be slightly more concise by integrating some bullet points into prose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (simple parameter, no output schema, no annotations), the description is largely complete. It explains the purpose, usage, and workflow integration thoroughly. However, without an output schema, it could benefit from more details on the return format (e.g., structure of facility IDs).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 100%, so the schema already documents the single parameter (language). The description does not add any parameter-specific information beyond what's in the schema, such as how language affects facility names or default behavior. Baseline 3 is appropriate when the schema handles parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly states the tool's purpose: to return facility IDs that must be used with the search-hotels tool's facilities parameter. It specifies the verb ('returns facility IDs') and resource ('facilities'), and clearly distinguishes it from sibling tools like search-hotels by explaining its role in the workflow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool vs. alternatives: 'ALWAYS USE THIS TOOL FIRST when a user mentions ANY specific hotel amenities or requirements' and 'must be called BEFORE search-hotels'. It lists specific examples of requirements that trigger its use and explains the consequence of not using it ('searches will not correctly filter').

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dumyCq/jinko-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server