Three tools with inconsistent quality. triage_open_cases and draft_case_from_incident have minimal descriptions (under 100 chars) that lack WHEN/WHY context. case_resource is a resource, not a tool, and descriptions don't explain prerequisites or expected output structure. All three lack documented return schemas. Parameters have types but descriptions are sparse. No error handling guidance. Naming is verb-forward but descriptions fail the LLM-optimization bar (50-200 chars, actionable context).

• Expand triage_open_cases description to 100-200 chars: 'Retrieve and prioritize all open support cases across specified projects/organizations. Returns case summaries sorted by severity and age. Call this first to see what needs attention, then use draft_case_from_incident or case_resource for details.'
• Document output schema for each tool. E.g., triage_open_cases returns [{case_id, title, severity, created_at, last_updated}]. This enables LLMs to chain calls and extract IDs for follow-ups.
• Add format/constraint details to parameters. E.g., 'parents: array of Google Cloud project IDs (format: my-project-123) or organization IDs (format: 123456789). If omitted, uses GOOGLE_CLOUD_SUPPORT_MCP_PARENTS env var.'
• Add error handling guidance: 'If scope is invalid, returns error with available scopes. If user lacks permission, returns 403 with required IAM roles. Retry with correct scope or ask user to grant permissions.'
• Clarify case_resource: is it a resource URI handler (for MCP resource protocol) or a callable tool? If callable, register it as a tool with explicit input schema and output documentation.

Inferred effective spec: 2026-07-28+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry