Loading ToolBench
Analytical travel-planner MCP. Vault-backed profile + trip plans, seven flight-strategy analyzers, trip-prep + emergency-card + post-trip review.
travel-mcp has 6 tools with clear verb-noun naming (healthcheck, get_travel_profile, update_travel_profile_section, list_companion_profiles, get_companion_profile, upsert_companion_profile). Descriptions are present and detailed (100-300 chars), explaining WHAT each tool does and WHEN to use it. However, input schemas are incomplete: most tools lack explicit parameter type definitions in the visible code. The upsert_companion_profile tool shows good schema structure with nullable types and descriptions, but healthcheck, get_travel_profile, and list_companion_profiles have empty input objects with no parameters documented. Output schemas are not documented in the visible code. Error handling is present (sanitize_error, classify_error) but recovery guidance is minimal. The tool descriptions are LLM-optimized and include prerequisites (e.g., 'Edit via Obsidian directly OR via update_travel_profile_section()'), which is strong. Composition is good: tools are single-responsibility and chainable (get_travel_profile → update_travel_profile_section). Security is solid: no credentials in parameters, audit logging on every call, input validation via validators.py.
Return one companion profile by name.
Return the master traveler profile (frontmatter + body) from 🧳 Travel/Profile.md. Profile is the source of truth for: name, DOB, passport ISSUING COUNTRY and EXPIRY, KTN, loyalty IDs, credit cards, cabin rules, schedule rules, hotel chains, hard booking rules. Edit via Obsidian directly OR via update_travel_profile_section().
Verify the MCP is configured + ready: vault path resolved, profile present, router available. Auto-creates the 🧳 Travel/ folder tree + seeds Profile.md on first call when TRAVEL_MCP_VAULT_PATH is set. Idempotent — re-running once everything exists is a no-op.
List all companion traveler profiles under 🧳 Travel/Companions/.
Replace one `## Section` body in Profile.md. section_heading is matched verbatim (e.g. '4. Airports & Flights'). If the section doesn't exist it is appended. Adjacent sections are preserved.
Four tools (healthcheck, get_travel_profile, list_companion_profiles, get_companion_profile) have empty or missing input schemas.
Output schemas are not documented in tool descriptions. LLMs cannot plan downstream calls or extract fields without knowing what each tool returns. healthcheck returns a dict with 8+ fields (ok, vault_path, profile_exists, etc.) but this is not declared in the docstring.
get_companion_profile accepts a 'name' parameter but no validation or error guidance is documented. If the companion does not exist, the error message should suggest available companions or recovery steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 56 | 2026-07-28+ | v2 |
Create or update a companion traveler profile. Use for partner, family member, frequent travel buddy. All fields optional — pass only what you want to set/change. `body` overwrites the markdown body (use sparingly; the frontmatter holds structured fields).
update_travel_profile_section description mentions 'section_heading is matched verbatim' but does not document what happens if the section does not exist (it is appended). This dependency should be explicit in the description.
No pagination or result-limiting parameters on list_companion_profiles. If the Companions/ folder grows large, the tool could return hundreds of files, bloating context. Should accept limit and offset/cursor parameters.