handle-mcp

fyld_kurv_fra_madplan

Idempotent

Fills an online basket with exact items from an approved meal plan only after explicit user confirmation; it modifies the basket but never orders or pays.

Instructions

Læg PRÆCIS varerne fra en godkendt madplan i butikkens kurv. Ændrer kun kurven. Brug det KUN, når brugeren selv har godkendt: med koden ("OK UGE-4821") eller et kort "bestil"/"ok"/"ja", når planen er den eneste ventende. godkendelse er brugerens egne ord, ordret. Er det ikke en klar godkendelse ("ja, men uden laks"), sker der intet. En plan kan kun bruges én gang. Er kurven ikke tom, stopper den, medmindre brugeren har sagt, at det er i orden (kurven_maa_have_andet=True). Bestiller og betaler ALDRIG: brugeren vælger selv leveringstid og betaler i butikkens app. Vis bagefter kurven og evt. advarsler.

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": {
      "kode": "<kode>",
      "godkendelse": "<godkendelse>"
    },
    "name": "fyld_kurv_fra_madplan"
  }
}

Input Schema

Name	Required	Description	Default
`kode`	Yes
`godkendelse`	Yes
`kurven_maa_have_andet`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.37.0Nov 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Beyond the annotations it discloses the hard limits: a plan can only be used once (consistent with idempotentHint=true), execution halts on a non-empty basket unless the flag is set, and the tool never orders or pays — the user picks delivery and pays in the store app. It also tells the agent to surface the basket and any warnings afterwards, which no structured field conveys.

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?

The action is front-loaded, followed by approval rules, one-time-use and basket-state constraints, then the ordering boundary and post-call instruction — every sentence adds a rule. It is dense but not padded; the only slight muddle is folding the approval example into the sentence about the code.

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 mutation tool with no output schema and no parameter descriptions in the schema, the description covers preconditions, failure behavior, side effects, the no-payment boundary, and what to show the user afterwards. Nothing an agent needs to invoke it correctly appears to be 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 description coverage is 0%, so the description carries the burden: `godkendelse` is defined as the user's verbatim own words and `kurven_maa_have_andet` as the permission to keep existing basket contents. `kode` is only illustrated through the example 'OK UGE-4821' rather than explained (e.g. where the plan code comes from), leaving one parameter's origin implicit.

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

Purpose5/5

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

The opening sentence gives a specific verb and resource ('Læg PRÆCIS varerne fra en godkendt madplan i butikkens kurv') plus a scope constraint ('Ændrer kun kurven'), which separates it from siblings like vis_kurv or saet_antal_i_kurv. An agent can identify the action and its boundary without opening the schema.

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

Usage Guidelines5/5

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

It states exactly when to call (only when the user has personally approved, with the code or a short 'bestil'/'ok'/'ja' and only when the plan is the sole pending one) and when not to (vague or conditional approvals like 'ja, men uden laks' produce no action). The prerequisite of an empty basket and the escape hatch via `kurven_maa_have_andet` are spelled out.

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