Cookidoo MCP Server

Overview Schema Source Related Servers Discussions Admin

Upload Custom Recipe Image

upload_custom_recipe_image

DestructiveIdempotent

Replace a custom recipe's photo by uploading a local JPEG, PNG, or WebP image file; it is re-encoded as JPEG and stripped of metadata before Cookidoo storage.

Instructions

Set the photo of one of the user's custom recipes from a local image file, replacing the current photo (which is lost). The file is sent to Cookidoo's image storage.

Only files inside the folders listed in the server's COOKIDOO_IMAGE_DIRS setting can be used; .jpg, .jpeg, .png and .webp up to 10 MB. The image is re-encoded as JPEG and all metadata (EXIF, GPS location, camera details) is removed before upload. Only call this with a file the user explicitly chose for this recipe.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "recipe_id": "<recipe_id>",
      "image_path": "<image_path>"
    },
    "name": "upload_custom_recipe_image"
  }
}

Input Schema

Name	Required	Description	Default
`recipe_id`	Yes	The custom recipe ID returned by list_custom_recipes
`image_path`	Yes	Absolute path of the image file

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Nov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the annotations by disclosing the destructive consequence in concrete terms (the current photo "is lost"), a sandboxing rule (paths must be under COOKIDOO_IMAGE_DIRS), format and size limits, and that files are re-encoded to JPEG with EXIF/GPS metadata stripped. This is exactly the kind of detail an agent needs before authorizing a destructive, open-world upload.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the action and its destructive consequence in the first sentence, then layers constraints in two dense paragraphs with no filler. The parenthetical "(which is lost)" is a good example of a short clause carrying real weight rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter destructive write with an output schema and full annotation coverage, every decision point is addressed: consent, path sandboxing, accepted formats, size cap, and post-processing/metadata behavior. Nothing an agent needs in order to invoke this safely is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so both parameters are documented; the description still adds operative constraints the schema does not carry, namely that image_path must live inside a configured COOKIDOO_IMAGE_DIRS folder and must be jpg/jpeg/png/webp under 10 MB. The recipe_id semantics are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ("Set the photo of one of the user's custom recipes from a local image file") and states the replacement semantics. It is immediately clear this writes an image to an existing recipe, though it never explicitly contrasts itself with the sibling upload_custom_recipe, leaving the agent to infer the recipe-vs-image distinction from names.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit selection/authorization rule: "Only call this with a file the user explicitly chose for this recipe," which tells the agent when consent exists and when it does not. It lacks an explicit alternative-action path (e.g., what to do if the recipe already has a photo the user wants kept), so it falls short of full when/when-not coverage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.