Skip to main content
Glama

Remove a journal stop from a Wanderlog trip

wanderlog_remove_journal

Remove a stop from a Wanderlog trip journal by matching a case-insensitive title substring; use a date filter to resolve duplicate titles.

Instructions

Removes a stop from a Wanderlog trip's journal by matching a substring of its title.

The match is case-insensitive. If exactly one stop matches, it is deleted. If none match, an error is returned. If several match, a numbered list is returned and nothing is deleted — re-call with a more specific title or add a date filter to pick one.

Input Schema

NameRequiredDescriptionDefault
dateNoOptional exact date filter to disambiguate duplicate titles, YYYY-MM-DD.
titleYesCase-insensitive substring matching the title of the journal stop to remove.
trip_keyYesThe trip to remove the journal stop from.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.4/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 does so unusually well: it discloses case-insensitive substring matching, the conditional-delete rule, the no-op guarantee on ambiguity, and the error path. It omits whether a deletion is reversible and what permissions are required, which are the remaining gaps for a destructive mutation.

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?

Front-loaded with the core action, then one short paragraph covering each outcome path. No redundant restatement of the title or schema fields; every sentence adds a branch condition the agent must handle.

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?

There is no output schema, and the description covers the ambiguous and error return shapes but not the success response. For a three-parameter removal tool that is nearly complete; only the successful-deletion return value and irreversibility are unstated.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond the schema by explaining that 'title' is a substring matcher whose ambiguity is resolved interactively and that 'date' exists to disambiguate duplicate titles. This tells the agent how the parameters behave together, not just their types.

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 and resource ('Removes a stop from a Wanderlog trip's journal') plus the matching mechanism. It is clearly distinguishable from the sibling tools wanderlog_add_journal and wanderlog_edit_journal without opening any schema.

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?

Explains the operational conditions well: exactly one match deletes, no match errors, multiple matches returns a list and deletes nothing, with explicit remediation ('re-call with a more specific title or add a date filter'). It doesn't name sibling alternatives such as edit_journal for modifying rather than removing, but the when-to-use context is clear.

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