Single tool 'pantry' has a detailed description (>1000 chars) but violates naming conventions (generic verb 'pantry' instead of action-specific like 'run_recipe' or 'manage_recipe'). Input schema is present with proper types and enums, but parameter descriptions are minimal or missing for several fields ('input', 'recipe', 'guard'). Output schema is not documented. The tool combines four distinct actions (list/get/run/push) into one, violating single-responsibility principle. Security warnings are extensive but buried in description rather than surfaced as tool annotations or separate tools.

• Split 'pantry' into four separate tools: list_recipes (scope param), get_recipe (name param), run_recipe (name, input, guard params), push_recipe (recipe, shared params). Each tool has one clear action.
• For each tool, document the output schema explicitly. E.g., list_recipes returns {recipes: [{name, description, visibility, owner}], total_count}. run_recipe returns {output, execution_time_ms, errors}.
• Add descriptions to all parameters: 'input' → 'Input object passed to recipe context (structure depends on recipe definition)', 'recipe' → 'Recipe object with name, code, description, and metadata', 'guard' → 'If true, apply parse-time tripwire to detect obvious escape attempts. Not a sandbox, untrusted recipes require a real isolate.'
• Add destructiveHint: true to run_recipe and push_recipe to signal they modify state. Add readOnlyHint: true to list_recipes and get_recipe.
• Implement confirmation pattern for run_recipe: return {status: 'input_required', message: 'Recipe execution is not sandboxed. Confirm you trust this recipe code before proceeding.', recipe_preview: {name, code_preview}} to require explicit user approval before running untrusted recipes.