All 4 tools have identical, minimal schemas with only a single required parameter (site_did). Descriptions are present but generic and repetitive across tools. No output schemas documented. No error handling guidance. No parameter validation constraints. Tools lack differentiation in naming and purpose clarity. This is a scaffold/stub implementation with backend pending, tool definitions are placeholder-quality.

• Document output schemas for each tool. E.g., query_hashrate should return {hashrate_th_s: number, pool_accepted_shares: number, variance_window: string}. This enables LLMs to plan downstream calls and extract the right fields.
• Add format/pattern constraint to site_did parameter. Replace 'e.g. did:hive:mos:0x...' with a regex pattern (e.g., '^did:hive:mos:0x[a-fA-F0-9]{40}$') or explicit format declaration. Remove example values from descriptions.
• Differentiate tool descriptions by use case. E.g., 'query_hashrate: Monitor mining performance (TH/s, shares). Call this to track pool productivity.' vs 'query_health: Monitor hardware status (temperature, fans, errors). Call this to detect equipment failures.' This helps LLMs select the right tool.
• Provide mock/stub responses for development. Even if backend is pending, return plausible example data (e.g., {hashrate_th_s: 150.5, pool_accepted_shares: 12000, variance_window: '5m'}) so agents can test tool composition and LLMs can reason about output structure.
• Add error recovery guidance. Instead of bare 503, return: 'Backend not yet live (Q3 2026). To test, use mock data or contact [email protected]. Retryable: yes (check back after Q3 2026).'