Loading ToolBench
Model Context Protocol server for Geotab APIs that provides access to vehicle telematics data including device information, location tracking, trip data, fault codes, and diagnostic status
The Geotab MCP server has critical definition quality issues. Tool naming is reasonable (action verbs present), but descriptions are extremely terse (many under 50 characters), parameter descriptions are minimal or absent, and input/output schemas are not fully visible in the provided code. The server exposes 8 tools but several are duplicates (get_fault_data appears twice, get_trip_data and get_trips are near-duplicates). Parameter types are documented in the tool list (string, integer, boolean, number), but descriptions for most parameters are generic and lack constraint information (ranges, format requirements, enums). No output schemas are documented. Error handling in the code exists but is generic (ValueError, Exception catching) without actionable recovery guidance. The implementation uses custom request/response models, but the actual schema definitions are not visible in the provided code excerpt. Overall, this is a typical community server with functional but below-baseline definition quality.
Get information about all devices in the Geotab account
Get the current location of a specific device
Get a list of all devices in the Geotab account
Get fault codes and diagnostic data for a device
Get fault codes and diagnostic data for a device
Get status data for a device
Get trip data for a specific device within a time range
Duplicate tool definitions: get_fault_data appears twice (in geotab-mcp-server/mcp_server/server.py and geotab-mcp-docker/mcp/operations.py); get_trip_data and get_trips are near-duplicates with conflicting 'days' parameter types (integer vs number). This creates ambiguity for LLM tool selection and wastes context.
Tool descriptions are excessively terse (most 30-35 characters). 'Get information about all devices in the Geotab account' (52 chars) is below the rubric baseline of 10-1024, approaching the minimum. Descriptions lack WHEN to call this tool, WHAT it returns, and any dependencies (e.g., 'Call get_devices first if you only have a device name'). LLMs cannot distinguish between get_devices, get_device_info, and get_device_location without richer context.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 44 | - | v1 |
Get trip data for a specific device within a time range
Parameter descriptions are missing or generic. 'include_inactive' (get_device_info, get_devices) has a one-line description with no guidance on when to set it true or false. 'days' parameter lacks a range constraint (is it 1-365? 0-unlimited?). 'device_id' appears as a required string but no guidance on format (UUID? alphanumeric? opaque Geotab ID?). Per the rubric, parameter descriptions must include expected format, range, and allowed values.
Output schemas are not documented. No indication of what fields get_device_info, get_trips, or get_fault_data return. Without documented output schemas, LLMs cannot plan downstream tool calls or extract required data.
No pagination support visible. get_devices, get_trips, and get_fault_data likely return all matching records (potentially hundreds or thousands). No limit, offset, page_size, or next_cursor parameters documented.
Generic error handling with no recovery guidance. The code catches ValueError and Exception and returns 'Operation error' or 'Operation execution failed'. No indication of whether the error is retryable, user-fixable, or fatal. No guidance on next steps (e.g., 'Device not found. Call get_devices to see available IDs').
Parameter type inconsistency: 'days' is declared as integer in get_trip_data and get_fault_data (geotab-mcp-server), but as number in get_trips and get_fault_data (geotab-mcp-docker). This inconsistency will confuse LLMs and cause validation errors if the server merges both implementations.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) declared in the schema. While all current tools appear to be READ_ONLY, this should be explicitly signaled in the tool definition so agents and clients can optimize behavior (e.g., safe to retry, safe to parallelize).