Skillz provides 14 tools with explicit schemas and descriptions. Most tools have clear action verbs (build_tool, register_script, delete_tool, call_tool, create_pipeline, import_tool). However, several tools exhibit significant definition quality issues: (1) Descriptions are often terse and lack context for when to use the tool instead of alternatives. For example, 'List all available tools' (list_tools) is only 26 chars and provides no guidance on when an agent should call it. (2) Parameter descriptions are present but inconsistent in depth, some tools like register_script have extensive guidance (e.g., 'CRITICAL for Python: Use sys.stdin.readline() NOT sys.stdin.read()') while others like explore_skill lack prerequisite context. (3) Output schemas are not documented in the source, only input schemas are visible. (4) Error handling guidance is absent, tools return results or failures, but descriptions do not explain recovery paths. (5) Some high-risk tools (build_tool, execute_code, delete_tool) lack clear confirmation/dry-run patterns despite their destructive potential. The tool naming is strong (verb-leading, clear intent), and input parameters are well-constrained with enums and type definitions where applicable. Baseline analysis: 14/14 tools have descriptions (100%, exceeds 94% A+ baseline); all have JSON Schema input definitions; but output schemas and error guidance are absent. Tool names average ~15 chars and start with action verbs, meeting naming baselines.

• Document output schemas for all 14 tools. Add 'output_schema' declarations in tool registrations and summarize expected response fields in descriptions. Example: 'Returns {success: boolean, tool_id: string, created_at: ISO8601}'.
• Add confirmation/dry-run support to destructive tools. For delete_tool and delete_memory, add a 'confirm' boolean parameter defaulting to false; when false, return a preview of what would be deleted. For execute_code, add a dry_run parameter that parses code and reports syntax errors without execution.
• Expand error guidance. Rewrite descriptions for call_tool, execute_code, import_tool, and build_tool to include: (1) What errors can occur (invalid tool name, execution timeout, syntax error). (2) Recovery hints (e.g., 'If the tool is not found, call list_tools first'). (3) Retryability (e.g., 'Execution timeouts are retryable; permission errors are not').
• Standardize parameter documentation depth. Audit all 14 tools and ensure every parameter includes: (1) What it controls. (2) Valid values or constraints (range, enum, pattern). (3) When it is required vs. optional. (4) Dependency on other parameters if applicable. Match the depth shown in register_script examples.
• Expand discovery tool descriptions to 150 - 250 characters. list_tools should explain when to call it before other operations (e.g., 'Call this at the start to discover available tools, or after registering new tools to confirm they are visible'). explore_skill should explain what 'resources and capabilities' means.

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

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