Skip to main content
Glama
Sign In

Mojeeb

by app.mojeeb.mcp
OverviewDiscussionsAdmin

Change a conversation's state

update_conversation
DestructiveIdempotent

Change a conversation's state

Changes what you send: the status, read for the team, urgent, and the conversation's AI switch. urgent: true is the dashboard's "Mark as Urgent" and urgent: false its "Mark as Resolved": both clear needs_attention, and resolving also sets an unhappy sentiment (1 or 2) to neutral (3). The AI reads urgent and needs_attention again with each of its replies, so a mark lasts until the AI next answers in the conversation. is_read never sends the customer a read receipt. ai_enabled: false stops the AI in this conversation until it is switched on again; a pause that a teammate's reply started is ended with resumeConversationAi instead. A change to what the conversation already has writes nothing. Every switch of ai_enabled is logged as made by your key (listConversationAiSwitches); the AI can also switch itself off when the agent's ai_stop_enabled is on. Resolving never switches the AI back on.

Input Schema

NameRequiredDescriptionDefault
statusNo
urgentNo`true` marks it urgent, `false` resolves it; both clear `needs_attention`, and resolving sets an unhappy `sentiment` (1 or 2) to neutral (3).
is_readNoRead or unread for the team. Never sends the customer a read receipt.
agent_idYesThe 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`.
ai_enabledNoThe conversation's AI switch.
conversation_idYesOne of the agent's conversations. Another agent's conversation, or a deleted one, is `404 not_found`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.5/5.0
Behavior5/5

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

The description discloses effects beyond the annotations: urgent clears needs_attention, resolving can neutralize sentiment, AI reads urgent/needs_attention per reply, is_read never sends a customer receipt, ai_enabled pauses AI until re-enabled, no-op writes are avoided, and AI switches are logged. These details align with destructiveHint=true and idempotentHint=true and provide substantial operational clarity.

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 dense and front-loads the affected state fields. It is long, but most sentences carry behavioral details that are useful for a destructive/idempotent mutation; the only minor waste is repeating the title as the first line.

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 complex state-changing tool with no output schema, the description covers side effects, AI behavior, logging, no-op behavior, and an important alternative. It does not describe the response shape, but the critical invocation and effect context is otherwise 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 description coverage is high at 83%, so the schema already documents most parameters. The description adds meaningful semantics for urgent, is_read, and ai_enabled beyond the schema, though it does not explain the status enum values or the full implications of open/closed/archived.

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 states a specific verb and resource: changing a conversation's state. It names the exact fields affected (status, is_read, urgent, ai_enabled) and distinguishes ai_enabled from the sibling resume_conversation_ai, so an agent can identify the tool without opening the schema.

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 explains the practical meaning of urgent true vs false, is_read, and ai_enabled false, and it explicitly routes one case to resume_conversation_ai instead. It does not provide a full when-not-to-use statement or compare against all state-related siblings, but the usage context is clear.

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

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