Both tools have minimal descriptions (under 100 chars) and lack parameter-level documentation. Input schemas are present with basic type info but lack descriptions for individual parameters. No output schema is documented. Tool names follow verb_noun pattern but descriptions are too terse to guide LLM selection. No error handling guidance, no idempotency markers, no security considerations documented.

• Add parameter descriptions: 'sender_id: Unique identifier of the node voting (e.g., node_1, node_2). Must be a non-empty string.' and 'message: The transaction or proposal payload to be voted on. Must be a non-empty string; digest is computed via SHA-256.'
• Document output schema in tool description: 'Returns {digest: str (first 12 chars of SHA-256), prepare_votes/commit_votes: int, quorum_required: int, is_prepared/is_committed: bool}.'
• Expand tool descriptions to 150-250 chars explaining WHEN to call: 'add_prepare: Records a prepare vote from a node and checks if 2f+1 quorum is reached. Call this for each node's prepare phase vote. Returns whether prepare quorum is achieved.' Similar for add_commit.
• Add error handling: 'If sender_id is empty or message is empty, return error: {error: "Invalid input", message: "sender_id and message must be non-empty strings"}. If quorum not yet reached, return is_prepared: false with current vote count.'
• Document state mutation and idempotency: 'Calling add_prepare twice with the same sender_id and message is idempotent, the vote is recorded once. Calling with different messages from the same sender_id records separate votes for each message digest.'