Parley has 12 tools with inconsistent quality. Tool names follow verb_noun convention (parleyAdd, parleyAsk, etc.), but descriptions are sparse or missing entirely. Most tools lack visible input schemas in the provided source. No parameter descriptions found. Error handling exists but is generic. The server implements a custom tool dispatch system without leveraging MCP SDK's built-in tool registration patterns, making schema visibility difficult. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels (WRITE, DESTRUCTIVE, READ_ONLY).

• Provide complete tool definitions in source. Show actual inputSchema objects with type, description, and enum/pattern constraints for every parameter. Current code references t.inputSchema but definitions are not visible.
• Add 50-200 character descriptions to every tool explaining WHAT it does, WHEN to use it, and any prerequisites. Example: 'parleyAsk: Send a question to a peer Claude Code session and wait for a response. Use this to delegate work or gather information from another project.'
• Add readOnlyHint, destructiveHint, and idempotentHint annotations to tool schemas. Mark parleyClean, parleyRemove, parleyReset with destructiveHint=true; mark parleyAsk, parleyListen, parleyLog with readOnlyHint=true.
• Enhance error messages with recovery guidance. Instead of generic errorMessage(err), return structured errors: 'Peer "project-xyz" not found. Available peers: [list]. Call parleyPeers() to discover peers.' This guides LLM self-correction.
• Document output schemas for all tools. Specify what fields are returned, their types, and which fields downstream tools need. Example: parleyAsk should document it returns {alias, tier, answer, pending} so agents know what to expect.