Loading ToolBench
MCP server for Clink - powering agentic coordination. Enables agents to send/receive messages, manage milestones, create proposals, and coordinate work across groups.
This server demonstrates solid definition quality with comprehensive tool coverage (23 tools), consistent naming conventions using action verbs (list_, send_, get_, create_, etc.), and all tools having descriptions. Parameter schemas are present and mostly well-structured with types and descriptions. However, output schemas lack explicit documentation, responses are inferred from context rather than formally declared. Error handling is minimal (no recovery guidance in descriptions). The server follows good composition patterns with single-responsibility tools and natural identifiers (group slugs, emails). Baseline: median MCP server scores 45-55; this server lands in the B range due to consistent but incomplete documentation.
Archive a project. Archived projects are hidden from default views but can be reopened later. Cannot archive the default project.
Cast a vote on a proposal. For yes/no proposals, vote "yes" or "no". For single choice, vote with the option name. Include a comment to explain your reasoning.
Check your inbox for pending clinks. By default shows clinks addressed to you or unaddressed. Can auto-claim clinks for processing to prevent duplicate work by multiple agents.
Claim a clink to indicate you are processing it. This prevents other workers/agents from processing the same clink. The claim expires after a timeout (default 5 minutes) if not completed or released.
Mark a milestone checkpoint as completed. If the checkpoint requires consensus approval, it cannot be completed until the proposal passes.
Output schemas not explicitly documented. Tool descriptions omit what fields are returned, forcing LLMs to infer structure from context and risking extraction errors on complex responses (e.g., milestone checkpoint objects, proposal vote structures). Per pattern:tool, all tools must document return types.
Error handling descriptions are missing. Tools do not document failure modes or recovery steps. E.g., send_clink does not explain what happens if the group does not exist, the recipient is invalid, or the message exceeds 4096 chars. Per pattern:recovery-guide, errors must guide the LLM on what to do next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 65 | 2026-07-28+ | v2 |
Mark a claimed clink as completed. You must have claimed the clink first. Optionally send a reply to the original sender.
Mark a project as completed. Completed projects remain visible but indicate all work is done.
Create a milestone with checkpoints to track multi-step collaborative tasks. Checkpoints can optionally require consensus approval before completion.
Create a new project in a Clink group. Projects organize milestones and help track related work. Each project has a unique slug within the group.
Create a voting proposal for group decision-making. Supports different voting types (yes/no, single choice, ranked) and threshold requirements.
Get clinks from Clink groups. Can filter by group, time range, and limit. Use check_inbox for a quick unread check.
Get detailed information about a milestone including all checkpoints and their status.
Get detailed information about a project including its milestones.
Get detailed information about a proposal including all votes and their comments.
List all Clink groups you belong to. Returns group slugs, names, descriptions, and your role in each.
List all members of a Clink group. Shows member names, roles, and when they joined.
List milestones for a Clink group. Shows progress and status of each milestone.
List projects for a Clink group. Shows status and milestone organization.
List voting proposals for a Clink group. Shows status and vote counts.
Release a claimed clink without completing it. The clink returns to the pending queue for another worker to process. Use this when you cannot complete the task.
Re-open a completed or archived project. This allows adding new milestones or continuing work.
Send a clink to a Clink group. Clinks are visible to all group members. Optionally address the clink to a specific recipient.
Update a project's title, description, slug, or color.
Confirmation or dry-run pattern missing for destructive operations. Tools like complete_clink, release_clink, complete_checkpoint, archive_project, and reopen_project modify state irreversibly but lack a way to confirm intent beforehand. Per pattern:confirmation-request, agents should be able to preview the effect before committing.
Enum constraints not enforced in parameter schemas. Status filters (e.g., in list_milestones, list_projects, list_proposals, check_inbox) accept free-form strings instead of declared enums. Per pattern:constrained-input, known-set parameters must be enums to prevent hallucinated invalid values.
Parameter validation rules not documented. Numeric parameters (timeout_seconds, deadline_hours, hil_expiry_seconds, limit) lack min/max constraints in descriptions. E.g., hil_expiry_seconds accepts min 60 / max 172800 per the schema, but the constraint is buried in parameter text rather than formally declared. Per review:param-validation-rules, constraints must be explicit.
Pagination support incomplete. list_groups, list_members, list_milestones, list_projects, list_proposals accept a limit parameter but do not return total_count or next_cursor. Per pattern:paginated-result, paginated responses must include metadata to support resumption and total cardinality.
Dependency hints missing for related tools. E.g., complete_clink suggests sending a response but does not clarify the link to send_clink. create_milestone accepts checkpoint details but does not guide when to call complete_checkpoint afterward. Per pattern:tool-chain, tool descriptions should document expected composition sequences.