Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
Three tools present with complete schemas and descriptions, but several critical gaps limit quality. All tools have action verbs and non-empty descriptions (delegate_*, which matches pattern:tool naming conventions). However, descriptions lack depth about prerequisites, error conditions, and when to use each tool vs alternatives. Parameter descriptions are present but generic. Output schemas are partially documented in TypeScript types but not exposed in the MCP tool registration (only input schemas visible). Tool composition is problematic: delegate_autopilot and delegate_run overlap significantly, creating ambiguity about which to call. Error handling guidance is absent. The server appears to expose these tools via src/lib/mcp/formatToolContent.ts but the actual tool registration code is not visible in the provided source, only type definitions for output formatting.
Tools (3)
delegate_autopilotwritesource verified67/100
Decide whether delegation is worthwhile, and if so orchestrate one or more specialist Codex sub-agent runs.
delegate_resumewritesource verified65/100
Resume a previous specialist Codex sub-agent run via `codex exec resume`, continuing from an existing thread.
delegate_runwritesource verified67/100
Spawn a new specialist Codex sub-agent run via `codex exec`, writing a run directory with artifacts.
Ambiguous tool composition: delegate_autopilot vs delegate_run both orchestrate specialist agents with nearly identical parameters. LLM cannot disambiguate when to use each. delegate_autopilot's purpose ('decide whether delegation is worthwhile') suggests a decision tool, but it also orchestrates runs like delegate_run does, creating confusion.
Descriptions lack context about when to call each tool. 'Decide whether delegation is worthwhile' does not explain: Is this a planning step? Does it execute immediately? What is the return format? When should I call delegate_run instead? LLM must guess.
Parameter descriptions are generic and lack constraints. 'model' has description 'LLM model to use' but does not specify valid values, format, or examples. 'reasoning_effort' describes purpose but not allowed values. 'skills_mode' enum is present but not explained in description.
delegate_autopilot
Recommendations
Clarify tool composition: Rename or split delegate_autopilot to indicate it is a planning/decision step that returns a plan without executing it. E.g. 'plan_delegation' vs 'delegate_run' (execute). Or merge them with a 'dry_run' boolean parameter to control whether jobs actually execute.
Expand tool descriptions to 100-200 characters explaining: (1) What does the tool do? (2) When to use it vs alternatives? (3) What does success/failure look like? (4) What does it return? Example: 'Spawn a specialist Codex sub-agent to complete a single task. Returns run directory, artifacts, summary, and next steps. Use this for one-off tasks; use delegate_autopilot for multi-step planning.'
Document parameter constraints in descriptions: For 'model', list valid values or point to Codex model list. For 'reasoning_effort', specify enum values (e.g. low|medium|high). For 'cwd', state 'absolute or relative path to working directory; must be readable by the server'.
Add JSON Schema output documentation. Create a 'result' schema field in each tool definition showing the structure of DelegateToolOutput (status, run_dir, summary, deliverables, open_questions, next_actions, artifacts, timing, error). Make it machine-readable so LLMs understand what fields to extract.
Add error handling guidance to descriptions. E.g. 'If status=failed, check error field for details. Common failures: (1) invalid skills → retry with skills_mode=auto; (2) permission denied → check sandbox level; (3) timeout → increase model reasoning_effort or reduce max_skills. Use delegate_resume to continue from a checkpoint.'
Spec posture evidence
Inferred effective spec: 2025-06-18+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Output schemas documented in TypeScript (DelegateToolOutput, AutopilotToolOutput types in formatToolContent.ts) but not exposed as JSON Schema in tool definitions. LLM has no machine-readable specification of what each tool returns.
No error handling guidance. Descriptions do not explain failure modes or recovery steps. If a run fails, what should the LLM do? Retry? Resume with delegate_resume? Parse the error from 'error' field? No guidance given.
Parameter 'cwd' is required (no default) but not validated in descriptions. Expected format: absolute path? Relative to what? Must exist? Can be created? No guidance.
Array parameters (skills, config_overrides) lack item constraints. 'config_overrides' items are strings described as 'TOML format' but no schema/pattern specified. LLM may pass invalid TOML. No example format given.
Parameter interdependencies undocumented. E.g. if skills_mode='explicit', then skills array should be required; if skills_mode='none' or 'auto', skills should be ignored. No documentation of this relationship.
delegate_autopilotdelegate_rundelegate_resume
Document parameter interdependencies. E.g. 'If skills_mode=explicit, then skills array must be provided and non-empty. If skills_mode=auto or none, skills array is ignored.'
Add examples for complex parameters. E.g. config_overrides example: 'Set max_iterations = 5' (TOML syntax). Show one valid config override to guide LLM usage.
Consider consolidating delegate_run and delegate_resume: They have near-identical parameters. Combine into a single 'delegate_task' tool with optional thread_id (if provided, resumes; if null, starts new run). This reduces cognitive load on LLM.
Add idempotent/destructive hints via tool annotations: Mark delegate_run and delegate_autopilot as having side effects (writes to filesystem, spawns processes). Help agents understand retry safety.
Document sandbox modes in parameter description: 'read-only (no file write), workspace-write (modify cwd subtree), danger-full-access (unrestricted). Higher sandbox levels pose security risk; use least-privilege mode.'
Return more structured error messages from tool handler. Current formatToolContent.ts shows error field as string; consider structured {code, message, recovery_hint} so LLM gets actionable guidance.