Loading ToolBench
Full-surface MCP translator for the Planday API, plus an Excel/Power BI bridge. Provides access to all 125 Planday operations through a tiered tool system (universal search/describe/call, curated reads, and composed tools) and a standalone HTTP bridge for timesheet reporting.
Strong foundation with 9 well-defined tools covering a complex API surface. All tools have descriptions (10 - 200 chars, within baseline 34 - 392 range) and explicit input schemas with types. Naming follows verb_noun pattern (search_, describe_, call, get_, summarise_). Key strengths: curated reads reduce discovery friction; composition tools (timesheet, cost summary) abstract multi-endpoint complexity; error handling includes recovery guidance. Gaps: parameter descriptions are minimal (many lack context on format/constraints); output schemas are not formally documented; no tool annotations (readOnlyHint/destructiveHint); some parameters lack descriptions (e.g., 'path' and 'query' in planday_call are generic objects with minimal guidance).
Invoke any of the operations returned by planday_search_operations. Arguments are validated against the API spec before the call. Paged endpoints are walked to completion automatically - you never need to pass limit or offset. Mutating operations require PLANDAY_WRITE_TIER to be raised.
Full signature for one operation: every path, query and body parameter with its type and whether it is required, plus the response shape. Call this before planday_call unless you already know the arguments.
Curated read for departments
Curated read for employees
Curated read for shifts
The Timesheet Report: one row per shift with scheduled vs worked hours, breaks, approval status and cost. Joins three endpoints Planday does not combine itself. For totals and comparisons prefer planday_summarise_staff_cost - it aggregates server-side instead of row-by-row.
Curated read descriptions are generic ('Curated read for X'). LLMs cannot distinguish when to use planday_get_departments vs planday_search_operations without richer context. Add use-case guidance: 'Use this to list all departments with IDs for filtering other queries. Faster than search_operations for the common case.'
planday_call's 'path', 'query', and 'body' parameters lack descriptions explaining format, required structure, or examples. LLMs cannot infer that 'path' expects {departmentId: 101} vs {department_id: 101}. Add: 'Path parameters as an object, e.g. {departmentId: 101}. Keys match the operation signature from planday_describe_operation.'
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The Risk field in tool metadata is not exposed to the MCP protocol. Add tool annotations so clients can warn before executing destructive operations and optimize caching for read-only tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 67 | 2026-07-28+ | v2 |
Search all 125 Planday API operations by keyword. Start here when no curated tool covers what you need - every endpoint in the API is reachable this way. Returns operation ids to pass to planday_describe_operation and planday_call. Areas: absence, hr, payroll, punchclock, reports, scheduling.
Composed tool for summarizing staff costs by department or employee
Portal identity plus the current mode and write tier. Run this first: it proves the credentials, the X-ClientId header and the token's scopes in a single call.
Output schemas are not formally documented. capRows() helper returns {rows, returned, matched, truncated} but this structure is not declared in tool definitions. LLMs cannot plan downstream operations without knowing response shape. Document return types in tool descriptions or via explicit schema declarations.
Error messages in planday_describe_operation suggest alternatives ('Did you mean...') but this recovery guidance is not consistent across all tools. Standardize error responses to always include actionable next steps (e.g., 'Try planday_search_operations with a partial name').