Skip to main content
Glama

shared_recipes_create_one

Creates a share token for a recipe, enabling you to share it with others via a link.

Instructions

Create One — Shared: Recipes. Create recipe. [POST /api/shared/recipes] Keywords: shared_recipes_create_one, shared recipes create one, create recipe, add recipe, new recipe, make recipe, write recipe, recipe, recipes, shared recipes, shared, create, add, new, make, write, post, mealie.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.11

TDQS

D1.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It says nothing about what the created object is (a share token), required auth/permissions, whether the share is public, link expiry semantics, or reversibility. "Create recipe" actively obscures the share-token behavior visible in the schema.

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

Conciseness2/5

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

The useful content is one short line; the rest is a keyword spam block of near-synonyms ("add recipe, new recipe, make recipe, write recipe, ... post, mealie") that adds tokens without adding meaning. Structure is front-loaded but bloated.

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

Completeness1/5

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

A mutation tool with no annotations, no output schema, 0% parameter documentation, and a nested request body needs much more than "Create recipe." Nothing tells the agent what will be created, what is required, or what happens on expiry, making correct invocation a guess.

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% for the single nested "body" parameter, and the description adds nothing about recipeId (uuid) or expiresAt (date-time). The agent learns parameter meaning only by reading the $defs, and even then neither field is documented.

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

Purpose2/5

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

"Create recipe" restates the name without stating the specific resource being created — the schema shows a RecipeShareTokenCreate body (recipeId + expiresAt), i.e. a share-token, not a recipe. The "Shared: Recipes" prefix hints at scope but does not distinguish this from sibling creators like recipe_crud_create_one, create_recipe_from_html_or_json, or create_recipe_from_image.

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?

No when-to-use, when-not-to-use, or alternative routing is given. The only routing-style content is a keyword blob ("create, add, new, make, write, post") that names no sibling and gives the agent no basis to choose this tool over the many other recipe-creation tools.

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