Skip to main content
Glama

Edit Tracker queue trigger

tracker_triggers_update
Idempotent

Edit a queue trigger's name, active state, order, actions, or conditions; only supplied fields change. Use trigger ID and optional version to prevent concurrent edits.

Instructions

Edit a queue trigger; only the fields set in body are changed.

Get trigger_id from triggers_get / the queue settings. Pass version to guard against concurrent edits (optimistic locking).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesFields to change; unset ones stay.
versionNoCurrent version of the object (optimistic lock), from its get/list tool.
queue_idYesQueue key (case-sensitive, e.g. TEST) or numeric queue id.
trigger_idYesNumeric trigger id, from ``triggers_list``.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.67.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover safety (idempotentHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description still adds real value beyond them: partial-update semantics and optimistic-locking behavior via version. No return-value or permission details, but the mutation model is well disclosed.

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?

Two short sentences, front-loaded with the core behavior and then the prerequisites. Every clause earns its place with no redundancy.

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

Completeness4/5

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

For a 4-param mutation tool with full schema coverage, no output schema, and safety annotations, the description covers the essentials: partial update semantics, ID sourcing, and concurrency control. It could note permissions or effects on unlisted fields but is otherwise complete.

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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the source of trigger_id and the concurrency purpose of version (optimistic locking), which the schema only labels generically as a lock field.

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 and resource ('Edit a queue trigger') and immediately clarifies the PATCH semantics ('only the fields set in body are changed'). It is clear what the tool does, though it does not explicitly contrast with sibling writers like tracker_triggers_create.

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

Usage Guidelines4/5

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

Provides clear preconditions: obtain trigger_id from triggers_get or the queue settings, and pass version to guard against concurrent edits. It gives no explicit when-not-to-use guidance or named alternatives, but the context needed to call it correctly is present.

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