Loading ToolBench
MCP server for Clink messaging platform integration with Claude Code. Allows sending and receiving clinks across Claude Code sessions, managing projects, milestones, consensus proposals, and group collaboration.
Scoring was not performed
No output schemas documented. Tool handlers return unstructured text (type: 'text' in MCP response). LLMs cannot parse results reliably, extract nested fields, or chain tools effectively. All tools are affected.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 25 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 52 | - | v1 |
Generic error handling with no recovery guidance. When tool execution fails, the response is 'Error executing {name}: {message}' with isError: true. No categorization (retryable, user-fixable, fatal), no suggestions for next steps, no actionable guidance for the agent.
Parameter descriptions are sparse and lack constraint details. Examples: 'timeout_seconds': 'How long to hold the claim in seconds (default: 300 = 5 minutes)', no min/max bounds. 'limit': 'Maximum number of clinks to return. Default 50, max 100.', only one tool specifies max. Others (check_inbox limit=10, list_pending_verifications limit=10) lack documented constraints, inviting invalid LLM inputs.
Missing descriptions or non-actionable descriptions on several tools. 'check_inbox' description mentions auto-claim but does not explain the distributed work coordination problem or timeout behavior. 'release_clink' and 'reopen_milestone' have generic descriptions (65 chars or less) that do not explain when or why to call them vs. other similar operations.
No pagination documented for list tools. 'list_groups', 'list_members', 'list_milestones', 'list_projects', 'list_proposals', 'list_pending_verifications' have no offset/page/cursor parameters and no indication of result limits. Large result sets risk overwhelming the context window.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). The server declares tool definitions but does not use MCP tool annotations to mark which tools are read-only (list_groups, get_clinks) vs. destructive (delete_checkpoint) vs. idempotent (claim_clink with repeated claims). This limits agent reasoning about safe-to-retry vs. irreversible operations.
Complex nested parameter structures without clear serialization guidance. 'create_milestone' and 'add_checkpoint' accept 'checkpoints' and 'depends_on' arrays with complex nested objects and union types (oneOf with number|string). No examples or serialization documentation for how LLMs should format these inputs.