The user's own spending target for a trip, if they set one. Personal, not shared: each member of a trip has their own, and no one else's is readable.
| Name | Required | Description | Default |
|---|---|---|---|
| journey_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety. The description adds behavioral nuances: 'if they set one' indicates conditional existence (possibly null/not found if unset), and 'no one else's is readable' discloses a privacy/permission boundary. These go beyond the annotations and inform the agent about expected behavior and authorization.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and wastes no words. It efficiently conveys the tool's purpose and key constraints without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, read-only annotations, and no output schema, the description covers the essential aspects: what it retrieves, that it's personal, conditional existence, and privacy. It doesn't specify the exact return format (e.g., whether it returns null when unset), but 'spending target' suggests a value, and the tool's simplicity makes it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining journey_id. The description mentions 'for a trip', which implicitly ties journey_id to the trip identifier, but it does not explicitly state the parameter's role or expected type. Given the simplicity, this indirect reference provides some meaning but not full compensation for the schema's lack of description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it retrieves the user's own spending target for a trip. It also distinguishes from shared budgets by emphasizing 'Personal, not shared' and 'no one else's is readable', which differentiates it from any shared or other-member budget tools. This is a specific verb+resource with clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool: to get your own budget for a trip. It explicitly states that others' budgets are not readable, which implies a limitation and guides against using it for non-personal budgets. It does not explicitly name alternatives like set_budget, but the context is sufficient for an agent to understand the scoping and avoid misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource and action (e.g., create_flight vs create_activity vs create_stay), and descriptions clarify overlaps like stay vs accommodation. The only potential confusion (create_activity covers travel legs) is explicitly explained, so misselection is unlikely.
All tools follow a consistent verb_noun pattern using standard verbs: create, delete, get, list, search, set, update, add, remove, leave. Nouns are consistently singular and descriptive (passport, journey, stay, flight, accommodation). No mixed conventions or vague verbs.
With 36 tools, the count is higher than typical, but the server covers a wide domain: journeys, stays, activities, flights, accommodations, visas, documents, preferences, and sharing. Each entity has CRUD operations plus search and status, so the count is justified, though bordering on heavy.
The tool surface is remarkably complete: full CRUD for every entity (journeys, stays, activities, flights, accommodations, visas), user profile access (get_me), search utilities, sharing controls (join links, member management), and preferences. No obvious dead ends or missing lifecycle steps; even edge cases like deleting bookings before stays are handled.