Skip to main content
Glama
djwmarcx

Better Mealie MCP

Get Media Recipes By Recipe Images Timeline By Timeline

get_media_recipes_by_recipe_images_timeline_by_timeline

Retrieve a static image from a recipe's timeline event by providing the recipe ID, timeline event ID, and file name.

Instructions

Takes in a recipe id and event timeline id, returns the static image. This route is proxied in the docker image and should not hit the API in production

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
file_nameYes
recipe_idYes
timeline_event_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.20.1

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the behavioral burden. It does disclose that the route is proxied in the Docker image and should not hit the API in production, which is useful context, but it does not mention auth, response format, or other request behaviors.

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?

Two sentences with no filler; the main behavior and the proxy caveat are both present. The phrasing is compact, though slightly ambiguous about what 'proxied in the docker image' means in practical terms.

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

Completeness3/5

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

For a simple static-image fetch with three required params and no output schema, the description provides the return type and two key identifiers. However, it under-documents file_name and does not differentiate this route from sibling media routes, leaving some gaps.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. It explains recipe_id and timeline_event_id as identifiers, but completely omits the required file_name parameter. The enum in the schema helps, but the description does not clarify how file_name relates to the returned image.

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?

The description states a specific action: take a recipe id and timeline event id and return the static image. It clearly identifies the resource as timeline-related media, which helps distinguish it from generic sibling media routes, though it does not explicitly name an alternative.

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

Usage Guidelines2/5

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

The only usage guidance is the proxy/production caveat, which is a routing constraint rather than a clear when-to-use instruction. No explicit alternatives or conditions are given to help an agent choose between this and similar media endpoints.

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

Deploy Server

Other Tools