This governance proxy exposes 5 tools with significant definition gaps. Tool schemas are present but parameter descriptions are minimal or absent. slack_send_message and github_create_issue have basic descriptions but lack detail on when to use them vs alternatives. demo_send_message and demo_refund are demo tools with trivial descriptions. No tool documents output schemas, error recovery paths, or idempotency guarantees. The proxy's core value (governance/approval workflow) is not reflected in tool definitions, agents cannot infer that some calls will be held for review. Parameter descriptions are sparse: 'Channel ID or name' is vague (what format?), 'Issue body (markdown)' lacks length/content constraints. No tool declares permissions, audit requirements, or risk levels in the schema itself.

• Add detailed parameter descriptions: 'channel: Slack channel ID (e.g., C1234567) or name (e.g., #general). Names are case-insensitive.' Include format, valid ranges, and examples as constraints, not prose.
• Document output schemas for all tools. E.g., slack_send_message should return {message_id, channel_id, timestamp, thread_ts?}. This enables agents to chain calls and extract IDs for follow-ups.
• Add error recovery guidance: 'If channel not found, try search_channels() with a partial name. If permission denied, verify the bot has write:channels scope.'
• Annotate tools with destructiveHint (github_close_issue, demo_refund) and idempotentHint (github_create_issue if it deduplicates by title). Use MCP tool annotations to signal governance requirements.
• Expand demo tool descriptions to explain their purpose: 'demo_send_message: Simulates Slack message sending without calling the real API. Use for testing governance policies. Returns mock response with tool name and arguments.'

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

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