Loading ToolBench
MCP server for the FieldRoutes pest-control / lawn-care API. Exposes tools to read and write customers, appointments, subscriptions, routes, tickets (invoices), and notes.
FieldRoutes MCP has solid naming conventions (verb_noun pattern across all 9 tools) and comprehensive parameter schemas with type definitions. Descriptions are present and moderately detailed (avg ~150 chars), explaining WHAT each tool does and key constraints. However, parameter descriptions are inconsistent, some params lack detail on format/constraints (e.g., 'date_from' says 'YYYY-MM-DD HH:MM:SS format' but 'reason' in cancel_appointment is bare). Output schemas are not explicitly documented in the code; responses are JSON strings but field structure is inferred. Error handling is present (custom exception hierarchy) but recovery guidance is minimal. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. Missing idempotency guidance for write operations.
Cancel an appointment with a free-text reason (e.g. 'customer request').
Create a new customer. Returns the new customerID. Required: first_name, last_name. At least one contact method (phone or email) is strongly recommended so office staff can reach the customer.
Fetch one customer record by ID.
Verify FieldRoutes credentials work. Run this first if any tool errors.
Search appointments. ``date_from``/``date_to`` in ``YYYY-MM-DD HH:MM:SS`` format. status: 0=pending, 1=completed, 2=cancelled (verify against the live API once you have credentials).
Search FieldRoutes customers. All filter params are optional; omit to fetch the first batch. ``name`` matches against first/last name using LIKE. ``balance_min`` and ``balance_age_days`` map to FieldRoutes' balance/balanceAge fields. Returns a JSON array of customer records (when include_data=True) or a list of customerIDs (when False). The FieldRoutes API caps search at 50k IDs and resolved-data includes at 1k; for bigger pulls use the apiModule.fullResult pagination loop in the official docs.
Output schemas not documented. Tools return JSON strings but field structure is inferred from descriptions rather than formally specified. LLMs cannot reliably extract nested fields or plan downstream calls.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Tools are marked with Risk levels in metadata but not exposed to LLM via MCP tool annotations. LLM cannot distinguish safe reads from destructive writes without parsing descriptions.
Parameter descriptions inconsistent in detail. Some params (e.g., 'date_from', 'balance_age_days') include format/constraint details; others (e.g., 'reason' in cancel_appointment, 'fields' in update_customer) are bare. LLM cannot reliably infer valid input ranges.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | <=2025-11-25 | v2 |
Search service routes. ``date`` in ``YYYY-MM-DD`` format.
Search recurring service subscriptions (pest-control plans, lawn-care contracts).
Update an existing customer. ``fields`` is a partial customer dict (phone, email, address, balance, status, etc). Returns success boolean.
Error handling present but recovery guidance minimal. Custom exceptions exist (FieldroutesAuthError, FieldroutesNotFoundError) but tool descriptions do not explain what to do on failure (e.g., 'If customer not found, try search_customers first').
Pagination not explicitly documented. search_* tools mention FieldRoutes API caps (50k IDs, 1k resolved data) but do not expose limit/offset/cursor parameters. LLM cannot control result size or iterate large datasets.