Mojeeb

Update an agent's settings

update_agent

DestructiveIdempotent

Update an agent's settings

Changes the settings you send: the name, the description, the Main Instructions (instructions), the time zone, the AI handoff, comment auto-hide, and when the AI stops responding (ai_stop_enabled, ai_stop_when). Send at least one (422 no_settings otherwise). Everything is validated before anything changes. instructions replaces the whole text, and the AI follows the new text on its next replies, usually within a minute; sending the text the agent already has changes nothing. A key can't change an agent's status (so it can't delete one), ai_model, model_provider, avatar_url or language: sending any of them with a value is 422 field_not_writable, with the field in param, and nothing changes. Deleting an agent stays in the dashboard; follow-ups have updateFollowUpSettings, and the AI's switch per channel updateConnection. The answer's message_weight says what the agent now reads (Main Instructions, active knowledge, active attachments' text, in characters) and what one of its replies costs; when it has a notice, pass it on to the user.

Input Schema

Name	Required	Description
`name`	No	Can't be blank or contain angle brackets. Stored without surrounding spaces.
`agent_id`	Yes	The agent the resource belongs to. Another company's agent, or the nil UUID, is `404 agent_not_found`; an agent outside the key's agent list is `403 agent_not_authorized`.
`time_zone`	No	An IANA time zone in Region/City form, such as `Africa/Cairo` (`422 unknown_timezone` otherwise), or an empty string for the platform default.
`description`	No	An empty string clears it. Can't contain angle brackets. Stored without surrounding spaces.
`ai_stop_when`	No	When the AI should stop responding, in your words, such as "When the customer asks to talk to a person or wants a refund." Replaces the whole text; an empty string clears it. Stored without surrounding spaces. Sending it without `ai_stop_enabled` keeps the switch as it is.
`instructions`	No	The Main Instructions. Replaces the whole text, stored and given to the AI exactly as sent; can't be blank. Send plain text with a blank line between rules: the dashboard shows lines without one as a single paragraph, and saves them that way when someone edits them there.
`ai_stop_enabled`	No	Whether the AI may stop responding in a conversation and hand it to your team. Switching it on, or changing `ai_stop_when` while it's on, applies from the agent's next message.
`ai_handoff_enabled`	No	Whether a reply from your team pauses the AI in that conversation.
`ai_handoff_window_minutes`	No	How long the AI stays paused after your team's last message. Kept while the handoff is off.
`comment_auto_hide_enabled`	No	Whether the AI hides negative Facebook and Instagram comments on the agent's pages.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 1, 2026

addedInput schema / properties / ai_stop_enabled

Added value: +{
+  "description": "Whether the AI may stop responding in a conversation and hand it to your team. Switching it on, or changing `ai_stop_when` while it's on, applies from the agent's next message.",
+  "type": "boolean"
+}

addedInput schema / properties / ai_stop_when

Added value: +{
+  "description": "When the AI should stop responding, in your words, such as \"When the customer asks to talk to a person or wants a refund.\" Replaces the whole text; an empty string clears it. Stored without surrounding spaces. Sending it without `ai_stop_enabled` keeps the switch as it is.",
+  "maxLength": 2000,
+  "type": "string"
+}

First observedOct 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, yet the description still adds real substance: validation happens before any change, instructions replaces the whole text and takes effect within about a minute, resending identical text is a no-op, and non-writable fields yield `422 field_not_writable` with the field in `param` and no partial change. The response contract (`message_weight`, `notice`) is also disclosed. It stops short of describing partial-failure semantics across multiple fields beyond 'validated before anything changes'.

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 mutable-field list and the minimum-payload rule before the edge cases. It is a single dense block, though — the error-code and side-effect sentences could be split for scanning, and a few clauses (the dashboard paragraph-splitting note) are verbose relative to their importance.

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 10-parameter mutation tool with no output schema, the description covers mutability constraints, effect timing, idempotency, error codes, and what the response fields mean and require of the caller. An agent has enough to invoke it correctly and to relay the result.

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 baseline is 3, but the description adds meaning the schema does not: `instructions` replaces rather than merges, `ai_stop_when` replaces its whole text and sending it without `ai_stop_enabled` preserves the switch. It does not restate per-parameter formats (time zone form, length limits), which the schema already covers.

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 agent's settings') and immediately enumerates the mutable fields: name, description, instructions, time zone, handoff, comment auto-hide, ai_stop. It also carves out what it is not (deletion stays in the dashboard, follow-ups use updateFollowUpSettings, per-channel switch uses updateConnection), so an agent can separate it from siblings without reading schemas.

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 requires at least one settings field ('422 no_settings otherwise') and names three concrete alternatives for adjacent operations (updateFollowUpSettings, updateConnection, dashboard for delete). The condition that selects each alternative is stated, not implied.

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

All Mojeeb 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.

Resources

Need Help?