Daemoon exposes 22 tools across 9 cloud providers with consistent naming (verb_noun pattern) and structured schemas. Most tools have descriptions and input schemas present. However, many parameter descriptions are minimal or missing, output schemas are undocumented, and error handling lacks recovery guidance. Tool descriptions average ~60 chars (below the 194-char baseline for A+ tools). No tool annotations (readOnlyHint/destructiveHint) despite clear risk stratification. Composition is sound, tools chain well via ID returns, but descriptions don't guide LLM selection between similar tools (e.g., list_projects appears 3 times across providers).

• Add output schema documentation to every tool. Example: 'Returns: {type: object, properties: {id: string, name: string, created_at: ISO8601}}'. This enables LLMs to plan downstream calls.
• Annotate all WRITE tools with destructiveHint=true and READ tools with readOnlyHint=true in the tool definition. Agents need to know which operations are reversible.
• Expand tool descriptions to 50 - 150 chars. Current descriptions like 'List my zones (domains) registered with Cloudflare' are too terse. Add: when to call it, what it returns, and how it differs from similar tools.
• Add recovery guidance to error responses. Instead of 'Error: Invalid project ID', return 'Invalid project ID. Call gcp.list_projects() to see available IDs, or check the GCP console.'
• Prefix list_* tools with provider name in description to disambiguate. E.g., 'List GCP projects' vs 'List Supabase projects' so LLMs can distinguish them without provider context.

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

• Relies on Sampling (deprecated) - integrate directly with the LLM provider API