Mojeeb

Test the agent in a chat

send_test_chat_message

Test the agent in a chat

Sends a message to the agent as a customer would write it and returns the agent's answer in the same response, so you can check how it answers after changing its instructions, knowledge or attachments. Leave conversation_id out to start a new test chat; send the conversation_id of an earlier answer to continue it, so the agent sees the whole chat. Only test chats can be continued: a customer's conversation is 404 not_found.

The AI answers exactly as it does for customers, with its knowledge, tools, attachments and lead capture. Its tools run for real: a test can book a calendar slot, capture a lead or call your company's own API. Each answer counts against your plan's message limit, like any AI reply; over the limit, nothing is saved and the answer is 402 message_limit_exceeded. A test chat is saved like one from the dashboard's test chat, under a customer named after the key or the AI assistant.

The request waits up to 30 seconds for the answer. status says how it went: replied with the agent's messages in replies; pending when no answer came in time (read it later with listConversationMessages and after set to message_id); or no_reply when the AI is switched off or paused in that chat. One message at a time per test chat: sending another while one waits is 409 test_chat_busy.

Input Schema

Name	Required	Description
`text`	Yes	The message, as a customer would write it; text that is only spaces is refused.
`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`.
`conversation_id`	No	A test chat of this agent to continue, from an earlier answer's `conversation_id`. Leave it out to start a new test chat.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 27, 2026

TDQS

A4.6/5.0

Behavior5/5

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

The description goes well beyond the annotations by disclosing real side effects: the agent's tools run for real, potentially booking a calendar slot, capturing a lead, or calling a company API. It also explains message-limit accounting, the 402 limit error, persistence behavior, the 30-second wait, status values, and the 409 busy condition.

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 front-loads the core action and then layers on necessary side-effect and error details. The only minor waste is the opening sentence repeating the title, but the overall structure is purpose-built for a complex test tool.

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?

Given the absence of an output schema and the complexity of a tool that can trigger real external actions, the description is remarkably complete. It covers input behavior, continuation rules, side effects, persistence, limits, timeout behavior, status outcomes, and concurrency constraints.

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 already 100%, and the description adds useful semantic context beyond the schema: text should read as a customer would write it, and conversation_id controls whether a new test chat starts or an earlier test chat continues. It also clarifies that only test chats can be continued.

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 uses a specific verb and resource: it sends a message to an agent as a customer would and returns the agent's answer in the same response. It clearly frames this as a test-chat operation distinct from real customer conversations, noting that customer conversations return 404 when continuation is attempted.

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 gives clear when-to-use guidance: test the agent after changing instructions, knowledge, or attachments. It also explains how to start versus continue a test chat via conversation_id, and explicitly excludes customer conversations. It stops short of naming sibling tools like send_conversation_message as alternatives, but the context is otherwise strong.

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?