Single tool 'goose-run' has a basic schema with 4 parameters (name, prompt, instruction, repo), all with type and description. However, the tool description is minimal (11 chars: 'Run a goose agent'), falling well below the 34-char baseline for p10. No output schema is documented, the tool returns text content but LLMs cannot predict structure. Error handling returns generic error messages without recovery guidance. The tool combines multiple concerns (agent initialization, GitHub integration, execution) into one operation, violating single-responsibility. No idempotency guarantees, no pagination, no structured output schema. Parameter descriptions are terse (e.g., 'goose agent name' lacks context on what a 'goose agent' is or how to name one). The tool name 'goose-run' is generic and does not clearly convey the action, 'execute_goose_agent' or 'run_code_analysis_agent' would be clearer.

• Expand tool description to 50-150 characters explaining: 'Execute a Goose code analysis agent on a GitHub repository. Provide a prompt describing the task (e.g., "find all TODO comments") and optionally an instruction to guide the agent. Returns analysis results as structured JSON.'
• Document output schema: 'Returns {status: string, output: string, errors: [string], execution_time_ms: number}' so LLMs know what fields to expect.
• Add error recovery guidance: Instead of 'OPENROUTER_API_KEY is not set', return 'Missing OPENROUTER_API_KEY environment variable. Set it before starting the server: export OPENROUTER_API_KEY=<your-key>'
• Clarify parameter relationships: Add to 'instruction' description: 'Optional. If provided, guides the agent behavior. If omitted, the agent infers behavior from the prompt alone.'
• Rename tool to 'execute_code_analysis_agent' or 'run_repository_analysis' to make the action and domain explicit.

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

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