Skip to main content
Glama

Kite Discord Bot Builder

Test flow

test_flow
Read-only

Runs a flow as a test without changing anything, to check that it does what it should. The flow runs with a fake trigger: the command with the options, the event of an event listener, a webhook request, or a click on a button or select menu of a message template. Reads from Discord are real, like members and roles. Nothing is sent or changed: messages, role changes and every other change are returned as effects of their block, with warnings when Discord would reject them, like a missing permission or a role above the bot's. Stored variables are read, and changes to them only last for the test. Use variables to start the test with other stored values, like a balance, XP or the time a cooldown started. Blocks that call services other than Discord, like Send API Request, AI and integrations, don't run and have no result unless you mock them. Mock blocks to test each branch, like the error branch of an Error Handler or the answers of AI Check and AI Choice. Waits are skipped. Use then to click the buttons, use the select menus and submit the modals the flow showed, which runs those parts of the flow. Returns each run of the flow with the blocks that ran in order, their results, errors and effects. After building or changing a flow, test the branches that matter and fix what fails before telling the user it works.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "app_id": "<app_id>"
    },
    "name": "test_flow"
  }
}

Input Schema

NameRequiredDescriptionDefault
dmNoRuns a command in a DM with the bot instead.
thenNoWhat the user does after the flow ran, in order: {"click": "<label or custom ID of a button>"}, {"select": "<placeholder or custom ID of a select menu>", "values": [...]}, or {"submit": {"<custom ID or label of an input>": "value"}} for the modal the flow showed. user_id makes someone else do it.
eventNoMerged into the Discord event of an event listener, or the interaction of a command, in Discord's gateway format. Like {"content": "hi"} for message_create, or {"emoji": {"name": "⭐"}, "message_id": "123"} for reactions.
mocksNoWhat blocks do instead of running, by block ID. {"result": ...} is the block's result, in the format of its result_schema, like a Discord member object for Get Member, or {"status_code": 200, "body": {...}} for Send API Request. {"error": "..."} makes the block fail. For AI Check the result is "yes", "no" or the probability of yes, for AI Choice the name of an option, and for Verify Webhook "valid" or "invalid".
app_idYesThe ID of the app, from list_apps.
valuesNoWith message_id: the values picked in the select menu.
optionsNoThe arguments of a command by name, like {"user": "123", "amount": 5}. IDs as strings, attachments as the URL of a file.
user_idNoWho triggers the flow, a member of the server. By default the user of the API token.
webhookNoThe request that triggers a webhook event listener.
guild_idNoThe server, from list_servers. Needed if the bot is in more than one.
variablesNoValues of stored variables when the test starts, in place of the stored ones, like {"variable_id": "...", "scope": "<server ID>:<user ID>", "value": 95}. The scope is the scope setting of the block as it would be filled in, and only for variables with a value per scope. A value of null means the variable has no value.
channel_idNoThe channel, by default the server's system channel or first text channel.
command_idNo
message_idNo
flow_source_idNoWith message_id: the flow_source_id of the button or select menu to use.
event_listener_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the readOnlyHint/openWorldHint annotations by disclosing that Discord reads are real, writes are returned as effects with validation warnings, waits are skipped, non-Discord services do not run unless mocked, and stored-variable changes last only for the test. It also describes the return payload (each run with ordered blocks, results, errors, effects). That is exactly the behavioral context annotations cannot carry.

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?

Purpose is front-loaded and nearly every sentence carries non-redundant operational detail, but the block is a dense unbroken paragraph of a dozen sentences with no structure, list or paragraph breaks for the distinct concepts (trigger, effects, variables, mocks, then). Slight redundancy between 'without changing anything' and 'Nothing is sent or changed'.

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 16-parameter tool with nested objects and no output schema, the description covers the trigger inputs, the mock/variable setup, the replay mechanism and the shape of the returned runs. An agent has everything needed to invoke it correctly, including the multi-server guild_id and default channel caveats handled by the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 81%, yet the description adds real meaning: mocks need per-block result formats including special cases for AI Check, AI Choice and Verify Webhook; variables supply scoped start values with null meaning no value; 'then' replays button/select/modal interactions via user_id. This is guidance an agent could not infer from the schema alone.

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 ('Runs a flow as a test') plus the key scope constraint ('without changing anything') and the trigger model (fake trigger vs. real Discord reads). This lets an agent distinguish it immediately from edit_flow, list_logs and the create/update siblings.

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?

Gives clear usage context: run it after building or changing a flow, test the branches that matter, and fix failures before reporting success. It also explains how to set up scenarios (variables, mocks). It stops short of naming alternatives or explicitly saying when not to use it, so a 4 rather than a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.