Nine tools with inconsistent quality. All have descriptions (positive), but most descriptions are vague, domain-specific jargon-heavy, and lack actionable context for LLM selection. Naming is verb-based but cryptic (resolve_signal, resolve_sparks_dimension, resolve_member). Input schemas present but minimal, most parameters are bare strings with weak constraints. No output schemas documented. No error handling guidance. Tools read-only (low risk) but descriptions assume deep domain knowledge of CPG protocols, making them hard for general agents to use effectively.

• Rewrite descriptions to explain WHAT the tool does, WHEN to use it, and WHAT the LLM should do with the result. E.g., 'Get metadata for a CPG protocol (ACM-SPARKS, SM-ECO-10060, or ACM-68000). Use this to understand the protocol structure before resolving specific signals or dimensions.' Current descriptions assume domain expertise.
• Document output schemas explicitly. Add a 'returns' field to each tool definition showing the structure of the response. E.g., resolve_signal returns {code: string, state: string, meaning: string, ...}. This lets LLMs plan downstream calls.
• Enhance parameter descriptions with constraints and examples. E.g., resolve_member: 'Member code (2-4 uppercase letters, e.g. FR, AU, MX). Codes are ISO-style country/region identifiers in the SM-ECO-10060 sovereign manifest.'
• Add error recovery guidance. When notFound() is returned, suggest the next step: 'Signal not found. Call list_signals() to see valid codes.' This guides LLM recovery without extra reasoning.
• Rename 'resolve_*' tools to 'get_*' or 'lookup_*' for clarity. 'get_signal' is more intuitive than 'resolve_signal'. If 'resolve' has domain meaning in CPG, document it in the description.