Skip to main content
Glama

Update Agent

update_agent

An agent's recurring runs are steered by each trigger's prompt and code; the goal is shared context, not the run script. A goal edit that adds, removes, or changes a recurring step therefore doesn't reach the runs on its own: after updating the goal, read the agent's triggers and bring each affected trigger's prompt or code in line via update_trigger — or confirm the existing triggers already cover the change. Narrowing a live outreach campaign's ICP is the same shape with more surfaces: segment-bound triggers, per-segment templates, and queued-unsent sends stay wired to the dropped segment; follow your channel's outreach skill to reconcile them.

Set priority=True to push this whole campaign's queued sends — email and LinkedIn alike — ahead of your other campaigns'. It starves the others until it drains — that's intended. priority=False clears it. Dict with success status and updated agent details

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalNoNew goal/instructions. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat.
titleNoNew title
statusNoSet to 'active' or 'paused'. Pausing stops the whole agent — every trigger on it.
agent_idYesID of the agent to update
priorityNoTrue to prioritize this campaign's queued sends (email and LinkedIn) over other campaigns; False to clear.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / goal / description
      Previous value: -"New goal/instructions"New value: +"New goal/instructions. Name any outside resource a run reads (a Google Sheet, doc, file, URL) by the identifier its tool takes (the spreadsheet ID and tab, the URL), not only by its title — a later run doesn't see this chat."
  2. Changed4 schema fields changed
    • addedInput schema / properties / agent_id
      Added value: +{
      +  "description": "ID of the agent to update",
      +  "type": "integer"
      +}
    • changedInput schema / properties / status / description
      Previous value: -"Set to 'active' or 'paused'. Pausing stops the whole task — every trigger on it."New value: +"Set to 'active' or 'paused'. Pausing stops the whole agent — every trigger on it."
    • removedInput schema / properties / task_id
      Removed value: -{
      -  "description": "ID of the task to update",
      -  "type": "integer"
      -}
    • changedInput schema / required
      Previous value: -[
      -  "task_id"
      -]New value: +[
      +  "agent_id"
      +]
  3. Added

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint=false/destructiveHint=false. The description adds substantial non-obvious behavior: pausing stops every trigger on the agent, priority=True starves other campaigns until it drains, and goal edits do not propagate to recurring runs without trigger reconciliation. This is exactly the context annotations cannot carry.

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?

Front-loaded with the core action and the 'only provided fields change' rule, and every paragraph covers a distinct surface (goal/trigger drift, outreach reconciliation, priority). It is long and some outreach-campaign material is situational, but it is structured rather than padded.

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

Completeness5/5

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

For a mutation tool with no output schema, the description covers what changes, what doesn't propagate, downstream reconciliation steps, and priority side effects. The <returns> note covers the response, so nothing material is missing.

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 goes beyond it by explaining the side effects of priority (starves others, intended) and the requirement to name outside resources by tool-usable identifiers in the goal. That is real added meaning over the schema text.

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 (update) and resource (agent) and enumerates the exact mutable fields: title, goal, active/paused status, priority. It also differentiates from siblings by routing goal-vs-trigger edits to update_trigger, so an agent can tell it apart without opening other schemas.

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

Usage Guidelines5/5

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

Explicit when-to-use ('Only provided fields are changed'), an interactive-session prerequisite ('Confirm with the user before calling'), and named alternatives with conditions ('bring each affected trigger's prompt or code in line via update_trigger'). Leaves little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources