SafetyNet MCP server has significant definition quality gaps. 14 tools are registered with basic descriptions (10-80 chars), but most lack depth and actionable guidance. Input schemas are present for 8/14 tools but incomplete: 6 tools (read_contract_state, withdraw_liquidity, transfer_cspr, and 3 others) have NO visible input schema in the source. Parameter descriptions are minimal or absent. Output schemas are undocumented. Error handling is not evident in tool definitions. Naming is verb-forward (read_*, swap_*, stake_*) but descriptions are too terse to guide LLM selection. No tool annotations (readOnlyHint, destructiveHint) despite clear risk levels. Critical write operations (swap_tokens, stake, lend) lack confirmation/dry-run patterns.

• Add complete input schemas for read_contract_state, stake, lend, withdraw_liquidity, transfer_cspr. Include parameter types, descriptions, and constraints (e.g., min/max amounts, enum validators).
• Expand descriptions to 100-200 chars. For each tool, state: WHAT it does, WHEN to use it (vs similar tools), WHAT it returns, and any prerequisites. E.g., 'Stake CSPR tokens to a validator. Requires validator address (hex format) and amount (min 1 CSPR). Returns stake_id for tracking. Non-reversible, use simulate_stake first to estimate rewards.'
• Document output schemas for all tools. Specify field names, types, and units. E.g., read_balance returns {balance_cspr: number (motes), balance_tokens: {symbol: string, amount: number}}.
• Add tool annotations: mark read_* tools with readOnlyHint=true; mark swap_tokens, stake, lend, transfer_cspr with destructiveHint=true; mark idempotent operations with idempotentHint=true.
• Implement dry-run or confirmation patterns for write operations. E.g., swap_tokens should accept a 'dry_run' parameter that returns expected output without executing, or require explicit 'confirm=true' after simulation.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry