ethora-mcp-server

Update Agent

ethora-agent-update

DestructiveIdempotent

Overwrites the fields you pass; previous values are not kept and cannot be restored from the API, so confirm changes to the prompt, name or settings with the user first. Update a saved AI agent (PUT /v2/agents/:agentId). All fields are optional - only what you pass is updated. Common uses: tune the system prompt after a test run, switch responseMode to control turn-taking in multi-agent rooms, or adjust cooldownSec. See ethora-agents-quickstart prompt for the end-to-end recipe. Requires: an agent id or address from ethora-agent-list or ethora-agent-create. Only the agent's owner can update it: a public agent from someone else, including the platform's Support Agent, answers 403, so ethora-agent-clone it and update the copy.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	New display name. For multi-agent scenarios prefer single-word names — the @-mention matcher uses exact display-name match with word-boundary.
`slug`	No	URL-safe slug.
`isRAG`	No	Enable RAG retrieval.
`prompt`	No	Updated system prompt (persona + behaviour). For multi-agent rooms instruct the agent to end every message with an @-mention of the next speaker — that's how turn-handoff works through the response gate.
`agentId`	No	Mongo _id (24 hex chars) of the agent to update.
`ragTags`	No	RAG tag filter.
`summary`	No	Short bio.
`trigger`	No	Legacy trigger field. Prefer `responseMode`.
`llmModel`	No	LLM model override.
`flowsYaml`	No	Deterministic scripted conversation for this agent, as YAML. Drives the agent through a fixed sequence (opening menu, appointment request, intake questionnaire, survey) instead of leaving every turn to the model. Compiled and validated server-side on save: an invalid script is rejected with code `FLOWS_INVALID` and per-line details, and nothing is stored. A flow named `start` is reserved and fires when a conversation opens. Buttons are authored here (`buttons:` on a `say` step, or `options:` on an `ask` step). Call `fetch` with id `doc:agent-flows` for the full authoring format before writing one. Pass an empty string to clear the script.
`categories`	No	Directory categories, any of: `customer-support` (customer-facing assistants), `persona` (a character or historical figure), `entertainment` (quizzes, games, scenarios), `worker` (internal work). Used to filter `ethora-agent-list`. Replaces the agent's current set.
`visibility`	No	'private' or 'public' (cross-app invitable).
`cooldownSec`	No	Minimum seconds between this agent's replies in a given room. Damped 2x for bot-to-bot. Set 0 for quick turn-taking.
`isPublished`	No	Convenience alias for visibility='public'.
`llmProvider`	No	LLM provider override.
`botAvatarUrl`	No	Avatar image URL.
`responseMode`	No	When the agent replies. 'always' = every message; 'mentioned' = only @-mention or /bot (best for multi-agent turn-taking); 'smart' = mini-LLM decides; 'probability' = coin-flip using `responseProbability`.
`botDisplayName`	No	Display name in chat UI.
`greetingMessage`	No	Message the agent posts when it first joins a new room.
`agentIdOrAddress`	No	Alias for `agentId` - either name is accepted, pass whichever you have.
`responseProbability`	No	If responseMode='probability', odds (0-1) of replying. Damped 0.6x for bot-to-bot.

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations cover the safety profile (destructiveHint=true, idempotentHint=true), but the description goes well beyond them: it explains that passed fields are overwritten and old values are unrecoverable, advises confirming prompt/name/settings changes with the user, and discloses the 403 ownership failure mode. That is exactly the kind of operational context annotations cannot encode.

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 critical destructive-behavior warning is front-loaded, and the second paragraph cleanly handles prerequisites and authorization. Slight redundancy ('Overwrites the fields you pass' vs. 'only what you pass is updated') and the endpoint path add minor noise but no real bloat.

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 21-parameter mutation tool with no output schema, the description covers everything an agent needs to call it safely: destructive/partial-update semantics, ownership/auth requirements, and a pointer to external authoring docs (doc:agent-flows) for the complex flowsYaml field. 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 per-parameter docs already carry the load and baseline is 3. The description still adds value by calling out specific parameters with rationale (prompt for turn-handoff, responseMode for multi-agent turn-taking, cooldownSec), nudging an agent toward the right fields for common tasks.

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 a saved AI agent') and even anchors it to the endpoint PUT /v2/agents/:agentId. An agent can trivially distinguish this from siblings like ethora-agent-create, ethora-agent-list, and ethora-agent-activate.

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 names concrete use cases (tune prompt after a test run, switch responseMode for turn-taking, adjust cooldownSec) and points to the ethora-agents-quickstart prompt for the full recipe. It also spells out prerequisites (agent id/address from list or create) and the ownership constraint with an explicit alternative: clone an un-owned agent and update the copy instead.

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

All ethora-mcp-server tools Inspect

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.

Update Agent

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources