Tineo

Update itinerary item

segment_update

DestructiveIdempotent

Update an existing segment. Only provide the fields you want to change. Get field names from segment_get_schema if unsure. Segment dates must fall within the parent trip dates; use trip_update first to extend the trip. To change a checklist's tasks use checklist_items_add, checklist_item_update, checklist_items_remove or checklist_items_reorder (IDs from trip_checklists). The result lists the saved value of every field you sent, read back from Tineo, so do not call segment_details to confirm the change. On an Activity, Lodging, EventTicket or Parking, fields.placeId (a place_id from places_search) attaches that place the same way segment_associate_place does, replacing the stored address with the place's. 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

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "segment_update"
  }
}

Input Schema

Name	Required	Description
`id`	No	Alias for segment_id (widget compatibility)
`fields`	No	Field values to update. Only include fields that should be changed. Send null to clear an optional field; an empty string is ignored and the stored value is kept.
`segment_id`	No	The ID of the segment to update

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 14, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds substantial behavior beyond them: the response echoes the saved value of every field sent (so no confirmation read is needed), placeId replaces the stored address on place-bearing segment types, dates must fall within the parent trip's range, and unspecified times are stored as "time not set".

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?

Purpose and the field/schema guidance are front-loaded, but the cruise section is bloated: three separate sentences restate that cruise days must not be modeled as generic segments ("Never substitute Activity, CruiseActivity...", "Cruise/CruiseDay generic writes require the dedicated cruise tools", "If cruise tools are unavailable explain the limitation"). The core update guidance is buried under that tail.

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 destructive mutation with a free-form nested `fields` object, no output schema and no required parameters, the description supplies the missing pieces: how to discover field names, how null/empty values behave, how the response can be trusted, and what constraints the server enforces on dates.

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?

Schema coverage is 100%, so the baseline would be 3, but the description adds real meaning the schema lacks: it enumerates specific field names inside the free-form `fields` object (placeId, startDateTime) and gives the accepted date-only format YYYY-MM-DD with its storage consequence. It also points to segment_get_schema for discovering valid field names.

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 opening two sentences give a specific verb and resource ("Update an existing segment") plus a scope rule ("Only provide the fields you want to change"). The rest of the text distinguishes it from many siblings by name (segment_associate_place, checklist_* tools, trip_update, cruise_*), so an agent can route without opening another schema.

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?

Explicit when-to-use-elsewhere rules are given for four distinct alternatives: trip_update to extend parent trip dates, checklist_* tools for checklist tasks, places_search/segment_associate_place semantics for place attachment, and cruise_* tools for cruise reservations and sea/port days. It also states an explicit fallback (ask for clarification) when cruise tools are unavailable.

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

All Tineo tools Inspect

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

Need Help?