Selene exhibits pervasive definition quality deficiencies across all 19 tools. While tool names follow basic verb-noun conventions and descriptions exist, they are severely underdeveloped. Most descriptions lack actionable detail about when to use each tool, what it returns, prerequisites, and error recovery paths. Input schemas are present but parameter descriptions are minimal or absent entirely. Output schemas are not documented. Parameter constraints (enums, ranges, formats) are largely missing. No evidence of idempotency guarantees, error categorization, or LLM-friendly recovery guidance. The tool definitions appear to be skeletal wrappers around internal functions rather than LLM-optimized interfaces. For example, 'editFile' has a description 'Edit specific sections of a file' but does not explain the format of the 'edits' array parameter, what modifications are supported, or how failures are reported. 'executeCommand' accepts 'args' as an array with description 'Command arguments' but provides no guidance on escaping, injection prevention, or timeout behavior. 'skill' is entirely generic ('Execute a registered skill or plugin capability') with no indication of how to discover available skills or what parameters they expect. These gaps force LLMs to reason from minimal information, increasing error rates and wasted tool calls.

• For every parameter, add a 2-3 sentence description explaining: (1) what the parameter controls, (2) valid values/format/constraints (e.g., 'unix file path', 'ISO 8601 date', 'enum: create|update|delete'), (3) any dependencies on other parameters. Reference the constraint checker pattern.
• Document the output schema for every tool in its description. Example: 'Returns {success: boolean, fileSize: number, content?: string}. Use the fileSize field to check if the file is empty before processing.'
• Add enums to tools with bounded action spaces. Convert 'workspace' action parameter to explicit enum: 'action (one of: create, delete, configure, list, export)'. Document what each action does.
• For destructive tools (writeFile, editFile, patchFile, executeCommand, bash, workspace delete), add: (1) explicit statement 'This operation is irreversible', (2) guidance on when to request confirmation vs. proceeding, (3) example of what a failed state looks like.
• Add error classification to tool descriptions. Example for executeCommand: 'Returns error if: (1) command not found (user-fixable: suggest alternatives), (2) timeout after 30s (retryable: may be slow system), (3) exit code >0 (depends on command: may be expected behavior, check stdout).'
• For bash and executeCommand, document injection prevention. Example: 'Command is executed via shell; use args array to pass untrusted user input to avoid shell injection. Do not interpolate user strings into the command parameter.'
• Rename generic 'action' and 'input' parameters to specific names. Examples: 'workspace' → 'workspace_action' with enum; 'skill' input → 'skill_parameters' (object with documented structure); 'askFollowupQuestion' questions → 'question_list' and separate 'choice_options' parameter.