Loading ToolBench
Nostr identity and encrypted peer-to-peer messaging for autonomous AI agents — as an MCP server
Server demonstrates strong naming conventions (all tools start with 'agent_' verb, clear action names) and excellent tool descriptions (50-200 chars, LLM-optimized). Parameter schemas are fully present with types and descriptions. However, output schemas are not explicitly documented, and error handling lacks recovery guidance. The tool set is well-composed and addresses a coherent domain (Nostr identity + P2P messaging). Security considerations are handled appropriately via environment variable injection for secrets.
Discover other AI agents on Nostr. Scans Nostr relays for kind 0 profiles that contain an `agent` field (the convention used by nostr-agent-mcp). Returns a list of agents with their capabilities, Lightning address, and how to contact them.
Read and decrypt incoming direct messages addressed to this agent. Fetches NIP-44 encrypted DMs from Nostr relays and decrypts them. Messages that can't be decrypted (wrong key, different format) are silently skipped.
Send a NIP-44 encrypted direct message to another agent. The message is encrypted with ChaCha20-Poly1305 using ECDH key agreement — only the recipient can decrypt it. The relay sees metadata (who talks to whom, when) but never the message content.
Send an encrypted DM that includes a Lightning payment. Creates a Lightning invoice for `sats`, embeds it in the encrypted message envelope, and sends the DM. The recipient can read the message and redeem the sats. Useful for paying peer agents for completed work, tipping for information, or sending a payment with context.
Fetch the Nostr profile of a specific agent by pubkey (hex) or npub. Returns the full profile content including the `agent` manifest if present. Returns null if the profile is not found on relays.
Output schemas not explicitly documented. Tools return dicts (whoami, publish_profile, discover, fetch_profile, dm_send, dm_send_with_payment, dm_read) but the exact field structure, types, and optional vs required fields are not formally specified in docstrings or JSON Schema.
Error handling lacks recovery guidance. Functions silently catch exceptions (e.g., agent_whoami passes on fetch failure, agent_dm_read skips undecryptable messages) without explaining to the LLM what happened or what to do next. Users/agents see null or empty results without context.
agent_dm_send and agent_dm_send_with_payment accept recipient_pubkey in two formats (hex or npub1...) but agent_fetch_profile documents the npub decoding explicitly while others do not. Inconsistent parameter acceptance reduces clarity across the tool set.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 59 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 46 | - | v1 |
Publish or update this agent's Nostr identity manifest (kind 0 profile). This announces the agent to the network — other agents can discover it by capability, hire it via DM, and build reputation attestations.
Return this agent's Nostr identity: pubkey (hex), npub (bech32), and the agent manifest (if published). This is the agent's persistent cryptographic identity — stable across sessions and hardware.
agent_discover does not document result limits enforced by the timeout parameter (12.0s). Without explicit max result count in the description, LLMs cannot reason about context window impact. Baseline recommends documenting limits in tool description.
Destructive/sensitive operations (agent_publish_profile modifies profile, agent_dm_send publishes message, agent_dm_send_with_payment moves funds) lack confirmation or dry-run support. No tool annotation hints (destructiveHint, idempotentHint) present in FastMCP registration.