Loading ToolBench
AutoService API and Web UI application with appointment, customer, quote, and vehicle management endpoints
The MCP server exposes 5 appointment management tools with reasonable input schemas but critical gaps in documentation and description quality. Tool names follow verb_noun patterns (CreateForCustomerAsync, CreateIntakeAsync, ClaimAsync, UnclaimAsync, AdminAssignAsync), but descriptions are endpoint-focused rather than LLM-optimized. Input schemas are present with type definitions and field descriptions, but lack enums for constrained values (e.g., status field in CreateIntakeAsync accepts free-form strings). Error handling guidance is absent, no recovery hints or categorization of error types. Parameter descriptions exist but are terse (10-30 chars average) and lack validation constraints (ranges, formats, mutually-exclusive dependencies). Output schemas are not documented anywhere in the provided source. The tool definitions appear to be inferred from endpoint names rather than explicitly registered with full MCP metadata.
Assigns a mechanic to an appointment as admin. Endpoint: PUT /api/appointments/{id}/assign/{mechanicId} (AdminOnly).
Assigns the current mechanic to an in-progress appointment. Endpoint: PUT /api/appointments/{id}/claim.
Creates an appointment for an existing customer/vehicle pair. Endpoint: POST /api/customers/{customerId}/appointments (AdminOnly).
Creates a scheduler intake with customer lookup/creation and vehicle linkage. Handles appointment creation from public scheduler.
Removes current mechanic assignment from an appointment. Endpoint: DELETE /api/appointments/{id}/claim.
Descriptions are endpoint-focused and lack LLM decision-making context. 'Creates an appointment for an existing customer/vehicle pair' says WHAT but not WHEN to call it (versus CreateIntakeAsync), WHO can call it (AdminOnly), or what happens if IDs don't exist.
CreateIntakeAsync has free-form 'status' parameter (nullable) that invites invalid values; description says 'must be null or unspecified' but provides no enum constraint. LLMs will hallucinate status values. Also documents conflicting behavior: 'mutually exclusive' (vehicleId vs vehicle) but lacks clear error guidance if both are provided.
No output schema documented for any tool. LLMs cannot plan downstream calls or extract response fields (e.g., what does CreateForCustomerAsync return? appointment ID? full appointment object?). This violates the pattern that responses must contain IDs needed for chaining.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
No error handling or recovery guidance. What happens if customerId does not exist? If VehicleId is invalid? If MechanicIds list is empty after uniqueness check? No categorization (retryable vs user-fixable) or actionable next steps.
Parameter descriptions are terse (e.g., 'Customer email - must be valid format'; 'Vehicle ID - must be a positive integer') and lack specificity. No examples of 'valid format' for email; no clarification of 'positive integer' (does 0 count?). No mention of max length, constraints, or what happens on validation failure.
Tools declare admin-only restrictions (CreateForCustomerAsync, AdminAssignAsync) but no explicit permission gate or scope declaration in the tool definition. LLMs have no guidance on when these tools are callable or what permissions are needed.
CreateIntakeAsync accepts overlapping inputs (vehicleId vs vehicle object) documented as 'mutually exclusive' but no enum/const enforcement. LLMs may pass both or neither. Parameter relationship dependencies are undocumented: what if customerFirstName/customerLastName are missing when creating a new customer?