Loading ToolBench
Service agreements for freelancers: scope, deliverables, rate, termination and liability caps.
Strong tool naming (verb_noun pattern), comprehensive parameter schemas with type constraints, and detailed descriptions. All 9 tools have clear names starting with action verbs (agreement_*). Input schemas are well-structured with proper JSON Schema types, enums, min/max constraints, and maxLength limits. Descriptions average ~180 chars and explain WHAT, WHEN, and consequences. However, output schemas are not explicitly documented in the source, responses are inferred from code logic rather than declared. Error handling is present but minimal (no recovery guidance or actionable error messages visible). Tool composition is clean (single responsibility per tool), and parameter naming is consistent (agreement ID or client name as lookup key). Missing: explicit output schema documentation, error classification guidance, and confirmation patterns for destructive operations.
Run the before-you-send-it checklist on one agreement: lists missing fields and flags one-sided gaps. Pass the agreement id or client name.
Write a service agreement between a freelancer and a client before the work starts: the parties, the scope of services, the deliverables, the rate and payment terms, start and end dates, a termination notice period, a liability cap and the governing jurisdiction. Stores the agreement and returns it rendered as clean Markdown with a signature block. Free tier: 3 active agreements; expiring a finished one frees its slot.
Delete one agreement. Pass the agreement id or client name. Deletion is permanent and cannot be undone.
List all agreements, with a summary of each: id, parties, status, rate, dates, deliverable count, and when it was last changed. Free tier: lists all, but only 3 can be active at once.
Read one agreement in full: all fields, the full history of status changes, and the rendered Markdown. Pass the agreement id (e.g. SA-2026-0003) or the client name if only one agreement has it.
Output schemas not explicitly documented. Tool descriptions state what is returned (e.g., 'rendered as clean Markdown', 'summary of each'), but the actual response structure (field names, types, pagination) is not declared. LLMs cannot plan downstream tool calls or extract fields reliably without documented output schemas.
Destructive operation (agreement_delete) lacks confirmation or dry-run pattern. No indication in description that deletion is permanent and irreversible. LLMs may invoke delete without user confirmation, causing data loss.
Error handling is minimal. No visible recovery guidance in tool descriptions (e.g., 'If agreement not found, try agreement_list() to see available agreements'). Error responses are likely raw failures without actionable next steps for the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Render one agreement as Markdown or, on Pro, as print-ready HTML. Pass the agreement id or client name, and the format: markdown or html. HTML is a Pro feature.
Update one agreement: change any field except the id and created date. Pass the agreement id or client name. Dates must be YYYY-MM-DD. The updated timestamp is set to now.
Move an agreement to the next status in the flow: draft → sent → signed → expired. Pass the agreement id or client name. Optionally add a note and a date (YYYY-MM-DD) the step is stamped with; if you do not pass a date, today is used.
List the built-in clause library: optional clauses you can add to an agreement. Free tier: summaries only. Pro: full text with variables filled from the agreement.
Dual-lookup pattern (agreement ID or client name) is convenient but underdocumented. Descriptions state 'Pass the agreement id (e.g. SA-2026-0003) or the client name when only one agreement has it' but do not explain what happens if multiple agreements share a client name or if the lookup is ambiguous.
agreement_list lacks pagination parameters (limit, offset, cursor). Free tier lists all agreements, but no indication of result limits or how to handle large agreement counts. Unbounded list responses risk context window exhaustion.