The 'faucet' tool has a minimal schema with only one parameter (address: string) but critically lacks a description entirely. The parameter itself has null description. No output schema is documented. The tool performs a WRITE operation (transfers funds) but provides no guidance on error handling, recovery, or side effects. This violates core patterns: tool-description (every tool needs a description), tool-parameter-description (every param needs a description), and command-tool (write operations must declare their irreversible nature). The implementation exposes a hardcoded secret key in source code, violating secret-injection pattern.

• Add a tool description (50-200 chars): 'Transfer test tokens to a blockchain address. Requires a valid address parameter. Returns transaction hash. This is a test faucet, use only on testnet.'
• Add parameter description for 'address': 'Blockchain address to receive tokens (e.g., solana address format, 44 characters base58-encoded)'
• Move the hardcoded secret key to an environment variable (e.g., FAUCET_SECRET_KEY) and load it at startup via process.env. Never embed secrets in source code.
• Document the output schema explicitly: 'Returns {content: [{type: "text", text: string}]} where text is the transaction hash. Include transaction hash in response so agents can track the transfer.'
• Add error handling with recovery guidance: catch invalid addresses, network errors, and rate limits. Return actionable messages like 'Invalid address format. Expected 44-character base58 string.' instead of raw errors.