Skip to main content
Glama

Remove a place from a Wanderlog trip

wanderlog_remove_place

Remove any place, flight, hotel, or block from a Wanderlog trip via a natural-language reference (name, role, day, or ordinal). If ambiguous, it returns a numbered list without making changes.

Instructions

Removes a place (or flight, train, hotel — any block) from a Wanderlog trip based on a natural-language reference.

Supported reference forms:

  • Exact or partial name: "Queenstown Gardens", "Gardens"

  • Role keywords: "the hotel", "the flight", "the train"

  • Day filter: "Queenstown Gardens on May 4" or "... on day 3"

  • Ordinal prefix (for duplicates): "1st Queenstown Gardens", "second X", "last X"

  • Combined: "2nd Queenstown Gardens on May 4"

If the reference is ambiguous (multiple places match), the tool returns a numbered list of candidates and does NOT make any change. Re-call with an ordinal prefix ("1st X", "2nd X") or a more specific filter to pick the one you want.

Input Schema

NameRequiredDescriptionDefault
trip_keyYesThe trip to remove from.
place_refYesNatural-language reference to the place you want to remove. Examples: 'Queenstown Gardens', 'the hotel', 'the sushi place on day 3'. Supports ordinal prefixes for duplicates: '1st Queenstown Gardens', 'second Queenstown Gardens', 'last Queenstown Gardens'. Supports day filters via ' on ': 'Queenstown Gardens on May 4'. Ordinals and day filters can be combined: '2nd Queenstown Gardens on May 4'.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it does disclose the highest-value non-obvious behavior: ambiguous references return a numbered candidate list and make no change. It omits reversibility, permission requirements, and confirmation behavior, which are gaps for a destructive operation.

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?

Front-loaded with the one-line purpose, followed by a scannable bulleted list of reference forms and a closing note on ambiguity. Slight redundancy with the schema's place_ref description mildly lowers it from 5.

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?

For a two-parameter destructive tool with no annotations and no output schema, it covers reference syntax and the ambiguity fallback well. Missing are the consequences of removal (e.g. whether other schedule blocks shift) and permissions, which would round it out.

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 coverage is 100% and the place_ref schema description already enumerates the same reference forms, so the description largely restates structured data. It does reinforce the semantics of natural-language resolution, but adds little operational detail beyond the schema.

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?

States a specific verb ('Removes') and a precisely scoped resource ('a place (or flight, train, hotel — any block) from a Wanderlog trip'), which also implicitly separates it from siblings like wanderlog_remove_expense, wanderlog_remove_note, and wanderlog_move_block.

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?

Gives concrete guidance on how to form references and, crucially, what to do when the reference is ambiguous (re-call with an ordinal or more specific filter). It does not explicitly contrast with sibling removal tools (e.g. remove_expense for expenses), so 4 rather than 5.

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