Loading ToolBench
An Express + TypeScript server that makes Jake Gaylor legible to AI systems: a webpage, llms.txt, an MCP server, and an A2A agent over the same resume.
Three tools with clear names, solid descriptions, and well-structured input schemas. All parameters have types and descriptions. Tool names start with action verbs (get_, book_) and are unambiguous. Descriptions are 200-350 chars, within the 10-1024 baseline. However, output schemas are not explicitly documented, responses are JSON text blobs without declared field structure. Error handling provides some recovery guidance but could be more granular. No parameter validation rules stated (e.g., email format, ISO 8601 format enforcement delegated to implementation). Schemas use Zod validation at runtime but do not expose constraints in descriptions.
Book a 30-minute intro call with Jake Gaylor. Use a start time from get_availability. The booking is pending until Jake Gaylor confirms or declines it; the attendee email receives the outcome.
Get Jake Gaylor's open intro-call slots for the next two weeks (30-minute meetings). Returns JSON of ISO 8601 UTC start times grouped by day, plus the human booking page URL. Use book_intro_call to book one.
Structured screening and logistics data for Jake Gaylor: role types, level, location, relocation, remote preference, work authorization, compensation stance, availability, and machine-readable resume links. Returns JSON.
Output schemas not documented. Tools return JSON text blobs (content: [{type: 'text', text: JSON.stringify(...)}]) without declaring field structure. LLMs cannot plan downstream operations or extract specific fields reliably.
Parameter validation constraints not stated in descriptions. 'email' parameter lacks format guidance (e.g., 'valid email address'). 'start' parameter says 'ISO 8601' but does not warn against past dates or explain how timezone-naive strings are handled.
Error responses are text blobs without structured error codes or categorization. When booking fails, the response is unstructured text describing the failure. LLMs cannot distinguish retryable errors (slot taken) from user-fixable errors (invalid email) from fatal errors (service down).
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 64 | 2026-07-28+ | v2 |
'name' parameter in book_intro_call lacks length guidance in description. Schema validates max 120 after slicing, but description does not state this constraint. LLMs may pass longer names and be silently truncated.