Loading ToolBench
Geotab FuelGuard MCP Server — clean multi-module rewrite. Provides tools for fuel theft detection, card location verification, fleet analytics, and Slack notifications.
The server has 8 tools with moderately good descriptions (most 80-150 chars), proper input schemas with types, and clear naming conventions following verb_noun patterns. However, there are significant gaps: no output schemas are documented, no error handling guidance is provided, and several parameter descriptions lack detail about constraints, ranges, and valid values. The tools follow READ_ONLY/WRITE risk classification, but lack details about what errors might occur and how agents should recover. Output structures for complex tools like fuelguard_detect_fuel_theft are inferred but not documented in the schema. The descriptions are functional but could be more specific about when/why to use each tool versus alternatives. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present in the visible code.
Detect fuel theft events from StatusData using pattern analysis. Returns list of detected drops with confidence scores and severity ratings.
Analyze fuel efficiency trends to detect unusual consumption patterns that may indicate siphoning or other theft.
Generate fleet-level fuel consumption summary with top theft candidates and cost impact analysis.
Verify fuel card transaction locations against GPS data. Matches card purchases to vehicle locations and identifies geographic mismatches that may indicate fraud.
Retrieve detailed information about a Geotab device including VIN, license plate, and status.
List all Geotab devices in the fleet with their labels and status.
No output schemas documented for any tool. Agents cannot infer what fields to expect in responses, forcing them to guess or make trial-and-error calls downstream.
Numeric parameters lack documented bounds and constraints. E.g., min_drop_L and mismatch_threshold_m have no min/max constraints; limit parameters have no upper bounds. This invites LLMs to pass invalid values.
No error handling guidance in tool descriptions. Agents have no way to know what errors are retryable, what errors require user intervention, or how to recover from failures (e.g., Geotab API timeout, device not found, invalid date range).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 17 | - | v1 |
Reconcile fuel card transactions against detected fuel drops to identify unmatched events.
Send a theft alert or card hold request to Slack webhooks for fleet managers and finance teams.
fuelguard_send_slack_alert is a WRITE operation but lacks confirmation/dry-run capability. Agents could accidentally send duplicate or malformed alerts without a safety mechanism.
Tool descriptions do not indicate dependencies or multi-step workflows. E.g., fuelguard_reconcile_card_drops likely depends on first running fuelguard_detect_fuel_theft, but this is not documented. Agents may call tools in wrong order.
ISO 8601 date format parameters (from_iso, to_iso) lack description of accepted formats, timezone handling, and validation rules. E.g., does '2024-01-15' work, or must it include time like '2024-01-15T00:00:00Z'?
Pagination not explicitly documented for list-returning tools. fuelguard_fleet_summary and fuelguard_list_devices both return limited results (default limit 20 and 100), but there is no mention of how to retrieve additional results, total count, or next_cursor.