ethora-mcp-server

Update Agent

ethora-agents-update-v2

Idempotent

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.

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`	Yes	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.
`categories`	No	Category tags for directory listings.
`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.
`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 observedSep 15, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Adds important behavioral context beyond annotations: despite being a PUT endpoint, it behaves as a partial update. It also explains practical effects of responseMode and cooldownSec. Annotations already cover idempotency and non-destructiveness, so the description supplements rather than repeats them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with no filler: operation/endpoint first, then update semantics, then common use cases and a recipe pointer. Every sentence earns its place.

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?

The 19-parameter schema is fully documented and annotations cover idempotency/safety. The description adds operation semantics, typical workflows, and a quickstart reference. It does not describe response/error format, but the absence of an output schema makes that less critical here.

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% with detailed parameter descriptions, so the baseline is 3. The description adds selection value by tying prompt, responseMode, and cooldownSec to concrete scenarios and clarifies that all fields except agentId are optional.

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' with the endpoint 'PUT /v2/agents/:agentId'. It is clearly distinguishable from sibling tools like ethora-agents-create-v2, ethora-agents-delete-v2, and ethora-agents-clone-v2.

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?

Explicitly explains the partial-update semantics ('All fields are optional — only what you pass is updated') and gives concrete common uses: tuning the prompt after a test run, switching responseMode for turn-taking, and adjusting cooldownSec. It points to the quickstart recipe for the end-to-end flow, though it does not explicitly contrast with create/get tools.

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