Loading ToolBench
A task management and project collaboration application with Next.js frontend, PostgreSQL backend, and file storage capabilities
Conatus is a Next.js task management application exposing 19 REST API endpoints as MCP tools. While all tools have descriptions and basic input schemas, the implementation has significant gaps: (1) Tool names do not follow verb_noun convention, they are HTTP method + path strings (e.g., 'POST /api/account/avatar') rather than semantic names like 'upload_avatar' or 'get_avatar'. This forces LLMs to parse HTTP semantics instead of intent. (2) Parameter descriptions are minimal (10-30 chars) and lack actionable constraints, e.g., 'Image file (must be image/* MIME type, max 5MB)' is present but most params lack format/range guidance. (3) Output schemas are not documented anywhere in the provided source, we see input schemas but no response structure definitions. (4) Error handling is absent, no recovery guidance, no categorization of retryable vs fatal errors. (5) No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). (6) Mutually exclusive parameters (taskId vs projectId in comments tools) are documented in descriptions but not enforced via schema constraints. Average tool description length ~80 chars (below 194-char baseline); no parameter descriptions for many fields.
Delete the authenticated user's account and associated data
Revoke a registration invite by ID (admin only)
Delete an attachment file from S3 storage and database
Delete a comment
Retrieve the authenticated user's avatar image from S3 storage
List all active registration invites (admin only)
List all attachments for a specific task
Tool names are HTTP method + path strings (e.g., 'POST /api/account/avatar') instead of semantic verb_noun names (e.g., 'upload_avatar'). LLMs cannot infer intent from HTTP syntax; they need action-oriented names.
Output schemas are not documented. No response structure definitions provided for any tool. LLMs cannot plan downstream calls or extract required fields without knowing what each tool returns.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 29 | 2026-07-28+ | v2 |
Download an attachment file from S3 storage
List comments for a task or project
Update a comment's content
Upload a user avatar image to S3 storage and update user profile
Change the authenticated user's password
Create a new registration invite (admin only)
Upload a new attachment file to S3 storage
Confirm password reset with token and set new password
Request a password reset email with rate limiting
Verify email address with token and accept pending project invitations
Resend email verification link with rate limiting
Create a new comment on a task or project
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels marked in metadata (READ_ONLY, WRITE, DESTRUCTIVE). Agents cannot distinguish safe from dangerous operations.
Parameter descriptions are minimal (10-30 chars) and lack actionable constraints. Most params have no format guidance, range limits, or enum values. E.g., 'id' params lack explanation of format; 'content' params lack length limits.
No error handling guidance. Tools lack recovery hints, error categorization (retryable vs fatal), or actionable error messages. LLMs cannot self-correct on failures.