The server defines 12 tools with visible input schemas (Zod validation) and descriptions. Naming follows verb_noun conventions mostly (ask_bitcoin, generate_image, wot_score). Descriptions range from 100-300 chars, meeting the 10-1024 baseline, and explain the cost (sats) and operation clearly. However, all tools expose a 'payment_hash' parameter which violates secret-injection patterns, payment authentication should be server-side via Authorization headers, not user-supplied parameters. Parameter descriptions are adequate but could be more precise about format (e.g., 'hex format' is mentioned for pubkeys but not validated). Output schemas are NOT documented, the code returns text via formatL402() helper, but the actual response structure from the backend APIs is never described. This forces LLMs to infer structure from error handling code. Error handling leverages formatL402() for payment prompts, which is good for UX but the recovery pattern is manual (user pays, retries with hash) rather than automated. Tool composition is weak: no batch variants, no chaining IDs in responses documented, and several tools operate on the same Nostr graph but don't reference each other.

• Move payment_hash from tool parameters to server-side Authorization header injection. Implement a middleware that accepts an Authorization: L402 <hash> header and injects it into fetch() calls. Never expose auth tokens in parameter lists.
• Document the output schema for each tool. For ask_bitcoin: does the response include { result: string, reasoning: string, model: string }? For wot_score: { score: number, rank: number, percentile: number, followers: number }? Include examples in JSDoc comments above each tool definition.
• Add pagination parameters (limit, offset/cursor) to tools returning lists. Update wot_score, wot_follow_quality, wot_trust_circle, wot_anomalies, wot_compare_providers to accept optional limit (1-100, default 50) and cursor parameters. Document in descriptions: 'Returns up to 50 results per request.'
• Add Zod pattern validation for pubkey parameters. Change z.string() to z.string().regex(/^[a-f0-9]{64}$/).describe('Nostr public key (64 hex chars)') for all wot_* tools that accept pubkeys. This enables client-side validation and LLM self-correction.
• Add error classification to formatL402(). Distinguish between payment_required (retryable), rate_limit (backoff), invalid_input (fix params), and service_error (non-retryable). Return structured error objects with status, message, and nextSteps guidance.
• Add tool relationship metadata. Create a JSDoc comment above the wot_* tools describing their relationships: 'wot_score gives a trust rank; wot_sybil_check assesses authenticity; wot_trust_path reveals connections. Call sybil_check first if you suspect a fake account.'