Skip to main content
Glama
Sign In
wanderlog-mcp

wanderlog-mcp

by foxnaim
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Add a checklist to a Wanderlog trip

wanderlog_add_checklist

Adds a checklist with unchecked items to a Wanderlog trip, placing it on a specific day, a custom section like 'Packing list' or 'Trip Preparations', or the default 'Places to visit' list.

Instructions

Adds a checklist to a Wanderlog trip. Each item starts unchecked and can be ticked off in the Wanderlog app.

Add at least one checklist per trip. Common patterns:

  • In a custom section: a packing list or "before departure" checklist

  • On day 1: an arrival-day checklist ("pick up Oyster card", "check into hotel", "buy SIM")

  • On specific days: day-of tasks ("bring swimsuit", "charge camera", "carry cash for market")

Supply "day" for a dated itinerary day or "section" for an undated section such as "Notes" or "Trip Preparations". When both are provided, "section" takes precedence. Omit both to add to the default "Places to visit" list.

Returns a confirmation including the checklist title and item count.

Input Schema

NameRequiredDescriptionDefault
dayNoOptional day to add the checklist to. Accepts 'day 2', 'May 4', or ISO '2026-05-04'. If 'section' is also provided, the section takes precedence. Omit both to add to the 'Places to visit' list.
itemsYesChecklist items. Each string becomes one checkbox item, initially unchecked.
titleNoOptional title for the checklist (e.g. 'Packing list'). Omit for an untitled checklist.
sectionNoOptional undated section to add the checklist to, identified by its heading (e.g. 'Notes', 'Trip Preparations', or 'Places to visit'). Matching is case-insensitive and takes precedence over 'day'. Omit both to add to the 'Places to visit' list.
trip_keyYesThe trip to add the checklist to. Use wanderlog_list_trips if you don't know the key.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.2

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does a decent job: it discloses the initial state of items (unchecked), the precedence rule between 'section' and 'day', the default fallback container, and the shape of the confirmation. It does not cover failure behavior such as an unmatched section heading or an invalid trip key, which keeps it below a 5.

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-sentence purpose, then usage patterns, then parameter precedence, then return value — a sensible order. The three-bullet pattern list is longer than strictly necessary and repeats the notion of per-day checklists, but each bullet does illustrate a distinct placement decision.

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 5-parameter non-destructive creation tool with no annotations and no output schema, the description covers purpose, placement semantics, iteration default, and return value. Only error handling and duplicate/matching behavior for 'section' remain unexplained, a modest gap.

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 schema already documents every parameter including accepted day formats and case-insensitive section matching. The description mostly restates those rules; its only added value is illustrating typical section/day choices through the pattern examples. Baseline 3 is appropriate.

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 first sentence names a specific verb and resource ('Adds a checklist to a Wanderlog trip') and the following sentence pins down the unit of work ('each item starts unchecked'), which distinguishes it from sibling note/place/section adders without ambiguity.

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?

It gives an explicit usage norm ('Add at least one checklist per trip') plus concrete scenario patterns (packing list, arrival-day, day-of tasks) and a routing rule for the three-way choice of day, section, or default list. An agent knows exactly when to reach for this tool and which parameter form to pick.

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

Deploy Server

Other Tools