Skip to main content
Glama
Neuratel-AI

Neuratel MCP Server

Official
by Neuratel-AI

update_agent

Update agent configurations by changing only specified fields while preserving all others. Deep-merges nested settings, enabling precise adjustments to voice, transcriber, tools, and more.

Instructions

Update any part of an agent's configuration.

Only the fields you provide are changed — everything else stays as-is. The backend deep-merges your changes, so you can update a single field inside a nested config without affecting sibling fields.

Two ways to update

Named parameters — for common changes:

update_agent(agent_id="...", temperature=0.5, voice_speed=1.1)

config parameter — for any section not covered by named params. Use get_agent first to see the current structure, then pass sections. Named params always override the corresponding section in config.

IMPORTANT: provider field required for voice/transcriber

The backend uses discriminated unions — voice and transcriber sections MUST include the provider field or validation fails. Always pair voice_id/voice_model/voice_speed with voice_provider. Same for transcriber.

Available config sections

config={
    "turn_detection": {
        "mode": "semantic_vad",   # or "vad"
        "min_delay": 0.5,
        "max_delay": 6.0,
        "endpointing_mode": "dynamic"
    },
    "timeout": {
        "enabled": True,
        "trigger_seconds": 15.0,
        "warning_messages": ["Are you still there?"],
        "final_message": "Goodbye!"
    },
    "background_audio": {
        "ambient": {"enabled": True, "source": "office_ambience", "volume": 0.3},
        "thinking": {"enabled": True, "source": "keyboard_typing", "volume": 0.5}
    },
    "tools": {
        "rag": {"enabled": True, "knowledge_base_ids": ["kb-id"], "top_k": 5},
        "voicemail": {"enabled": True, "action": "hangup"},
        "hangup": {"enabled": True, "keywords": ["goodbye", "bye"]}
    },
    "transfer": {
        "enabled": True,
        "mode": "blind",
        "destinations": [{"name": "Support", "number": "+15551234567",
                          "description": "Human agent", "keywords": ["human"]}]
    },
    "analytics": {
        "recording": {"enabled": True},
        "summary": {"enabled": True},
        "success_evaluation": {
            "enabled": True,
            "criteria": "Did the agent resolve the issue?",
        },
    },
    "tts_text_transforms": ["filter_markdown", "filter_emoji"],
    "preemptive_generation": False,
    "min_consecutive_speech_delay": 0.0
}

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
tagsNo
configNo
agent_idYes
languageNo
voice_idNo
is_activeNo
max_tokensNo
brain_modelNo
descriptionNo
temperatureNo
voice_modelNo
voice_speedNo
instructionsNo
first_messageNo
brain_providerNo
voice_providerNo
max_call_durationNo
transcriber_modelNo
interruption_enabledNo
transcriber_providerNo
first_message_delay_msNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

With no annotations, the description takes full responsibility for behavior disclosure. It covers deep-merge semantics (only provided fields are changed), the requirement for provider fields with voice/transcriber sections, and the override rule (named params override config sections). It also warns about validation failure due to discriminated unions, which is critical for correct usage.

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 long but well-structured with headers, code examples, and a warning section. Each part contributes meaningful information, and the front-loaded purpose statement ensures quick orientation. It could be trimmed slightly but is not wasteful.

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?

Given the complexity (22 parameters, nested config), the description thoroughly covers merge behavior, provider requirements, and the complete config schema. It does not describe return values, but an output schema exists, so that's not required. It omits error cases or permission notes, but for an update tool with this depth, it is highly 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 0%, so the description must compensate. It explains the config parameter in extensive detail with a full code block listing sections and fields. It also names several common parameters (temperature, voice_speed, voice_id, etc.) and their roles. However, not all 22 parameters are individually discussed, though many are self-explanatory by name.

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 opens with 'Update any part of an agent's configuration,' which clearly states the verb (update) and resource (agent configuration). This distinguishes it from sibling tools like create_agent, delete_agent, and get_agent.

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?

It explicitly outlines two usage paths: named parameters for common changes and the config parameter for other sections. It also advises calling get_agent first to see the current structure, providing clear context. However, it doesn't explicitly state when not to use this tool (e.g., for creation), but the sibling list and context make this obvious.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Neuratel-AI/neuratel-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server