Loading ToolBench
MCP server for The Mountaineers website (mountaineers.org)
mountaineers-mcp demonstrates solid definition quality with well-structured tool registration, comprehensive parameter schemas, and clear descriptions. All 28 tools are explicitly registered with proper descriptions and input schemas. Most tools follow verb_noun naming conventions and include meaningful, actionable descriptions (median ~150 chars). Parameters consistently include type definitions and descriptions. However, several patterns are underutilized: tool annotations (destructiveHint, idempotentHint, readOnlyHint) are absent despite many tools being read-only; output schemas are not formally documented in the visible code; error handling describes recovery paths but lacks structured error categorization; and some parameter descriptions could be more constraint-focused (e.g., enumerating allowed activity types vs free-form strings). The 'login' tool stands out with exceptional documentation including prerequisites and behavioral notes.
Get detailed information about a specific activity by URL or slug.
Get authenticated user's personal activity history (past and upcoming activities).
Get the roster of members signed up for a specific activity.
Get detailed information about a specific badge by URL or slug.
Get detailed information about a specific course, including schedule, pricing, leaders, and badges earned.
Get detailed information about a specific mountaineers.org event by URL or slug.
Tool annotations (destructiveHint, idempotentHint, readOnlyHint) absent from all tools despite clear semantic distinctions (28 tools are read-only, 1 is write-only). LLMs use these hints to understand tool safety and avoid unintended side effects.
Output schemas not formally documented in code. While search_* tools clearly paginate (20 results, page numbers), and get_* tools return entity details, there is no machine-readable schema definition visible for what each tool returns. LLMs must infer return structure from descriptions alone.
Parameter constraints are documented in descriptions (e.g., 'Difficulty filter: Casual, Easy, Moderate, Moderate+, Challenging') but not formalized as JSON Schema enums. Descriptions vulnerable to drifting out of sync; machine parsing impossible. LLMs may hallucinate invalid values like 'Very Hard'.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | C | 62 | - | v1 |
Get a member's past and upcoming activities.
Get a member's past and upcoming courses.
Get a member's activity history with filtering options.
Get public profile information about a specific member.
Get authenticated user's upcoming and past activities with filtering options.
Get authenticated user's earned badges.
Get authenticated user's past and upcoming courses.
Get detailed information about a specific route or place on mountaineers.org, including difficulty, elevation, directions, and maps.
List trip reports filed against a specific route/place URL. Paginated, 20 per page; results follow the site's default order (typically newest first). Use this when you have a route URL and want member-written reports for that route specifically — more accurate than searching trip reports by route name.
Get detailed information about a specific trip report by URL or slug.
Get the MCP server version.
List all Mountaineers branches.
List all Mountaineers committees.
Sign in to mountaineers.org. Opens a Chrome window where YOU complete the login (your password is never sent to this server or the AI); it then caches your session. Required once before any other tool works — mountaineers.org blocks unauthenticated clients. Re-run when a tool reports your session has expired. Requires a desktop with Google Chrome (stable channel) installed; the call blocks for up to ~3 minutes while you sign in. If you're already signed in from a previous run, it may finish in seconds.
Search currently-published outdoor activities on mountaineers.org (upcoming trips, course field trips, clinics). Supports filtering by type, branch, difficulty, date range, and more. Past activity instances are NOT in the search index — if you have a known historical activity URL use get_activity, or use get_member_history for a member's past activities.
Search the mountaineers.org badge catalog. Returns title, URL, and badge_type derived from the URL (one of: award, instructor, leader, other). Optional free-text query.
Search currently-published courses, clinics, and seminars on mountaineers.org (upcoming and rolling-enrollment only). Past course instances (prior years) are NOT in the search index, even though their URLs still resolve — if you have a known historical course URL use get_course, or use get_my_courses for the authenticated user's past courses.
Search mountaineers.org events (festivals, clinics, social gatherings, branch meetings — distinct from activities and courses). Returns title, URL, date string, and location. Optionally filter by free-text query.
Search for members on mountaineers.org by name, email, or location.
Search routes and places on mountaineers.org. Filter by activity type, difficulty, climbing category, and more.
Search trip reports on mountaineers.org. Trip reports are member-written accounts of past outings; the full historical archive (8000+ reports) is searchable here. To narrow to a specific route, pass the route name as the query.
Get authenticated user's profile information.
No error handling guidance in tool descriptions. When a tool fails (e.g., session expired, invalid URL slug), the implementation returns isError: true with a text message, but descriptions do not explain recovery paths (e.g., 'If session expires, call login() again'). Agents must guess next steps.
Member/user lookup tools (search_members, get_member_profile) accept only 'url' or 'slug' parameters. No support for more natural identifiers like member name or email. Agents must first call search_members, extract a slug, then call get_member_profile, two round-trips for a single lookup.
Date-range parameters (date_from, date_to) lack constraint documentation. Description says 'YYYY-MM-DD' format but no mention of valid ranges, minimum/maximum dates, or whether boundaries are inclusive/exclusive. LLMs may pass invalid dates without immediate feedback.
Pagination design consistent across search tools (page 0-based, 20 per page) but descriptions do not clarify what 'page' means when filtered results are fewer than 20 or when total count is unknown. No 'next_cursor' or 'has_more' field mentioned, agents may over-paginate or miss results.
No batch operations for tools agents call in loops. E.g., if an agent needs details for 5 routes, it must call get_route 5 times. A batch_get_routes(urls: []) or batch_get_activities(urls: []) variant would reduce latency and token cost.