Skip to main content
Glama
lumile

LumbreTravel MCP Server

by lumile

create_program

Create new travel programs in the LumbreTravel system by specifying program name, start and end dates, and agency ID.

Instructions

Crea un nuevo programa de viajes. Antes de crear un nuevo programa se debe preguntar al si quiere que primero se busque el programa a ver si existe. Si no se especifica la fecha de inicio o fin del programa, no la asumas, pide al usuario que la especifique. Si no se especifica el ID de la agencia, pide al usuario que la especifique.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesNombre del programa
startDateYesFecha de inicio del programa (DD-MM-YYYY), salvo que el usuario lo indique las fechas siempre deben ser en el futuro
endDateYesFecha de fin del programa (DD-MM-YYYY), salvo que el usuario lo indique las fechas siempre deben ser en el futuro. Y la fecha de fin debe ser mayor que la fecha de inicio
agencyIdYesID de la agencia a asociar con este programa

Implementation Reference

  • Handler function for the 'create_program' tool. Extracts arguments, formats dates, calls apiService.createProgram, and returns formatted response.
    case 'create_program': {
      const {
        name,
        startDate,
        endDate,
        agencyId
      } = args
    
      const program = await this.apiService.createProgram({
        name,
        startDate: formatDate(startDate),
        endDate: formatDate(endDate),
        agency: { id: agencyId }
      })
    
      return {
        content: [{
          type: 'text',
          text: `Programa "${name}" creado exitosamente.\n\nDetalles del programa:\n${JSON.stringify(program, null, 2)}`
        }]
      }
    }
  • Input schema definition and description for the 'create_program' tool in the listTools response.
      name: 'create_program',
      description: 'Crea un nuevo programa de viajes.  Antes de crear un nuevo programa se debe preguntar al si quiere que primero se busque el programa a ver si existe. Si no se especifica la fecha de inicio o fin del programa, no la asumas, pide al usuario que la especifique. Si no se especifica el ID de la agencia, pide al usuario que la especifique.',
      inputSchema: {
        type: 'object',
        properties: {
          name: {
            type: 'string',
            description: 'Nombre del programa'
          },
          startDate: {
            type: 'string',
            description: 'Fecha de inicio del programa (DD-MM-YYYY), salvo que el usuario lo indique las fechas siempre deben ser en el futuro'
          },
          endDate: {
            type: 'string',
            description: 'Fecha de fin del programa (DD-MM-YYYY), salvo que el usuario lo indique las fechas siempre deben ser en el futuro.  Y la fecha de fin debe ser mayor que la fecha de inicio'
          },
          agencyId: {
            type: 'string',
            description: 'ID de la agencia a asociar con este programa'
          }
        },
        required: ['name', 'startDate', 'endDate', 'agencyId']
      }
    },
  • Helper method in ApiService that performs the HTTP POST request to the backend API endpoint for creating a program.
    async createProgram (data: {
      name: string
      startDate: string
      endDate: string
      agency: { id: string }
    }) {
      const headers = await this.getHeaders()
      const response = await fetch(`${API_CONFIG.baseUrl}/integrations/mcp/programs/create`, {
        method: 'POST',
        headers: { ...headers, 'Content-Type': 'application/json' },
        body: JSON.stringify(data)
      })
      return await this.handleResponse<any>(response)
    }
  • src/index.ts:42-47 (registration)
    Registers the callTool handler on the MCP server, which dispatches to the specific tool handler based on name, including 'create_program'.
    // Configure handlers for tools
    this.server.setRequestHandler(
      CallToolRequestSchema,
      async (request) => await this.toolsHandler.callTool(request.params.name, request.params.arguments, this.server)
    )
  • Utility function formatDate used in the handler to convert input dates to DD-MM-YYYY format before sending to API.
    export function formatDate (dateStr: unknown): string {
      // Type validation
      if (typeof dateStr !== 'string') {
        throw new McpError(
          ErrorCode.InvalidParams,
          'Date must be a string in YYYY-MM-DD format'
        )
      }
    
      // Try to parse the date with different formats
      const formats = [
        'YYYY-MM-DD',
        'MM/DD/YYYY',
        'DD MMMM YYYY',
        'YYYY-MM-DDTHH:mm:ss.SSSZ',
        'DD-MM-YYYY'
      ]
    
      const parsedDate = moment(dateStr, formats, true)
    
      // Check if the date is valid
      if (!parsedDate.isValid()) {
        throw new McpError(
          ErrorCode.InvalidParams,
          `Invalid date format: ${dateStr}`
        )
      }
    
      // Additional validation for impossible dates
      const month = parsedDate.month() + 1 // moment uses 0-11 for months
      const day = parsedDate.date()
    
      if (month > 12 || month < 1 || day > 31 || day < 1) {
        throw new McpError(
          ErrorCode.InvalidParams,
          `Invalid date format: ${dateStr}`
        )
      }
    
      // Return in the desired format
      return parsedDate.format('DD-MM-YYYY')
    }
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses behavioral traits: it's a mutation tool (implied by 'Crea'), requires user input for missing parameters (dates, agency ID), and suggests a pre-check for existing programs. However, it lacks details on permissions, error handling, or what happens on success, leaving gaps in transparency.

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

Conciseness3/5

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

The description is appropriately sized (three sentences) but not optimally front-loaded. The first sentence states the purpose, but the second and third sentences mix usage guidelines and behavioral instructions, making it slightly cluttered. Every sentence adds value, but the structure could be more streamlined for clarity.

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

Completeness3/5

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

Given the complexity (mutation tool with 4 required parameters), no annotations, and no output schema, the description is incomplete. It covers purpose and some behavioral aspects but misses details like response format, error cases, or side effects. For a creation tool with full parameter coverage but no output info, it's adequate but has clear gaps.

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?

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides (e.g., it doesn't explain parameter interactions or formats). Baseline is 3 when schema does the heavy lifting, and the description doesn't compensate with extra insights.

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

Purpose4/5

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

The description clearly states the verb ('Crea') and resource ('un nuevo programa de viajes'), making the purpose specific and understandable. It distinguishes from siblings like 'update_program' or 'delete_program' by focusing on creation. However, it doesn't explicitly differentiate from other creation tools (e.g., 'create_agency'), which prevents a perfect score.

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

Usage Guidelines4/5

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

The description provides clear context on when to use this tool: before creating, ask the user if they want to search for existing programs first. It also specifies prerequisites (dates and agency ID must be provided by the user). However, it doesn't explicitly mention alternatives like 'get_programs_by_name' for checking existence or when not to use this tool, which keeps it from a score of 5.

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

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/lumile/lumbretravel-mcp'

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