Two tools with minimal schema documentation. Both have basic descriptions (50-60 chars, below the 194-char baseline for A+ tools) and input schemas present but severely underdeveloped. nimbus_search has a 'limit' parameter with range constraints (1-20) documented in description, but nimbus_ask lacks any input validation guidance. No output schemas documented for either tool. No error handling guidance, no recovery paths, no parameter type validation hints. Tool names follow verb_noun pattern (search, ask) but descriptions are generic and lack WHEN/WHY context. No evidence of idempotency, pagination support, or composition guidance.

• Expand tool descriptions to 150-250 chars. Include: WHAT (what data does it search/query?), WHEN (when should LLM call this vs the other tool?), WHAT IT RETURNS (structured fields, not free text). Example: 'Search the Nimbus incident index for on-call events, deployments, or ownership records matching a query. Returns up to 20 results with incident_id, title, timestamp, and severity. Use this for discovery; use nimbus_ask for analysis.'
• Document output schemas explicitly. For nimbus_search, specify: { results: [{incident_id, title, timestamp, severity, relevance_score}], total_count, has_more }. For nimbus_ask, specify: { answer: string, sources: [{incident_id, title}], confidence }.
• Add error handling guidance to both tools. Example: 'If no results found, try a broader query or use nimbus_ask to explore related incidents. If ask fails with timeout, retry with a shorter question.'
• For nimbus_search, document the 'limit' parameter constraint more formally: 'Maximum results to return (1-20, default 8). Larger limits may slow response; use pagination for exhaustive searches.'
• Add idempotency and composition hints. Example: 'nimbus_search returns incident_id; pass this to nimbus_ask for deeper analysis. Both tools are read-only and safe to retry.'