Skip to main content
Glama

delegacja

Save a calculated trip

trip_record

Calculate a trip and save it under a name, traveller taken from the shared business profile; returns the TRIP-YYYY-NNNN id. An identical record is refused and named, spending no slot. Free: 5 trips a calendar month.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endYesWhen it ended, same form as start. It must be after start as an instant
nameYesWhat to call it, e.g. "Berlin client workshop"
startYesWhen the trip began, ISO 8601 WITH a zone: "2026-03-28T22:00:00+01:00", or "2026-03-28T22:00" together with timezone
schemeYes"pl" Polish delegation regulation, "uk" HMRC benchmark scale rates, "us" GSA CONUS standard
projectNoProject or client this belongs to; carried onto the expense payload
purposeNoWhy the trip happened; kept on the record and carried onto the expense payload
timezoneNoIANA id such as "Europe/Warsaw". Required when start or end carries no offset; also the zone the US scheme counts calendar days in
travellerNoWho travelled. Defaults to the shared business profile's name
destinationYesCountry or locality, e.g. "Germany", "Poland", "United Kingdom", "United States"
fiscal_yearNoUS only, e.g. "FY2025". Defaults to the current bundled fiscal year
late_eveningNoUK only, per day: the journey was ongoing at 8pm and a meal was bought after it, which adds the 10.00 GBP supplement
lodging_nightsNoNights of accommodation. What this pays depends on the scheme and the answer says so
meals_providedNoPer day, in order: the free meals the traveller was given that day, e.g. [["breakfast"],["breakfast","lunch"]]. Each one reduces that day's allowance by the scheme's own percentage or amount
meals_provided_dailyNoThe same free meals on every day. Ignored for any day that meals_provided already names

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the sparse annotations, the description adds meaningful behavioral context: it returns a specific id format, refuses and names identical records without consuming a slot, and states the free quota of 5 trips per month. This gives the agent clear expectations for side effects, duplicate handling, and 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.

Conciseness5/5

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

The description is compact and front-loaded: the first sentence states the core operation and return value, and the second adds duplicate and quota behavior. Both sentences carry necessary information with no filler or repeated schema content.

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 high parameter count, the schema fully documents parameters, and the description covers the main non-schema facts: returned id format, duplicate refusal, and free usage limit. It is largely complete for invoking the tool, though it could more explicitly clarify the boundary with perdiem_calc or explain what happens when the monthly quota is exceeded.

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 baseline is 3. The description does not explain individual parameters, but it does clarify that the traveller comes from the shared business profile by default, which lightly reinforces the schema's own default. No extra parameter semantics beyond the schema are provided.

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 action ('Calculate a trip and save it under a name'), the resource (a trip record), and discloses the returned id format ('TRIP-YYYY-NNNN id'). This distinguishes it from sibling tools like trip_list, trip_export, and trip_delete, since it is the creating/persisting operation.

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

Usage Guidelines3/5

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

The description implies when to use the tool: when you want to calculate and save a trip, and it notes the 5-trip monthly free limit and duplicate refusal. However, it does not explicitly compare with alternatives such as perdiem_calc (which might only calculate without saving) or explain when not to use this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.