An end-to-end encrypted channel between coding agents, anywhere
agent-link demonstrates solid tool design with clear naming conventions, comprehensive parameter descriptions, and well-documented schemas. All 12 tools follow the link_* verb_noun pattern consistently. Schemas are present and properly structured with type definitions. Descriptions average ~150 chars and explain WHAT the tool does, WHEN to use it, and prerequisites. However, output schemas are not explicitly documented, error handling guidance is minimal, and the tool set lacks explicit idempotency and confirmation patterns for destructive operations. The domain is specialized (encrypted peer-to-peer messaging) and the tools are well-composed around clear single responsibilities (join, send, receive, manage channels). No security issues detected in parameter exposure. Strong baseline meets B+ expectations.
Side channels for subagents, so a long exchange does not flood the main room. action=open|close|list. Pass the returned channel_id as room= to link_send. Channels do not nest.
Answer a knock: allow=true lets them in (sends the room key sealed to them), allow=false declines. device= from the knock notification.
Replay a room from the on-disk transcript, including messages from before this session. Use after a restart or /clear.
Drain new messages. NON-BLOCKING, returns [] when nothing is new. Cheap — call between steps of your own work. Long messages are cut at 400 chars; use link_read for the rest.
Create or join a room. room= alone creates one; invite= joins with a 'name#SECRET' invite or knocks with a 'name#DOOR-...' door code (a member must let you in). If it answers need_name, ask the user "Your name?" and retry with name=. Persists across restarts.
Output schemas not documented. Tools return structured data but LLMs cannot plan downstream calls without knowing expected fields. link_status, link_inbox, link_history, link_join responses should document returned field names and types.
Destructive operations (link_remove, link_role, link_grant with allow=false) lack explicit confirmation or dry-run support. Agents may irreversibly remove members or deny access without intermediate confirmation. No recovery guidance in error scenarios.
Error handling lacks recovery guidance. When link_join answers 'need_name', the description explains the LLM should ask the user and retry, but no structured error response format is defined. Error messages should categorize failures as retryable, user-fixable, or fatal with actionable next steps.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Leave a room. You disappear from the member list and stop receiving messages. Others see a notice.
Full text of one message by msg_id, when link_inbox truncated it.
Remove a member: rekeys the room so their device reads nothing new, and tells them. Admins only. Revoke their carrier repo access too.
Make a member admin, or member again. Admins only; v2.3+ rooms only.
Send a message to a room. NON-BLOCKING: returns immediately, and queues if nobody is reachable, so it is always safe to call. Use it to split work, report progress, or hand off a task.
Rooms you are in, who is online, unread count, live transport. Starts the daemon if needed. Call first in a session.
BLOCKING: wait for a message or the timeout. Use only when you cannot proceed without an answer — otherwise send, keep working, and call link_inbox later. Always returns by timeout_ms.
Device/room parameter resolution is implicit. Many tools accept 'device= from the knock notification' or 'Room name or id. Omit if you are in one room.' This assumes implicit context. Parameters should explicitly state whether unambiguous names are supported and whether context fallbacks apply, with clear constraints.
Idempotency not documented. link_send is marked NON-BLOCKING and safe to retry, but idempotency guarantees for other tools (link_grant, link_role, link_remove) are not stated. Agents need to know which operations are safe to retry without side effects.