Loading ToolBench
Model Context Protocol (MCP) server implementation for Ashby ATS integration
Strong foundation with 50 tools, all registered with schemas and descriptions. Tool annotations (readOnlyHint/destructiveHint/idempotentHint) are correctly implemented and published. Naming follows verb_noun convention consistently (create_*, list_*, get_*, search_*, update_*). However, parameter descriptions are sparse or missing for many tools, only create_candidate shows detailed param docs; most others lack descriptions for their input fields. Output schemas are not documented. Error handling guidance is absent. Descriptions are adequate (50-150 chars typical) but lack dependency hints and recovery guidance. No batch operations despite 50 tools suggesting frequent multi-step workflows.
Add a hiring team member to an application
Add a tag to a candidate
Add a candidate to a project
Anonymize a candidate (irreversible)
Cancel an interview schedule
Change the source of an application
Change the stage of an application
49 of 50 tools lack visible input schemas in source code. Only create_candidate shows a complete JSON Schema with typed properties and descriptions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | <=2025-11-25 | v2 |
Create a new application
Create a new candidate in Ashby. Only `name` is required; other fields are optional but useful.
Create a note on a candidate
Create a custom field
Create an interview schedule
Create a new job
Fetch a single application by ID
Fetch a single candidate by ID (full record including custom fields, applications, etc.)
Fetch a single custom field by ID
Fetch a single interview by ID
Fetch a single interview stage by ID
Fetch a single job by ID
Fetch a single project by ID
Fetch candidates by auto-paginating /candidate.list, up to 50 pages (5,000 candidates) in one call. If the workspace has more than that, the response is marked `truncated: true` and includes `nextCursor` — continue with list_candidates from that cursor. Use list_candidates directly when you only need a single page.
List feedback on applications
List applications
List client info for a candidate
List notes on a candidate
List all candidate tags
List candidates. Uses Ashby's cursor-based pagination.
List custom fields
List interview events
List interview plans
List interview schedules
List interview stage groups
List interview stages
List interviews
List jobs
List projects
List candidate sources
Remove a hiring team member from an application
Search for candidates by email and/or name
Search for jobs
Search for projects
Set the value of a custom field on a record
Set the status of a job
Transfer an application to another job
Update an existing application
Update an existing candidate's fields. Only send fields you want to change.
Update an interview schedule (creates a new event when no interviewEventId is given)
Update an existing job
Upload a file for a candidate
Upload a resume for a candidate (replaces the primary resume)
Parameter descriptions are missing for 49 tools. Only create_candidate documents its input fields (name, email, phoneNumber, etc.). LLMs cannot infer parameter meaning from names alone, 'status' could mean HTTP status, job status, or application stage.
No output schemas documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., candidate_id for add_candidate_to_project) without knowing what get_candidate returns. Baseline: 100% of A+ tools document return types.
No error handling guidance. Tools lack recovery hints (e.g., 'Candidate not found. Try search_candidates() with a partial name.'). Agents receive raw errors with no actionable next steps.
No batch operations despite 50 tools and common multi-step workflows (e.g., add_candidate_tag called in loops). Agents waste tokens and latency on sequential calls. Consider add_candidate_tags (array), add_candidates_to_project (array), etc.