Sandrone has 11 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-100 chars, mostly adequate), and input schemas are present with type definitions. However, output schemas are entirely undocumented, LLMs cannot predict what fields to expect from responses, breaking tool chaining. Parameter descriptions are minimal (5-30 chars), lacking format constraints, ranges, or dependency hints. Error handling is absent from tool definitions. Tool naming follows verb_noun convention (get_, put_, delete_, list_) but lacks clarity on mutual exclusivity and parameter relationships. No evidence of pagination metadata (total_count, next_cursor) in list_resources despite cursor support. Destructive tools (delete_file, delete_subscription) lack confirmation or dry-run patterns.

• Document output schemas for all tools. Specify field names, types, and whether they are always present or conditional. E.g., sandrone_list_resources should document: {items: [{name, kind, display_name, ...}], total_count, next_cursor, has_more}.
• Add enum constraints to parameters with fixed options. E.g., sandrone_get_file 'mode' should be {type: 'string', enum: ['render', 'source', 'spec']}. sandrone_preview_subscription 'type' should enumerate valid subscription types.
• Specify min/max bounds for numeric parameters. E.g., sandrone_list_resources 'limit' should be {type: 'integer', minimum: 1, maximum: 200, default: 50}.
• Add confirmation or dry-run support to destructive tools. E.g., sandrone_delete_file should accept an optional 'confirm' boolean parameter, or offer a separate 'preview_delete_file' tool.
• Document error responses and recovery guidance. E.g., 'If file not found, call sandrone_list_resources to discover available files.' Include error codes and actionable next steps in tool descriptions.