Skip to main content
Glama
thenavidm

Kit MCP Server

by thenavidm
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Update tag name

update_tag_name

Rename a tag in your Kit account using its ID and new name. Updates account configuration to keep subscriber segments accurate.

Instructions

Update tag name. Changes account configuration.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
tag_idYesPositive tag id.
accountNoNamed private account from KIT_ACCOUNTS. Defaults to KIT_DEFAULT_ACCOUNT or the first configured account.
payloadNoComplete JSON body instead of individual body flags. Supports nullable fields and nested bulk structures. Cannot be combined with body flags or payload_file.
payload_fileNoLocal JSON request body file, at most 5 MB. Contents are validated before the API call and are never logged.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.0.0
    • removedInput schema / properties / confirm
      Removed value: -{
-  "description": "Must be true for audience/delivery changes, publishing, destructive operations and signing-secret changes. Use only for an action requested by the user.",
-  "type": "boolean"
-}
  2. First observedv2.0.1

TDQS

C2.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false, idempotentHint=false, and openWorldHint=true. The description's only added behavioral claim is 'Changes account configuration,' which is vague and does not disclose what specifically changes, whether the change is reversible, what permissions are required, or any rate limits. It adds little beyond the structured safety hints.

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

Conciseness3/5

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

The description is short and front-loads the core action in the first sentence. However, the second sentence, 'Changes account configuration,' is vague filler that does not earn its place and could mislead. It is concise but not well-structured enough for a higher score.

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 5 parameters, a nested payload object, and no output schema, the description is too thin. It does not explain how individual body flags interact with payload or payload_file, does not mention account selection, and does not clarify the scope of the update. The structured fields carry most of the burden, leaving the description incomplete.

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 80%, so the schema already documents most parameters (tag_id, account, payload, payload_file). The description adds no parameter-level meaning, but per the rubric a baseline of 3 is appropriate when schema coverage is high and the description does not compensate further.

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 first sentence gives a specific verb and resource: 'Update tag name.' It is clear what the tool does, but it does not differentiate itself from sibling tools like create_tag or bulk_create_tags. The second sentence, 'Changes account configuration,' is vague and does not sharpen the purpose.

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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention create_tag, bulk_create_tags, or any other tag-related sibling, nor does it state prerequisites or exclusions. The agent is left to infer usage from the name alone.

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