agents_simulate_inbound
Replay an inbound message on a thread through the real trigger pipeline and return what would have happened. The router auto-picks the winning enabled agent + trigger by priority/specificity (same logic as production). By default send_mode='draft' so no real message is sent; pass send_mode='auto'...
This record as markdown: /tools/io-github-saloprj-dialogbrain/agents-simulate-inbound.md
What agents_simulate_inbound does on Dialogbrain
AI agents invoke agents_simulate_inbound to trigger actions in Dialogbrain. What it does depends on the arguments the agent supplies, and its effects often reach beyond the immediate call: builds kicked off, notifications sent, workflows started.
| Parameter | Type | Required | Description |
|---|---|---|---|
send_mode | string | — | How the matched agent should deliver its reply. 'draft' (default, safe) creates a draft only — no real send, no idempotency key. 'auto' lets the agent deliver t |
thread_id | integer | — | Thread ID to route the simulated event from. Must belong to the API key's workspace. Omit and set create_new_livechat=true to test on a FRESH thread with no his |
message_text | string | — | Inbound message body to simulate. Defaults to '[MCP simulation test]' when omitted. |
system_message | object | — | Tag the simulated inbound as a system/service-message row (missed call, group join, pinned message, etc.) so the `excluded_system_message_kinds` trigger filter |
blockchain_tx_data | object | — | When set, simulate a blockchain:transfer event instead of a channel:message:new event. Expected keys: chain, to_address / from_address, tx_hash. |
channel_account_id | integer | — | Optional. The livechat widget's channel_account_id to host the fresh chat when create_new_livechat=true. Omit to auto-pick the workspace's active livechat widge |
attachment_file_ids | array | — | Optional list of workspace file IDs to attach to the simulated inbound message — same shape as a real Telegram message with image/document attachments. Use this |
create_new_livechat | boolean | — | Start a FRESH, history-free livechat chat instead of using an existing thread_id — creates a new visitor + thread on the workspace's livechat widget and routes |
Parameters from the server's own tool schema.
Why agents_simulate_inbound is rated High
agents_simulate_inbound triggers real processes with real consequences. An agent gone sideways doesn't fire it once. It starts dozens of builds, sends mass notifications, or burns through compute before anyone looks up.
Attacks that exploit this kind of access
The rule that runs agents_simulate_inbound safely
PolicyLayer is an MCP gateway: it sits between your AI agents and Dialogbrain, and checks every tool call against a rule you set before the call runs. Nothing changes on the server itself. For agents_simulate_inbound, this is the rule to start with:
agents_simulate_inbound stays usable, but rate-capped: a runaway agent can't fire it dozens of times a minute. Everything else on the server is denied unless you say otherwise.
The button opens the PolicyLayer dashboard: create your workspace, connect Dialogbrain, apply this rule, and every agents_simulate_inbound call is checked against it from then on.
Questions about agents_simulate_inbound
Replay an inbound message on a thread through the real trigger pipeline and return what would have happened. The router auto-picks the winning enabled agent + trigger by priority/specificity (same logic as production). By default send_mode='draft' so no real message is sent; pass send_mode='auto' on a test account to let the matched agent actually deliver (drafts get overwritten by the next draft, so 'auto' is the only way to verify Telegram/email delivery end-to-end). Use to verify routing for a thread: which agent answers, which trigger wins, or — when nothing matches — the structured skip reason. Pass blockchain_tx_data instead of message_text to simulate a blockchain:transfer event on the thread. Returns: {matched: true, matched_agent: {id, name, execution_mode}, matched_trigger: {id, trigger_type, conditions, specificity_score}, routing_reason, response_text, messages[], execution_mode, send_mode, model_used, tokens_input, tokens_output, latency_ms, rag_queries_made, rag_results_used} on a hit, or {matched: false, skip_reason, simulator_warnings} on a miss. It is categorised as a Execute tool in the Dialogbrain MCP Server, which means it can trigger actions or run processes. Use rate limits and argument validation.
agents_simulate_inbound accepts 8 parameters: send_mode, thread_id, message_text, system_message, blockchain_tx_data, channel_account_id, attachment_file_ids, create_new_livechat. The full parameter table on this page comes from the server's own tool schema.
Register the Dialogbrain MCP server in PolicyLayer and add a rule for agents_simulate_inbound: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Dialogbrain. Nothing to install.
agents_simulate_inbound is a Execute tool with high risk. Execute tools should be rate-limited and have argument validation enabled.
Yes. Add a rate_limit block to the agents_simulate_inbound rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for agents_simulate_inbound. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
agents_simulate_inbound is provided by the Dialogbrain MCP server (https://api.dialogbrain.com/mcp). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
More on Dialogbrain, and thousands of servers like it.
Across the catalogue