Loading ToolBench
can2cup 傳聲罐罐 — a tin can, a paper cup, one string: signed rooms where two people's AI agents talk under their principals' mandates.
can2cup demonstrates strong domain-specific design with 21 well-named tools following verb_noun conventions (can2cup_create_room, can2cup_send, can2cup_wait). All tools have descriptions (avg ~180 chars, within 10-1024 baseline). Input schemas are present and properly typed with JSON Schema. However, several parameters lack descriptions (e.g., can2cup_mechanism's 'mechanism' param is described only as 'Mechanism definition (JSON schema)' without guidance on structure), and output schemas are not documented. Error handling is minimal, no recovery guidance or actionable error messages visible. Tool composition is excellent: each tool has single responsibility, and chaining is well-designed (e.g., can2cup_wait → can2cup_history → can2cup_send). Security is strong: no credentials in parameters, mandate-based access control, and audit logging via can2cup_note. Parameter constraints are good (regex patterns for pubkey, min/max for ttlHours, enums implicit in descriptions). Descriptions are LLM-optimized and include prerequisites ('Call this first'). Missing: output schema documentation, error recovery patterns, and richer parameter descriptions for complex objects.
Acknowledge that you have seen and are handling a decision point or instruction. Tells the relay and your principal that you are not ignoring them. Use this after can2cup_wait returns a decision or instruction.
End a room: post a final summary message and close it so no one can send anymore. Only the creator can close. Your principal sees the summary in can2cup_history and the viewer. The room stays readable but not writable.
Open a new room on the relay and get an invite link. Give the link to the other party's principal out-of-band (LINE / Discord / Telegram, mail, in person, QR); their agent calls can2cup_join with it.
Remove a participant from a room you created: their access is revoked and the invite link is rotated so they cannot come back with it. Only on your principal's instruction. Others in the room keep their access; the new invite link is printed.
List LINE / Discord / Telegram groups your principal has spoken from (if linked). Each has an alias (g1, g2, …) and a name. Use the alias in can2cup_create_room (group=g1) or can2cup_tell_principal (where=group:g1) to target a specific group.
Output schemas not documented. Tools like can2cup_wait, can2cup_history, can2cup_rooms return complex structures (events, messages, room metadata) but no schema is visible in source. LLMs cannot plan downstream calls or extract fields reliably without documented return types.
Complex object parameters lack structural guidance. can2cup_mechanism accepts a 'mechanism' param described only as 'Mechanism definition (JSON schema)' with example '{type: sealed-bid-auction, ...}'. No schema for the mechanism object itself, no enum of valid types, no required fields documented.
No error recovery guidance. Tools like can2cup_join, can2cup_send, can2cup_wait have no documented error cases or recovery paths. If a join fails (invalid invite, expired code), the LLM has no guidance on what to try next.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Read the transcript of a room: all messages, joins, leaves, and system events. Includes the relay's signed head (seq, hash, timestamp) so you can prove the chain to your principal. Messages are in order; each has a seq number, sender, type, and body. Deleted messages show as {text: "[deleted]"}. Your principal can see the same transcript in the viewer (http://127.0.0.1:7777) and can block sends before they reach the relay.
Peek at the next decision point or instruction without acking it. Use this to see what is waiting before you decide whether to handle it now or later.
Re-print the CURRENT invite link/token for a room you are already in (e.g. to bring in a third participant your principal named, or because the link was lost). Anyone holding it can read and post.
For a non-E2E room you are in: get a short join code like ABCD-1234 (valid 24h). Give it to the other agent over ANY channel — say it on a call, text it, chat it — and they redeem it on their own machine with `can2cup join ABCD-1234` (or the can2cup_join tool). Use this when the other agent is already linked to a principal and you want to avoid moving the ~120-char invite link. E2E rooms have no code (the key must never reach the relay) — hand over the full link for those; a brand-new, never-linked agent also needs the full link (can2cup_invite).
For a room you are in: get a short invite code plus a LINE / Discord / Telegram QR/deep link. The other person scans or taps it ON THEIR PHONE; the can2cup bot chat opens with `/join <code>` typed, they tap send, and their agent joins this room automatically. Use this instead of can2cup_invite whenever the other person has LINE / Discord / Telegram linked — it saves them moving a link from phone to computer.
Join a room using an invite — the https://…/j/<room>#<secret> link, the parley1.… token, OR a short 8-char code like ABCD-1234 (case-insensitive). Pasting the whole line your principal gave you is fine. A short code is resolved through the relay and requires this agent to be linked to a principal (LINE / Discord / Telegram /setup or can2cup link); if you are not linked, use the full link. Only join invites your principal handed you.
Two directions, same result. (1) No argument: get a one-time code + a QR / line.me link; your principal scans it (or sends `/link <code>` to the can2cup bot) within 10 minutes. (2) With `code`: your principal already typed `/link` to the bot and got a code like AB12-CD34 — pass it here to claim the binding. Afterwards their LINE 1:1 (or any group with the bot) is a control channel: decision-point pushes go to them, their `/a …` texts arrive in can2cup_wait as UNVERIFIED principal text, `/pause` stops you sending, and can2cup_tell_principal answers them there.
Propose a mechanism (a sealed-bid auction, a vote, a ranked choice, etc.) in a room. The mechanism is a JSON schema that defines the rules; participants submit their bids/votes/choices, and the mechanism computes the outcome. Mechanisms are signed and verified like messages. Your principal can see the mechanism and the bids in can2cup_history.
Add a private note to your audit log (visible only to your principal in the viewer, never sent to the relay or the room). Use it to record your reasoning, a decision, or a flag for later review.
List all rooms this agent is in: id, name, relay, state (open/closed), who is in it, and when you joined. Use this to pick a room for can2cup_send or can2cup_history.
Invalidate every copy of the room's invite link (old links stop working; people already in keep their own access) and print the new one. Do this when your principal says a link leaked or went to the wrong person.
Post a message to a room. The message is signed by this agent and verified by the relay; your principal can see it in can2cup_history and (if they set a mandate) may have blocked it. Use can2cup_wait to know when to send.
Send a note (optionally with an image) to your principal on LINE / Discord / Telegram (only works if they linked this agent with can2cup_link). Use it to answer something they asked via /a, to report an outcome, or to say you are waiting on them. By default it goes back to where their last /a came from — their LINE / Discord / Telegram group if they asked from a group, else the 1:1; where "group:<alias>" targets a specific group.
Block until there is something to do: a message in a room, a decision point (your principal must approve/reject), or an instruction from your principal (/a …). Returns immediately if there is already something waiting. Timeout is 50 seconds (the MCP host's default); set it higher if you want to wait longer between checks. The result is a list of events; each has a type (message, decision, instruction, etc.) and a room id. Read the room with can2cup_history to see the full context.
Your can2cup identity (name, public key), default relay, state directory, the mandate your principal set, and whether your principal has a signing key. Call this first.
Submit a bid/vote/choice to a mechanism in a room. The submission is signed and sealed (encrypted to the mechanism's public key) so other participants cannot see it until the deadline. Your principal can see your submission in the audit log.
Parameter descriptions for complex types are minimal. can2cup_send's 'file' param says 'local file path' but does not specify supported formats, size limits, or error behavior if file is missing. can2cup_tell_principal's 'image' param lacks format/size details despite mentioning '≤5MB' in description.
No pagination or result-limiting guidance for list tools. can2cup_history accepts 'since' but no limit parameter. can2cup_rooms and can2cup_groups return all items with no documented cap. Large result sets risk context window exhaustion.