Gum exposes 6 meta-tools that act as dispatchers to a dynamic catalog. While schemas are present with type definitions, descriptions are severely underdeveloped. Tool names are generic (read, write, destructive, code) and do not follow verb_noun conventions. Parameters like 'op_id' and 'args' are opaque and force LLMs to understand a two-level indirection (tool → catalog operation). No output schemas are documented. Error handling and recovery guidance are absent. The 'gum.code' tool accepts arbitrary Risor scripts, creating injection risks. Overall, this is a framework for exposing operations, not a well-designed agent tool interface.

• Rename tools to follow verb_noun convention: gum.read → gum.invoke_read_operation, gum.write → gum.invoke_write_operation, gum.code → gum.execute_script. Or expose individual catalog operations as first-class tools (e.g., gum.list_users, gum.create_ticket) instead of a generic dispatcher.
• Expand descriptions to 100-200 chars. Example: 'gum.read: Execute a read-only catalog operation. Use this to fetch data (users, tickets, messages). First call gum.search_apis to discover available operations, then pass the op_id here.'
• Document output schemas for each tool. Specify what fields are returned (e.g., does gum.read return {result, op_id, metadata}?) so LLMs can chain calls.
• Add error handling guidance. Describe what errors are retryable (network timeout) vs user-fixable (invalid op_id) vs fatal (permission denied). Include recovery hints.
• For gum.code, document the Risor sandbox constraints, allowed modules, and timeout. Validate scripts for obvious injection patterns (shell metacharacters, file paths) before execution.

Inferred effective spec: 2025-06-18+.

• Relies on Roots (deprecated) - pass files/dirs via tool parameters, resource URIs, or configuration