Skip to main content
Glama
Sign In
Better Mealie MCP

Better Mealie MCP

by djwmarcx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Remote

Create Groups Labels Merge

create_groups_labels_merge

Merges the from_id label into the to_id label, then deletes from_id.

Instructions

Merges the from_id label into the to_id label, then deletes from_id.

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": {
      "fromId": "<fromId>",
      "toId": "<toId>"
    },
    "name": "create_groups_labels_merge"
  }
}

Input Schema

NameRequiredDescriptionDefault
toIdYes
fromIdYes
accept-languageNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv3.29.0

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description does carry the key behavioral fact that from_id is deleted as part of the operation, which is valuable. It omits whether the merge is reversible, whether items previously tagged from_id are reassigned to to_id, and any permission requirements for this mutation.

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?

One sentence, zero filler, and the destructive consequence is front-loaded alongside the merge semantics.

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?

The output schema covers return values, and the description captures the core merge+delete behavior. But for an irreversible mutation with no annotations, it should say what happens to references to the deleted label and what the third parameter does.

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 coverage is 0%, so the description must compensate; it does clarify the direction of the merge (from_id consumed, to_id retained), which is the critical ambiguity in the schema. However, the accept-language parameter and its effect are entirely undocumented, and no ID format hints are given.

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?

States a specific verb (merges) plus the exact resources (from_id label into to_id label) and the post-effect (deletes from_id). This clearly distinguishes it from list/create/update/delete_groups_labels_by_item siblings.

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

Usage Guidelines3/5

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

The word 'merges' implies the use case (consolidating two labels) and implicitly excludes simple renames or deletions, but it never explicitly states when to choose this over update_groups_labels_by_item or delete_groups_labels_by_item, nor any prerequisites.

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