Provider-neutral MCP server for AgentDispatch.
Free
Tools
list_applications
List the applications this API key can access, with the caller role and the permissions it grants. Start here when using a personal API key (usr_...): every other tool needs an explicit applicationId, which this tool supplies. Read-only, takes no arguments. Returns an array of { id, name, role, permissions }; an empty array means the key is valid but belongs to no application yet.
ArgumentsA call is made on an account: it counts against an allowance and the publisher sees it, which is why this one asks who you are first.
—
p95 latency
—
call success
—
uptime 90d
0
calls last 7d
What it does
Build, edit, and deploy Telegram bots on FlowCastle's hosted visual flow platform.
Quickstart
# 1 — install (mcprush login holds a key from your dashboard)
npx mcprush@latest add flowcastle-mcp
# 2 — ask your agent something
> Build, edit, and deploy Telegram bots on FlowCastle's hosted visual flow platform.
FlowCastle is free: there is no plan to choose, no cap to set and nothing that can bill you.
Publishernot claimed
APAll 1 server
api.flowcastle.ai1 server
1 category
Collected from a public index. Nobody has claimed this account, so nothing here was written by its author — claim it if it is yours.
Installation
Where are you running it?
Every route below installs the same thing and ends at the same approval screen. Nothing here runs on your machine — this server runs on the publisher’s own infrastructure behind our gateway, and what you install is the connection to it.
Claude Codedeclared by this listing
This is a public server: you run it yourself and this marketplace is not in the path. Claude Code registers it in one command.
claude mcp add --transport http flowcastle-mcp https://api.flowcastle.ai/api/mcpReconnect, or start a new session, and the tools appear in the model’s tool list.
Free to install, and it runs from its publisher’s own package: no account, no key, no card.
What it writes
One config entry pointing at the gateway. The server itself runs on the publisher’s own infrastructure, so nothing from this listing executes on your machine.
What you approve
28 tools, with what each one reads, writes and reaches shown before you agree — the same list on every route above. Read the tool surface.
Tool surface
What the model actually sees. Descriptions are diffed on every release — see version history.
List the applications this API key can access, with the caller role and the permissions it grants. Start here when using a personal API key (usr_...): every other tool needs an explicit applicationId, which this tool supplies. Read-only, takes no arguments. Returns an array of { id, name, role, permissions }; an empty array means the key is valid but belongs to no application yet.
Takes no parameters.
Example callreturns →
Create a new application (workspace) owned by the caller. Requires a personal API key (usr_...) — application-scoped keys cannot create applications. Seeds default flows unless skipDefaultFlows is true. Creates persistent state and is NOT idempotent: calling it twice creates two applications. Returns the new application id, which you then pass as applicationId to the other tools.
Takes no parameters.
Example callreturns →
Update application-level settings (name, active state, default language, incoming-message behavior). Requires the manage_settings permission in that application. Only the fields you pass are changed; omitted fields keep their current value, so the call is idempotent. Returns the updated application.
Takes no parameters.
Example callreturns →
List the group/channel chats a telegram_mtproto userbot monitors. Read-only. The watched list is the single source of truth for which chats the userbot processes: messages from unlisted group/channel chats are dropped (fail closed) and their contacts never materialize; DMs always pass. botId may be omitted when the application has exactly one userbot.
Takes no parameters.
Example callreturns →
Replace a telegram_mtproto userbot's watched-groups list — the chats it monitors. Requires the manage_settings permission. SET semantics: send the COMPLETE desired list every time (call list_watched_groups first and include existing entries you want to keep — omitting one removes it). Each entry needs a chatId (e.g. "-100…", for chats the account has joined) or a public username/t.me link; mode "j
Takes no parameters.
Example callreturns →
Import a telegram_mtproto userbot's existing chats as contacts — DM partners, groups, and channels — so everything the account already talks to becomes a valid send_message target without waiting for each chat to message first. Requires the manage_broadcasts permission. Reads the account's dialog list live (the userbot must be connected; large accounts can take up to a minute) and creates missing
Takes no parameters.
Example callreturns →
Return a compact application, flow, sequence, operation, and bot summary — the cheapest way to orient in a workspace. Read-only, no side effects. Deliberately omits variables and full flow graphs: use get_variable_context for variables, get_flow_context for a flow's topology, and get_application_context when you need flows, bots, and variables together.
Takes no parameters.
Example callreturns →
Search variable definitions by scope and keyword. Read-only. Returns { variables, total, returned, truncated } — compare returned against total to detect a cut-off result set and re-call with a higher limit. Values are withheld unless includeValues is true; variables marked secret stay redacted either way. Use the returned ids in `{{var|<id>}}` references.
Takes no parameters.
Example callreturns →
Return the full application-level automation context in one read-only call: every flow (with folders), connected bots, variables, sequences, and operations. This is the broad orientation call — prefer get_workspace_summary when you only need names and counts, since this response grows with workspace size. Operation graphs are hidden flows and appear only in the operations list, never in flows.
Takes no parameters.
Example callreturns →
Return a compact index of both installed and available marketplace modules, with each module's key, versions, description, actions, and triggers. Read-only. Start here when you need a capability the core action kinds do not cover; then call get_module_details for the exact input fields of one module, and install_module to add it. Returns a summary only — action input fields and setup requirements
Takes no parameters.
Example callreturns →
Return everything needed to use one module: action input fields and their types, trigger configuration, manual setup fields (credentials an operator must fill in the dashboard), and references to already-installed actions. Read-only. Call get_module_catalog first to obtain moduleKey, and call this again after install_module to read the installed action references you need when drafting actions. An
Takes no parameters.
Example callreturns →
Install an exact marketplace module version into an application and create any missing installed-template actions. Requires the manage_automation permission. Call get_module_catalog first to select the module and version, then get_module_details after installation to inspect setup requirements and installed action references. Safe to re-run: installing a version that is already installed only fill
Takes no parameters.
Example callreturns →
Return one flow's graph topology: its blocks, how they link, and a short summary per block. Read-only. Deliberately omits block data and action configs to stay cheap — once you know which block matters, call get_block_details for its full contents. This is the normal first step before editing an existing flow.
Takes no parameters.
Example callreturns →
Return the complete contents of one block: block data, action configs, HTTP request bodies, custom-code files, triggers, menu payloads, and media paths. Read-only. This is the heaviest read in the API — call get_flow_context first to find the block you need rather than walking a flow block by block. Always read a block before updating it, since update_block replaces the fields you send.
Takes no parameters.
Example callreturns →
Return the action-authoring contract: every supported action kind with its required fields, the placeholder ids for referencing entities created earlier in the same batch, the `{{var|...}}` / `{{sysvar|...}}` / `{{out|...}}` reference syntax, and the creatable block types. Read-only, takes no arguments, and needs no API key. Read this before drafting any apply_actions batch — it is the schema thos
Takes no parameters.
Example callreturns →
Return the flow-design rules that validation does NOT enforce: when to split a branch into its own flow, how navigation and menus must be wired, and worked examples. Read-only, takes no arguments, and needs no API key. Read this before any structural edit (new blocks, new branches, new flows) — a batch can pass validate_actions and still be badly structured, and these rules are what catch that.
Takes no parameters.
Example callreturns →
Search the library of reusable flow examples covering common business cases (lead capture, onboarding, payments, reminders). Read-only, needs no API key. Returns compact matches — id, title, summary, tags — with no flow body; pass an id to get_flow_example for the full example. Calling it with no arguments returns the top examples, and a query matching nothing returns an empty list rather than an
Takes no parameters.
Example callreturns →
Return one reusable flow example by id, optionally with a complete action batch you can adapt and pass to apply_actions. Read-only, needs no API key. Call search_flow_examples first to find the id.
Takes no parameters.
Example callreturns →
Dry-run validation of a proposed batch of flow-builder actions. Mutates nothing and is safe to repeat. OPTIONAL: apply_actions runs this exact validation itself and applies nothing when invalid, so calling validate_actions first is redundant — use it only to check a draft you do not intend to apply yet. Returns the same errors and warnings apply_actions would report. Note that passing validation d
Takes no parameters.
Example callreturns →
Validate and apply a batch of flow-builder actions — the single write path for editing flows, blocks, variables, broadcasts, sequences, and folders. Call this directly; a separate validate_actions call beforehand is unnecessary. Broadcasts have no dedicated tool and are managed here: create_broadcast makes a DRAFT (it owns its flow via data.flowId — add the message blocks in the same batch, no sep
Takes no parameters.
Example callreturns →
Send a message to ONE contact right now, outside any flow. For reaching many contacts use a broadcast instead. Target the contact with contactId (globally unique — preferred), or with platformId (the platform-side id, e.g. the Telegram user id). platformId is NOT globally unique: it is unique only per bot, so the same Telegram user talking to two of your bots is two contacts sharing one platformId
Takes no parameters.
Example callreturns →
List and search contacts in the application, paginated, newest first. Read-only. Filters combine as AND; search matches name, username, email, phone, and platformId. Returns compact contact summaries without variable values — use get_contact for one contact's variables. Remember platformId is unique only per bot, so the same person talking to two bots appears as two contacts.
Takes no parameters.
Example callreturns →
Return one contact's full profile plus every contact-variable value stored for them. Read-only. Values may hold personal data; variables of type SECRET are always redacted. Call list_contacts first to find the contactId.
Takes no parameters.
Example callreturns →
Create a contact manually — for imports or externally-sourced audiences; contacts who message a bot are created automatically. Requires the manage_broadcasts permission. platformId must be unique within the bot (duplicate fails with 409); botId may be omitted only when the application has exactly one bot. The variables map takes variable NAMES (or full folder paths when a name is ambiguous) — not
Takes no parameters.
Example callreturns →
Update a contact's profile fields and/or contact-variable values. Requires the manage_broadcasts permission. Only the fields you pass are changed — omitted fields keep their current value — so the call is idempotent. The variables map takes variable NAMES (or full folder paths when a name is ambiguous), not ids; an unknown name fails with 422 before anything is written. Variable writes propagate t
Takes no parameters.
Example callreturns →
List broadcasts in the application with status, schedule, and delivery counts. Read-only. Filters combine as AND. Note that delivery counts report messages attempted, not confirmed deliveries. Use get_broadcast_details for one broadcast's full breakdown. To CREATE or SEND a broadcast use apply_actions: create_broadcast makes a draft, update_broadcast (status SCHEDULED) schedules/sends it — see get
Takes no parameters.
Example callreturns →
Return full details for a single broadcast: status, schedule, recurrence rule, linked flow, and delivery breakdown by status. Read-only. Call list_broadcasts first to find the broadcastId. For per-message-block engagement stats use get_broadcast_analytics instead.
Takes no parameters.
Example callreturns →
Return engagement analytics for a broadcast: delivery breakdown by status plus per-message-block sent and clicked counts for its flow, over an optional date window. Read-only. Sent counts reflect messages attempted, not confirmed deliveries.
Takes no parameters.
Example callreturns →
Freeyour plan
$0 forever
- Every tool, no call limit
- No card, no account needed
- Source published under a licence you can read
- Runs on your machine — nothing of it reaches our gateway
- Nothing to cap, because nothing bills
What counts against your monthly calls
| Tool | Unit | Calls used | Out of the allowance |
|---|
Nothing here is billable. FlowCastle costs nothing to install and nothing to call, at any volume.
Call allowance · this installenforced at the gateway
Monthly allowance, in calls
—
—
Alert at 80% · then the tool returns a normal MCP error
Used this month: $8.42
$16.58 left
—Grade not published
No rule-by-rule report on file for this release
Two independent axes, because powerful and malicious are different questions. The grade is threat only. The capability level is blast radius, and it is never a penalty on the grade — it is priced as one subtract-only term in the score, where you can see it.
This listing is a hosted endpoint: the publisher runs it and we connect to it. The scanner reads packages and source, and neither exists to read here, so there is no grade — not a withheld one, an unmeasured one. What can be checked instead is on Installation: what it asks to reach and what it writes.
Release history
Pinned to 0.1.0 — the install command below asks for that release. A pin is part of an install, so it is kept for this visit and written down when you install.
0.1.0
undated
installedNo release note was published with this version.
—
no reviews yet
Reviews are earned
Only accounts with at least 50 real tool calls against this server in the last 90 days can post. Ratings are weighted by how much the reviewer actually uses it, and publishers can reply once per review.
Reviews are earned
Writing one takes an account with at least 50 real tool calls against FlowCastle in the last 90 days. That is the whole gate — there is no other way to post, which is why the counts beside each review are worth reading.
No reviews yet
Nobody has reviewed this listing. The rating on the card is the mean of the reviews written here and nothing else, so there is no rating until somebody writes the first — which takes an account with 50 real tool calls against it.