Skip to main content
Glama

conduyt_update_tag

Rename an existing tag or change its color by supplying the tag ID and a new name or hex color code.

Instructions

Rename a tag or change its color.

Input Schema

NameRequiredDescriptionDefault
idYesTag UUID
nameNoNew tag name
colorNoNew hex color code

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv4.71.0

TDQS

C2.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 does not disclose permission requirements, whether name uniqueness is enforced, whether the update is partial (name only, color only, or both), or what happens to existing tag assignments on contacts/deals after a rename.

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 short sentence with the operation and its two effects front-loaded; no filler. It is arguably under-specified for a mutation tool with no annotations, but nothing present is wasted.

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

Completeness2/5

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

For a mutation tool with zero annotations and no output schema, the description is thin: no error behavior, no required-permission context, no confirmation of whether the call returns the updated tag. The 100% schema coverage covers inputs but not the behavioral picture an agent needs before mutating data.

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 100%, so id, name, and color are already fully documented in the schema. The description adds nothing beyond restating that name and color are the editable fields, and it never mentions the required id parameter. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb (rename/change) and resource (tag) plus the two mutable attributes, so the agent knows exactly what operation this performs. It does not name or differentiate itself from siblings like conduyt_create_tag, conduyt_merge_tags, or conduyt_delete_tag, leaving that separation to the tool name alone.

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/when-not-to-use guidance and no mention of alternatives such as merge_tags (for consolidating tags) or create_tag. The description only implies usage by naming the fields it edits.

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