Skip to main content
Glama

gem_opskrift

Destructive

Save a recipe to your collection by name, replacing any existing entry; store ingredients, tags, notes, and a link for later use.

Instructions

Gem en ret i jeres opskriftssamling. Findes navnet, erstattes den. Brug link til nemlig-opskrifter (hent_opskrift kan så give varerne). Ingredienser er fri tekst, fx "500 g hakket oksekød". Gem kun det, brugeren beder om.

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": {
      "navn": "<navn>"
    },
    "name": "gem_opskrift"
  }
}

Input Schema

NameRequiredDescriptionDefault
linkNo
navnYes
noteNo
tagsNo
personerNo
ingredienserNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.37.0

TDQS

A3.9/5.0
Behavior4/5

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

The overwrite semantics ("if the name exists, it is replaced") are exactly the kind of behavioural detail annotations cannot express, and they align with destructiveHint=true. It also clarifies that ingredients are free text with a concrete format example. Minor tension: a replace-by-name upsert reads as idempotent, while idempotentHint is false; no auth or return behaviour is described.

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

Conciseness5/5

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

Four short sentences, front-loaded with the action and immediately followed by the replace rule, the link usage and the input format. No filler or repetition; every sentence contributes a distinct constraint.

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?

As a write tool with annotations covering the safety profile and no output schema, the description covers the essentials (what is written, overwrite behaviour, link format). It is still incomplete for a 6-parameter tool: three parameters are undocumented anywhere, and nothing says what the tool returns after a successful save.

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

Parameters3/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 carry all parameter meaning, and it covers only about half: navn (implicitly, via the replace rule), link (nemlig recipe URLs) and ingredienser (free-text strings with an example). note, tags and personer are never mentioned, so an agent gets no signal on what belongs in them.

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?

Specific verb plus resource: "Gem en ret i jeres opskriftssamling" tells the agent this is a save/write of a recipe. It also states the collision rule ("Findes navnet, erstattes den") and points to hent_opskrift as the retrieval counterpart, so it is distinguishable from the sibling tools. It stops just short of an explicit one-line contrast with the other write tools (gem_madplan, fjern_opskrift).

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 a real routing rule: use the link field for nemlig recipes, after which hent_opskrift can resolve the goods. It also adds a scope constraint for agents ("Gem kun det, brugeren beder om") that discourages over-collecting user data. No explicit when-not-to-use or prerequisite guidance, but the context is clear.

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