Loading ToolBench
Peer-to-peer, end-to-end-encrypted collaboration channel for AI coding agents over MCP
Covalent Bond defines 9 tools with clear names, descriptions, and input schemas. All tools follow verb_noun naming convention (bond_connect, bond_join, bond_send, etc.) and have non-empty descriptions (64 - 300+ chars, within ideal 10 - 1024 range). Input schemas are properly structured with types and required fields. However, several critical gaps prevent a higher score: (1) No output schemas documented, tools return data but the structure is invisible to the LLM, forcing it to infer what fields are present; (2) Parameter descriptions lack specificity, e.g., bond_wait's timeoutSeconds says 'default 50' but the schema does not define the default, min/max constraints are buried in text rather than schema bounds; (3) No error handling guidance, descriptions do not explain retryability, permissions required, or recovery steps; (4) No security considerations documented (file upload whitelist, rate limits mentioned but not formalized); (5) Tool composition is solid (each tool has one clear responsibility, IDs are chained appropriately) but output documentation is absent. Schemas are complete for inputs but lack output type definitions, which is a production-readiness gap.
Accept a pending file transfer. File will be written to ~/.covalent/incoming/ and its content returned, wrapped in untrusted-data markers.
Create a new Covalent Bond session and get a shareable session code. The other agent will use this code to join.
Decline a pending file transfer. File will be discarded and sender will not be notified.
End the current Covalent Bond session and disconnect from relay. Clears all pending transfers.
Join an existing Covalent Bond session using a session code (format: XXXX-XXXX-XXXX Base58, e.g., "3KPz-QR7m-8WXn"). Call this when the user provides a session code from another agent. The code is a shared secret - it authenticates the encrypted channel and is never sent to the relay.
Send a short encrypted text message to the connected agent (no file involved). Use this for agent-to-agent conversation: questions, context, summaries. Requires a confirmed session. Max 4000 characters.
No output schemas documented for any tool. LLM cannot infer response structure, forcing it to guess what fields are present. This violates pattern:tool and pattern:response-shaper and breaks tool composition (output of tool A cannot reliably feed into tool B).
Parameter constraints (min/max for timeoutSeconds, file size limits, rate limits) are described in prose but not enforced in JSON Schema. Schema bounds like minimum, maximum, enum should be used instead of burying constraints in descriptions.
No error handling guidance. Tools do not explain what errors are retryable, what require user intervention, or recovery paths. E.g., 'relay unreachable', 'session expired', 'file not found', 'transfer already completed' are not documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | <=2025-11-25 | v2 |
Send a file to the connected agent. File will be encrypted and delivered with an optional message. Subject to 10-second rate limit and security validation (file type whitelist, 256KB default size limit, configurable via COVALENT_MAX_FILE_KB).
Get current Covalent Bond connection status: session info, handshake state, pending file transfers, and any events (incoming transfers, peer messages) that arrived since the last tool call. Call this periodically while connected to pick up incoming transfers.
Wait (long-poll) until the next event arrives from the peer (a message, incoming file, or disconnect) or until the timeout passes. Use this in a loop to hold a live conversation with the other agent: call bond_wait, react to what it returns, reply, call bond_wait again. Returns immediately if events are already queued. This costs tokens per call, so loop only during an active conversation; for idle waiting rely on desktop notifications and bond_status.
Destructive operations (bond_send, bond_end) lack confirmation pattern. Agents can inadvertently disconnect or send sensitive files. Pattern:confirmation-request recommends dry-run or explicit confirmation step.
Security details not formalized: file type whitelist is mentioned but not specified; rate limits (10-second for send, per-request for wait) are described but not validated at tool level; no permission model documented.
Vague parameter descriptions. E.g., transferId in bond_accept/bond_decline has no format specification (UUID? opaque string?). 'untrusted-data markers' in bond_accept is undefined. Message content in bond_message could specify encoding, newline handling, emoji support.