Loading ToolBench
MCP server for travel information using GeoNames and OpenStreetMap data
This server has significant definition quality gaps. Tools 1-3 (search_cities, search_hotels, search_hotels_ui) have detailed, well-structured schemas with proper descriptions and parameter documentation. However, tools 4-17 show severely incomplete definitions: no visible input schemas, minimal or missing descriptions, and no documented parameters. The server defines 17 tools, but only 3 have production-grade definitions. Tools 4-17 have empty or placeholder input objects with no properties, making them unsuitable for agent use. The search_hotels description includes a workflow tip (good pattern), but the majority of tools lack the rigor needed for reliable LLM interaction. The common pattern: tools managing user state (user preferences, favorites) and maintenance tasks (enrichment, data refresh) are all poorly documented, suggesting these were lower priority. Average across all 17 tools: well-defined tools pull the score up, but 14 underdefined tools drag it down significantly.
Add a POI to user favorites
Get server statistics (admin only)
Get user preferences and settings
List active enrichment tasks (admin only)
List all user favorite POIs
Load GeoNames data for a specific country (admin/maintenance task only)
Refresh GeoNames data (admin/maintenance task only)
14 of 17 tools have empty or missing input schemas. Tools 4-17 show 'inputSchema: {"type":"object","properties":{}}', no documented parameters whatsoever. This violates the pattern:tool-description and pattern:constrained-input rules. Agents cannot reason about what parameters to pass.
14 tools have descriptions under 20 characters or placeholder text only (e.g., 'Get user preferences and settings' is 37 chars but provides no context on WHEN to use it, WHAT it returns, or what 'preferences' means). LLMs cannot reliably select these tools for agent use.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Remove a POI from user favorites
Search for cities. REQUIRES either country_code OR coordinates (latitude + longitude). Valid combinations: (1) query + country_code, (2) query + country_code + state, (3) query + lat/long, (4) country_code only, (5) country_code + state, (6) lat/long only. Returns city info with coordinates, population, timezone, country and state/province. Example: search for "New York" with country_code "US" to find New York City.
Search for accommodations (hotels, hostels, guesthouses, motels, resorts, apartments, B&Bs). Returns JSON results with coordinates, ratings, stay quality scores, and details. REQUIRES either location (city_name or coordinates) OR query. Supports amenity filtering (e.g., wifi, pool, parking) and open_now. WORKFLOW TIP: To find hotels near a landmark, first use search_pois to get the landmark coordinates, then use search_hotels with those lat/long coordinates.
Search for accommodations with interactive UI card. Same as search_hotels but renders results in a clickable card interface. Includes stay quality scores and supports amenity and open_now filters.
Set user preferences and settings
Start an AI place summary generation task (admin/maintenance task only)
Start a POI enrichment task (admin/maintenance task only)
Start a homepage harvest task (admin/maintenance task only)
Stop a running enrichment task (admin only)
Get the authenticated user ID (from JWT or database token)
Tools managing user state (whoami, get_user_preferences, set_user_preferences, add_favorite, remove_favorite, list_favorites) lack parameter documentation. set_user_preferences and add_favorite do not document what fields they accept or what the request/response structure is. An agent cannot know what keys to pass in the preferences object or how to construct a favorite request.
Maintenance and admin tools (refresh_geonames, load_geonames_country, start_enrichment_task, start_ai_place_summary_task, start_homepage_harvest_task) have descriptions indicating they accept parameters (e.g., 'Refresh GeoNames data', 'Load GeoNames data for a specific country') but the input schemas show zero properties. An agent cannot know what 'country' parameter to pass to load_geonames_country, or what task type/name parameters to provide to start_enrichment_task.
No error recovery guidance in any descriptions. The rubric pattern:recovery-guide requires error responses to tell the LLM what to do next. Descriptions for user preference and maintenance tools do not hint at failure modes (e.g., 'If country not found, try list_countries first') or what constitutes valid input.
search_hotels and search_hotels_ui both exist with nearly identical schemas and descriptions. This violates pattern:tool (each tool should do exactly one thing) and pattern:tool-chain (avoid multiple tools doing the same thing differently). The only difference is UI rendering, which should be a parameter flag on a single tool, not two separate tools. LLMs must reason about which to call, wasting token budget.
search_hotels description includes example amenity values ('["wifi", "pool"]') and accommodation types ('guest_house', 'hostel', 'bed_and_breakfast'). LLMs tend to reuse example values literally.' The enum constraints in the schema should be the source of truth, not description examples.
search_cities, search_hotels, and search_hotels_ui document parameter relationships (e.g., 'latitude + longitude required together', 'country_code + state optional') but do not explicitly state mutual exclusivity or conditional requirements in the schema. A oneOf or conditional constraint would be clearer than prose.
No output schemas documented for any tool. The rubric requires: 'Document the output schema. LLMs need to know what fields to expect so they can plan downstream tool calls.' Descriptions state what is 'returned' (e.g., 'Returns city info with coordinates, population, timezone...') but JSON Schema output types are not visible. An agent cannot programmatically know if coordinates are { lat, lon } or { latitude, longitude }.
No pagination parameters documented for list_favorites or list_enrichment_tasks. The rubric pattern:paginated-result requires: 'Tools returning lists should accept page/offset and limit parameters and return a total count or next_cursor.' These tools may return large lists with no way to limit results or iterate.