Skip to main content
Glama
Moe03

Convocore MCP Server

by Moe03

update_agent

Update an existing Convocore agent’s settings, prompt, nodes, voice, UI, or funnel configuration with partial patches that preserve unchanged fields.

Instructions

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.

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 observedv2.6.17

TDQS

A4.5/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing non-obvious semantics: partial nodes[] are GET-merged by id, toolsIds are additive and dashboard tools are preserved, allowRemoveTools=true is required for detaching, and ownerID is read-only. Remaining gap is that the response shape and failure behavior aren't mentioned at all.

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 PATCH scope, then prioritizes the highest-risk gotchas (prompt routing, nodes omission, additive tools) before the niche field groups. Dense but every clause carries information; the terse vg_* shorthand assumes the reader maps it to schema fields.

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 mutation tool with deep nested objects and no output schema, the description covers the traps that cause data loss or silent no-ops. The missing piece is any indication of what the call returns or how partial failures surface, which matters for a non-idempotent write.

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 already 100%, so the baseline is 3; the description adds real value by disambiguating systemPrompt (writes to nodes[0].instructions) from vg_systemPrompt (never send), by steering prompt edits to patch_agent_prompt, and by grouping UI Engine fields under vg_enableUIEngine* + vg_uiEngineChannelConfig. It does not cover most of the 23 parameters, but the ones it covers are the error-prone ones.

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 and resource ('Update an existing Convocore agent (PATCH)') and immediately names the sibling that handles the adjacent job (patch_agent_prompt for large prompt edits). An agent can distinguish this from create_agent, patch_agent_prompt, and update_agent_custom_css without opening any schema.

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 routing rules: prefer patch_agent_prompt for large prompt edits, do NOT pass nodes[] unless changing nodes, use funnelConfig instead of a custom webhook, and set vg_enableUIEngine first before individual element flags. These are concrete when/when-not conditions tied to alternatives in the sibling list.

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