Skip to main content
Glama
Sign In

Convocore

by app.convocore.mcp
OverviewDiscussionsAdmin

create_agent

Create a Convocore agent (advanced/raw). Prefer create_agent_from_template for website/branded agents. Always node-based: enableNodes is forced true; put the main prompt in systemPrompt (or nodes[0].instructions) — do NOT use vg_instructions (API rejects that field). Default chat model is always claude-haiku-4-5-20251001 (Claude Haiku 4.5) on vg_defaultModel + nodes[0].llmConfig.modelId. UI Engine flags optional via vg_enableUIEngine*. Lead notify: use funnelConfig (AI Funnel + lead scoring + email recipients) — do NOT create custom HTTP webhook tools for sales alerts. Sets nodes[0].kb.enabled for auto RAG with maxChunks=3 and vgOptions.maxChunkSize=512 — still bake critical facts into systemPrompt. Do not raise chunk size or chunk count unless the user asks.

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": {
      "title": "<title>"
    },
    "name": "create_agent"
  }
}

Input Schema

NameRequiredDescriptionDefault
lightNoEnable light mode (no chat history retention for privacy)
nodesNoOptional nodes. If omitted with systemPrompt, MCP creates the start node. Main prompt MUST be nodes[0].instructions.
themeNoVisual theme (e.g., blue-light, custom-blue-dark)
titleYesThe title of the agent
disabledNoWhether the agent should be disabled
descriptionNoA brief description of the agent
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.
enableVertexNoEnable Vertex AI for the agent
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.
systemPromptNoMain behavior prompt → written to nodes[0].instructions (enableNodes always true).
autoOpenWidgetNoAuto-open widget when agent loads
additionalConfigNoExtra agent fields: same as update_agent additionalConfig (see that tool for each field's type and meaning). Fields: roundedImageURL, branding, customThemeJSONString, chatBgURL, lang, fontFamily, rectangeImageURL, avatarImageUrl, headerImageUrl, bannerImageUrl, enableNodes, nodesSettings, vg_systemPrompt, vg_initPrompt, vg_initMessages, vg_prompt, vg_temperature, vg_defaultModel, vg_maxTokens, vg_max_messages_history, vg_enableAboutContext, ifKnowsThreshold, enableFallback, fallbackSettings, enableAudioSupport, captureIGStories, metaHumanTakeover, vg_kb_llm, vg_kbDefaultDimension, vg_kbTopChunks, vg_kbCharCount, vg_kbDocsNum, proactiveMessage, autoStartWidget, messageDelayMS, scrollAnimation, disableSmoothScroll, buttonsLayout, buttonVariant, inputVariant, ui, ADVANCED_customCSS, disableRating, chatEndMessage, aiIntroductionMessage, enableAIIntroductionMessage, privacyDisclaimer, gdprCompliance, disableModelAutoUpgrade, acceptFileUpload, disableFileUpload, enableQuickFileUpload, soundEffectUrl, soundEffectEnabled, agentPlatform, AITranslateTo, enableAITranslate, disableHumanHandoff, alwaysShowHandoff, manualControl, enableVGHandoff, fixedHandoffPopup, UIhandoffTitle, UIhandoffSubtitle, showHandoffEvenIfOffline, persistHandoffOnRefresh, blockInputDuringHandoffRequest, disableHandoffMessages, handoffNowChattingMessage, handoffBackToAiMessage, handoffCancelButtonLabel, disableHandoffStatusMessages, convoTags, topicsConfig, starred, enableGeoAnalytics, hideVoiceflowAnalytics, hideCallAnalytics, hideConversationMetrics, hideCustomAnalytics, hideVapiAnalytics, hideFunnelAnalytics, marketplace, autoTest, customButtonJSON_STRING. Do not put the main prompt here. Unknown fields are rejected up front with the valid names.
allowRemoveToolsNoDefault false: toolsIds in a nodes patch are unioned with the live list. Set true only to intentionally remove tools.
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.8/5.0
Behavior5/5

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

Annotations only declare readOnly=false, destructive=false, idempotent=false, openWorld=false. The description goes well beyond: it discloses forced server-side behavior (enableNodes always true), rejected fields, forced model defaults, and RAG defaults — exactly the kind of side effects an agent must know before calling a non-idempotent create.

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 correctly: identification, sibling alternative, then constraints. It is dense and dash-heavy, packing several independent rules into single run-on sentences, which slightly slows scanning, but every clause carries an actionable constraint rather than filler.

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, deeply nested create tool with no output schema, the description covers the high-risk gotchas (prompt placement, forced node mode, model defaults, KB sizing, lead-notify path) and points to additionalConfig/update_agent for the long tail. It does not say what the call returns (e.g., agent id) or note permissions/plan limits, which leaves a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/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, but the description adds real semantics beyond the schema: which field carries the main prompt (systemPrompt vs nodes[0].instructions), that vg_instructions is rejected by the API, that enableNodes is forced true, that the default model is claude-haiku-4-5-20251001, and that kb defaults to maxChunks=3 / maxChunkSize=512. That is meaningful guidance the schema does not convey.

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 ('Create a Convocore agent') and immediately qualifies the variant ('advanced/raw'), then names the sibling to use instead for website/branded agents. An agent can distinguish this from create_agent_from_template and clone_agent 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?

Explicitly routes the agent: use create_agent_from_template for website/branded agents, use funnelConfig rather than a custom HTTP webhook for lead alerts, and do not raise chunk size/count unless asked. These are concrete when-to-use / when-not-to-use rules naming alternatives.

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

All Convocore toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources