Loading ToolBench
MCP server exposing weather forecasts, weather alerts, internet search, nearest place finder, and Google navigation tools
This MCP server has significant quality gaps across multiple dimensions. While all 5 tools are explicitly registered with schemas and descriptions, the descriptions are often vague or generic, parameters lack proper type constraints and enum values, output schemas are not documented, and error handling is minimal. Tool naming follows verb conventions but some names are compound ('nearest_place_finder_agent', 'navigation_agent') suggesting multiple responsibilities. The server exposes API keys in tool implementations (hardcoded placeholder strings and Google API calls requiring keys passed at runtime), though not directly as parameters. Overall, this reads as an early-stage prototype rather than production-ready tooling.
Get weather alerts for a US state.
Get weather forecast for a location.
Searches for the queried destination from the current location and opens the gmap navigation tool
This functions does a Google API map search and returns a list of top 5 queried places alongwith ratings and lat-long details.
Search the internet for the given query and provides the list of search results.
Compound tool names suggest multiple responsibilities. 'nearest_place_finder_agent' and 'navigation_agent' combine search + presentation logic, violating single-responsibility principle. These should be split into discrete tools (e.g., 'search_nearby_places', 'get_navigation_url').
Output schemas are completely undocumented. get_alerts, get_forecast, search_external_info, nearest_place_finder_agent, and navigation_agent all return complex objects (dicts, lists, strings) with no schema documentation visible. LLMs cannot plan downstream tool calls or extract the right fields without knowing what the response structure is.
Google API keys are hardcoded as placeholder strings ('<YOUR_GOOGLE_API_KEY>') in nearest_place_finder_agent and navigation_agent. This is a critical security vulnerability, credentials should never appear in tool definitions. Use environment variable injection server-side.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 40 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 32 | - | v1 |
Parameter descriptions are generic or missing constraint information. 'query' in search_external_info has no guidance on format or length. 'prompt' in nearest_place_finder_agent and navigation_agent is ambiguous, does it accept natural language, coordinates, or structured queries? State expected format, range, or allowed values explicitly.
No error handling or recovery guidance. If the NWS API returns no alerts, get_alerts returns a generic string. If a location is invalid, get_forecast returns an unstructured message. Error responses should categorize failures (retryable vs. user-fixable) and suggest next steps (e.g., 'Try search_nearby_places() with a different query').
search_external_info uses an external API (Tavily) but hardcodes max_results=2 with no parameter exposure. Agents cannot control result count. More critically, the return type is declared as 'list' with no schema, what fields does each result contain? LLMs cannot extract what they need.
Tool descriptions lack WHEN and WHY guidance. 'Get weather forecast for a location' tells LLMs WHAT but not WHEN to call this vs. a general web search, or what prerequisites exist. State: 'Use this to fetch NWS 5-day forecast for US locations only. Requires valid latitude/longitude (use search_location first if needed).'
nearest_place_finder_agent and navigation_agent hardcode geographic bias (St. Paul's coordinates: 51.513446, -0.099869) with no parameter control. This is not scalable, agents cannot query for places near arbitrary locations. Add location parameters (current_latitude, current_longitude) to make tools universally usable.
get_forecast and get_alerts accept latitude/longitude and state as strings/floats but do not validate format, range, or correctness. Invalid input (e.g., latitude=999) is passed to the NWS API, causing opaque failures. Validate input ranges (latitude -90 to 90, longitude -180 to 180, state in valid US state codes) and return clear error messages.
nearest_place_finder_agent returns a list of dicts with keys 'name', 'user_rating', 'latitude', 'longitude', 'Open_now' but get_forecast and get_alerts return unstructured strings formatted manually. Inconsistent response types force LLMs to handle both structured and unstructured data. Standardize all responses to JSON objects with typed fields.