Skip to main content
Glama
Sign In

Tineo

by ai.tineo
OverviewDiscussionsAdmin

Create itinerary items

batch_segment_create

Create multiple segments in a trip in one call. To save into a trip that does not exist yet, send new_trip (title, start_date, end_date) instead of trip_id: the trip and its items are created in this one call. Put each item's values in fields, named as segment_get_schema returns them (Activity activityType is one of: tour, dining, show, spa, class, sports, sightseeing, other). Each item succeeds or fails on its own: valid items are created and failed items are returned by index with the reason, so resend only the failed items. Max 50 segments per call; split larger itineraries into several calls. Segment dates must fall within the parent trip dates. Dates up to 1 day outside the trip extend it, with a warning; further out, call trip_update first. For an Activity, Lodging, EventTicket or Parking at a real place, call places_search first and put the result's place ID in fields.placeId: Tineo links that place (map pin and coordinates) and fills a missing name, address, phone and website. Never invent a time: if the user has not given or chosen one, ask, or send the date only (YYYY-MM-DD) in startDateTime and Tineo stores it as time not set. Send a clock time only when the user stated it or a booking shows it. For commercial cruise reservations and sea/port days use cruise_* tools. Never substitute Activity, CruiseActivity or another segment type for a cruise day. Ordinary shore excursions remain valid Activity/CruiseActivity. If cruise tools are unavailable explain the limitation and ask for clarification. Cruise/CruiseDay generic writes require the dedicated cruise tools; their schemas and full reads remain available.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "segments": "<segments>"
    },
    "name": "batch_segment_create"
  }
}

Input Schema

NameRequiredDescriptionDefault
trip_idNoThe trip ID to add segments to. Send this or new_trip.
new_tripNoUse instead of trip_id to create the trip and its segments in one call. A trip of the user's with the same title and dates is reused.
segmentsYesArray of segments to create. Each must have segment_type and fields.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

The annotations declare a non-read-only, non-idempotent, non-destructive write, and the description adds substantial behavior beyond that: per-item partial success with failed items returned by index and the resend-only-failures recovery pattern, a hard 50-segment cap requiring call splitting, adjacent-date extension with a warning, and place-link side effects (map pin, coordinates, filled name/address/phone/website). The 'never invent a time' rule and date-only startDateTime fallback disclose data-integrity behavior an agent could not infer from schema or annotations.

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 content is front-loaded and ordered by decision priority: purpose, trip targeting, field shape, failure semantics, limits, dates, place linking, time handling, then the cruise boundary. The cruise section at the end is somewhat repetitive, restating the cruise-tool restriction across several sentences, which costs a little tightness in an otherwise dense and useful description.

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

Completeness5/5

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

For a nested-object, non-idempotent batch write with no output schema, the description covers everything an agent needs: how to target or create the parent trip, expected field shape and schema lookup, the partial-success return contract, the batch size limit, date-range constraints, and place/time preconditions. The cruise boundary is spelled out so the agent knows when to stop and use another tool instead.

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

Parameters5/5

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

Although schema description coverage is already 100%, the description adds semantics the schema cannot express: the trip_id versus new_trip mutual exclusivity, that new_trip creates the trip and items in the same call, and that item field names must match what segment_get_schema returns for that segment_type. It also gives concrete value meanings for fields, such as the Activity activityType enum values and writing fields.placeId from a places_search result.

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 first sentence names a specific verb and resource with scope: creating multiple segments in a trip in a single call. That clearly distinguishes it from the singular segment_create sibling, and the description immediately clarifies the alternate creation path via new_trip.

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?

It explicitly routes between alternatives: use new_trip when the trip does not exist yet, call trip_update first when dates fall more than a day outside the trip, call places_search before creating place-based segment types, and use cruise_* tools for cruise reservations and sea/port days. It also states the excluded case (never substitute Activity or CruiseActivity for a cruise day), which is exactly the when-not guidance most definitions omit.

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

All Tineo toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources