addy-mcp

update_label

Idempotent

Rename a label or change its colour using its label ID to keep alias categories organized and current.

Instructions

Rename a label or change its colour.

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": {
      "label_id": "<label_id>"
    },
    "name": "update_label"
  }
}

Input Schema

Name	Required	Description
`name`	No
`colour`	No	#06b6d4 cyan, #22c55e green, #eab308 yellow, #f97316 orange, #ef4444 red, #8b5cf6 violet, #64748b slate, #ec4899 pink, #14b8a6 teal, #3b82f6 blue
`label_id`	Yes	The id (UUID) of the item

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.2Nov 12, 2026

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false. The description adds value by delimiting the mutable surface to exactly name and colour, implying other label attributes are untouched. It does not explain partial-update semantics (what happens when one field is omitted) or whether renaming is reversible or requires uniqueness.

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?

A single front-loaded sentence with zero filler; the two supported operations are stated first. Its brevity borders on under-specification rather than excess, but nothing is wasted.

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 three-parameter mutation with no output schema, the definition is minimally adequate. It lacks the partial-update behaviour and permission/conflict context an agent would need to invoke it confidently, but annotations cover the safety profile.

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 67% and the colour parameter already carries a full hex-to-name mapping, so the schema does most of the work. The description maps intent to the name and colour parameters but says nothing about label_id being required or about null values meaning 'leave unchanged'.

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 gives a clear verb+resource pair — rename a label, change its colour — so an agent can immediately tell this mutates an existing label rather than creating, deleting, or fetching one. It stops short of explicitly contrasting with siblings like create_label or delete_label, but the action is unambiguous.

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?

There is no when-to-use guidance beyond the implied 'the label already exists' reading. It doesn't say what to do when the label is missing (create_label?), whether renaming to an existing name conflicts, or whether both fields can be changed in one call.

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

Deploy Server