Loading ToolBench
Unofficial MCP server that gives AI agents read-only access to your Kilter Board logbook.
Strong tool naming (all verb_noun pattern), comprehensive descriptions (avg 180 chars, well within 10-1024 range), and complete JSON schemas with type definitions and parameter descriptions. All 9 tools are read-only with proper ToolAnnotations. Key gaps: no output schema documentation in code (inferred from context), no error handling guidance in descriptions, and no pagination/limit enforcement details. Tool composition is clean (each does one thing), but descriptions could better explain when to use each tool vs. similar ones (e.g., kilter_get_logs vs kilter_get_sends distinction).
Return climbing statistics per wall angle. Use when the user asks about their performance on different angles, which angles they climb most, or angle-specific stats. Includes sends, flashes, attempts, and hardest send per angle.
Return sends per grade (unique climbs and entries), hardest first, with flash counts. Use when the user asks about their grade distribution, how many climbs at each grade, or flash rates by difficulty. Filters: angle (degrees).
Return the user's hardest sent climbs, ordered by difficulty (hardest first), then most recent. Use when the user asks about their hardest climbs, personal records, or maximum grade. Filters: limit (default 10, max 500), angle (degrees).
Return the user's Kilter logbook entries, newest first. Use when the user asks about recent Kilter climbs, attempts, what they climbed on a date, or wants raw history. Each entry is one climb at one wall angle on one date with the number of tries in that entry. Filters: limit (default 25, max 500), angle (degrees), topped (true=only sends, false=only unsuccessful attempts), start_date/end_date (YYYY-MM-DD, inclusive).
Output schemas not documented in tool descriptions. LLMs cannot plan downstream operations or extract fields without knowing response structure (e.g., what fields does kilter_get_summary return? Is it a dict or list?).
No error handling guidance in tool descriptions. If Kilter API fails or user is unauthenticated, descriptions don't tell LLM what to do next (retry, ask user for credentials, etc.).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Return sends per calendar month or ISO week, oldest first. Use when the user asks about their progress over time, climbing trends, or monthly/weekly stats. Filters: period (month or week).
Return climbs the user is working on (attempted but never topped at that angle). Use when the user asks about their projects, work-in-progress climbs or what they're trying. Filters: limit (default 10, max 500), angle (degrees).
Return climbs the user has topped (sent), newest first. Use when the user asks about their sends, ticks, completed climbs or flashes. Entries with status 'flash' were topped on the first try. Filters: limit (default 25, max 500), angle (degrees), start_date/end_date (YYYY-MM-DD).
Return the user's climbing sessions (one per calendar day), newest first. Use when the user asks about their climbing sessions, when they climbed, or wants a day-by-day breakdown. Each session is one calendar day in the user's timezone. Filters: limit (default 10, max 500).
Return aggregate statistics about the user's Kilter logbook. Use when the user asks about their overall climbing stats, total sends, hardest climb, progress, or wants a high-level overview. Includes sends, flashes, attempts, unique climbs, session count, hardest send/flash, and a breakdown by grade.
Limit parameter defaults and maxima are inconsistent across tools (limit defaults: 25, 10, 10; max: 500, 500, 500). No description explains why kilter_get_projects defaults to 10 while kilter_get_logs defaults to 25, or what happens if limit is omitted.
Tool descriptions use domain jargon ('topped', 'flash', 'font_grade') without defining it upfront. INSTRUCTIONS field explains these, but LLM may not read it before calling tools. Definitions should be in tool descriptions or a shared glossary.
No distinction in descriptions between when to use kilter_get_logs (raw history with filters) vs kilter_get_sends (only topped climbs). LLM may pick wrong tool if user says 'show me my climbs'.