Skip to main content
Glama

update_agent

Destructive

Update an existing Convocore agent (PATCH). For large prompt edits prefer patch_agent_prompt. Main prompt: use systemPrompt → start node instructions. NEVER send vg_instructions or vg_systemPrompt. Do NOT pass nodes[] unless you are changing nodes — omit it for title/UI/funnel/model updates. Partial nodes[] are GET-merged by id; a toolsIds-only start node cannot blank instructions, and toolsIds in a patch are only ever ADDED (tools attached on the dashboard are kept). To detach tools pass allowRemoveTools=true. Lead notify: funnelConfig (steps + notificationRules.recipients). UI Engine: vg_enableUIEngine* + vg_uiEngineChannelConfig. ownerID is read-only.

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": {
      "agentId": "<agentId>"
    },
    "name": "update_agent"
  }
}

Input Schema

NameRequiredDescriptionDefault
lightNoUpdated light mode setting
nodesNoNode patch. MCP merges onto the current graph by node id so partial updates (e.g. toolsIds) cannot blank nodes[0].instructions. Prefer systemPrompt for prompt writes.
themeNoUpdated theme
titleNoUpdated title
agentIdYesThe unique identifier of the agent to update
disabledNoUpdated disabled status
descriptionNoUpdated description
voiceConfigNoAgent voiceConfig for voice-capable agents. Integrations/API keys generally live at workspace/org level; this config selects providers, models, voices, and call behavior for the agent.
enableVertexNoUpdated Vertex AI setting
funnelConfigNoAI Funnel & Lead Scoring (built-in). Use this instead of a custom HTTP “notify sales team” webhook. enabled + steps (id/name/description/condition/points/category) + notificationRules (type score_threshold|steps_completed|data_collected, recipients emails, cooldownStrategy). Runtime scores the conversation and emails recipients when a rule fires.
systemPromptNoReplace main prompt → nodes[0].instructions (enableNodes forced true). Prefer patch_agent_prompt for surgical edits.
autoOpenWidgetNoUpdated auto-open widget setting
additionalConfigNoEvery other agent field the API accepts, typed from the main agent schema. Send only what changes: nested objects (nodesSettings, vg_kb_llm, ui…) are deep-merged into the current value, so existing settings are kept. Do not put the main prompt here (use systemPrompt / patch_agent_prompt). Unknown fields are rejected up front with the valid names.
vg_enableUIEngineNoMASTER SWITCH for UI Engine. When true the agent can emit structured UI (text, choice/buttons, visual, cardV2, carousel, iFrame, and — if their flags are on — form/input, invoice, calendarBooking). Call get_ui_engine_spec for payloads. Prefer enabling this before toggling individual elements.
leadCollectionRulesNoWhen to persist a CRM lead. Default: collect when email, phone, or phone_number is present.
vg_maxImagesPerCardNoMax images per cardV2/carousel card: 1 = imageUrl only; 2–3 allow images[] gallery. Omit for platform default.
vg_enableUIEngineFormsNoAllow form + input UI Engine elements (typically web). Set true to let the agent collect structured fields. Also set vg_uiEngineChannelConfig.web.form / .input as needed.
vg_enableUIEngineInvoiceNoAllow invoice card UI Engine elements (web). Use with vg_uiEngineInvoiceConfig for click notifications.
vg_uiEngineChannelConfigNoPer-channel allowlist of which UI Engine elements the agent may show. Channels: web, whatsapp, instagram, messenger, telegram. Each channel is an object of type→boolean (choice, visual, cardV2, carousel, iFrame, form, input, invoice, calendarBooking, file, VoiceNote, locationRequest, ctaUrl). Missing type = enabled. Example: { "web": { "choice": true, "cardV2": true, "form": true, "invoice": false }, "whatsapp": { "choice": true, "cardV2": true, "form": false } }. Forms/invoice/calendar still need their global vg_enableUIEngine* flags.
vg_uiEngineInvoiceConfigNoInvoice card notification settings.
vg_uiEngineCalendarConfigNoCalendar booking widget config (Google Calendar connection + booking rules).
vg_uiEngineFormNotifyConfigNoEmail notify settings when forms/inputs are submitted.
vg_enableUIEngineCalendarBookingNoAllow interactive calendar booking widget (web). Requires Google Calendar connectionIds in vg_uiEngineCalendarConfig.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already mark this as a destructive, non-idempotent write, and the description adds important mutation semantics: partial nodes are GET-merged by id, toolsIds can only be added unless allowRemoveTools is passed, and ownerID is read-only. It does not discuss auth requirements or rate limits, but it meaningfully exceeds what the annotations provide.

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?

The description is dense but front-loads the core operation and the most important sibling alternative. Subsequent sentences are terse and mostly earn their place by preventing common errors, though the heavy use of fragments and arrows makes it harder to scan than ideal.

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 23-parameter nested mutation tool with no output schema, the description covers the highest-risk pitfalls: prompt routing, node merging, tool detachment, legacy field avoidance, and UI Engine configuration. It does not mention permissions or pre-update reading via get_agent, but it is otherwise complete enough for safe invocation.

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, but the description adds real semantic guidance: systemPrompt maps to nodes[0].instructions, nodes should be omitted unless changing graph structure, funnelConfig covers lead notification, and vg_* legacy fields must not be sent. The mention of allowRemoveTools is helpful, though it is not visible in the provided schema and could confuse an agent validating parameters.

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?

The description states a specific verb and resource: update an existing Convocore agent via PATCH. It also distinguishes the tool from the prompt-editing sibling by naming patch_agent_prompt for large prompt edits, so an agent can select it without opening 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?

It gives explicit routing guidance: prefer patch_agent_prompt for large prompt edits, use systemPrompt for the main prompt, and never send vg_instructions or vg_systemPrompt. It also states when to omit nodes and when allowRemoveTools is required, covering both use and avoidance conditions.

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