This is a thin-client proxy to a hosted DeepMap service. Tool schemas are present and properly structured with JSON Schema, but descriptions lack LLM-optimization guidance and parameter descriptions are sparse or missing. Most tools have 2-3 required parameters (lat/lon) but lack descriptions for optional parameters like depth_m, region, horizon_days, radius_km, and type. Error handling is absent, no guidance on what failures mean or how to recover. The server mirrors a hosted endpoint, which is architecturally sound, but the published client does not add value beyond proxying; it does not enrich schemas or add recovery hints. Naming is reasonable (verb_noun style: water_availability, seismic_hazard, ground_stability) but some names are domain-specific and could be clearer (e.g., 'verify' is vague, verify_claim_hash would be better). Output schemas are not documented in the code.

• Add descriptions to all optional parameters. For depth_m, specify units (meters) and valid range (e.g., 0 - 10000). For region, list valid values or link to a discovery tool. For horizon_days, specify range (e.g., 1 - 365).
• Document output schemas for all tools. Add a 'returns' section to each tool description or a separate schema document. Example: 'Returns {water_trend: string, confidence: number, atlas_indication?: string}'.
• Wrap the _remote() function with error handling that categorizes failures (retryable, user-fixable, fatal) and returns actionable guidance. Example: 'API key invalid. Check DEEPMAP_API_KEY environment variable.' instead of raw HTTP 401.
• Rename 'verify' to 'verify_claim_hash' and simplify descriptions to 50 - 150 chars. Remove jargon or define it inline. Example: 'Verify a claim hash against the Bitcoin-anchored ledger. Returns true/false and the anchor timestamp.'
• Add pagination support to list_nulls and check_hypothesis. Document limit parameter (default 20, max 100) and return a total_count or next_cursor so agents can iterate over large result sets without exhausting context.