create_recipes_by_slug_imageCreate a recipe by scraping an image URL and linking it to a specified slug. Optionally include tags and categories to organize the recipe within Mealie.
Scrape Image Url
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| slug | Yes | ||
| includeTags | No | ||
| accept-language | No | ||
| includeCategories | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v3.23.1Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "type": "object"
+}v3.20.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The phrase 'Scrape Image Url' hints that the tool fetches an image from a URL, but it never discloses the actual side effect: that a recipe image is created or replaced. With no annotations, the description fails to convey mutation, network behavior, or overwrite semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three words is not conciseness; it is under-specification. There is no structured information, no rationale, and no detail to help an agent call the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with five parameters, no annotations, and no parameter descriptions, the description is far too incomplete. An agent cannot determine the role of each parameter, the operation's outcome, or the difference from sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning for any of the five parameters. 'Image Url' loosely implies the url parameter, but slug, includeTags, accept-language, and includeCategories are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Scrape Image Url' gives a vague verb and resource but never explicitly states that it creates or updates a recipe's image. It does not differentiate this create tool from sibling update_recipes_by_slug_image or delete_recipes_by_slug_image.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided for when to use this tool versus any of the many siblings. There is no mention of alternatives, prerequisites, or conditions like whether the recipe must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.