Falcon Builder

Falcon Builder by NeoSky AI is a no-code platform for production AI agents.

CommunityOnlineNo sign-inGlobalFreeCan modify data

What it can do

  • Whoami: Identity, mode, and workspace membership. Call this first in a session. Returns the workspace list needed by switch_workspace.
  • Switch Workspace: Set the active workspace for workspace-scoped tools (list_workflows). Pass a workspace_id from whoami.
  • List Workflows: Workflows in the active workspace (or an explicit workspace_id), newest-updated first. Filter by name substring.

What data it sees

Do you need an account

No: the server works without sign-in

Falcon Builder by NeoSky AI is a no-code platform for production AI agents. This MCP server lets your AI assistant work directly in your Falcon Builder workspace: inspect workflows and executions, read logs and version history, create and edit draft workflows and interfaces, run test executions, and publish or roll back to production.

Access is permission-scoped. Read is always included. Edit drafts, Run workflows, and Publish & rollback are granted separately, so a token can be read-only. OAuth for claude.ai, Claude Desktop, and ChatGPT; access tokens for Claude Code, Cursor, VS Code, and Gemini CLI.

Available on every Falcon Builder plan, including Free. Test runs count against your plan's execution limit.

How to connect

How to connect Falcon Builder to Claude

The server address to paste into Claude settings:

https://falcon-builder.run.tools

  1. Open Claude (claude.ai or the desktop app).
  2. Go to Settings → Connectors.
  3. Click Add custom connector.
  4. Paste the server address copied below into Remote MCP server URL and click Add.
  5. In a chat, click + → Connectors and switch the new connector on.

Custom connectors are available on Free, Pro, Max, Team and Enterprise plans (Free is limited to one). On Team and Enterprise an organization Owner adds the connector first under Organization settings → Connectors.

Authorization

After you click Add, a sign-in window for the service opens. Sign in with your own account and approve access. Claude never sees your password.

How to connect Falcon Builder to ChatGPT

The server address to paste into ChatGPT settings:

https://falcon-builder.run.tools

  1. Open ChatGPT in a browser (chatgpt.com). A Plus, Pro, Business, Enterprise or Edu plan is required.
  2. Turn on developer mode once: Settings → Apps → Advanced settings → Developer mode.
  3. Open Settings → Connectors and click Create.
  4. Fill in the form: Name (anything), Description (one line about what the service does), MCP server URL (copy it below).
  5. Under Authentication choose OAuth if the service requires sign-in, otherwise None. Click Create.
  6. In a new chat open + → Apps/Connectors and enable the connector.

OpenAI has renamed this section before (Connectors → Apps/Plugins). If the label differs, search settings for "developer mode". On Business/Enterprise workspaces an admin must allow custom connectors first.

Authorization

On first use ChatGPT opens the service's sign-in window. Sign in and approve access.

How to connect Falcon Builder to Cursor

The server address to paste into Cursor settings:

https://falcon-builder.run.tools

Fastest: click Open in Cursor below and confirm the prompt.

Manually:

  1. In Cursor open Settings → Cursor Settings → MCP and click Add new global MCP server.
  2. Paste the JSON copied below into ~/.cursor/mcp.json (per project: .cursor/mcp.json in the repo root).
  3. Save the file. The server appears in the MCP list; authorize it there if asked.

Authorization

If the service needs sign-in, an authorize button appears next to the server in the MCP list.

Server tool list (28)

Raw names from tools/list. Only developers need these.

whoamiIdentity, mode, and workspace membership. Call this first in a session. Returns the workspace list needed by switch_workspace.
switch_workspaceSet the active workspace for workspace-scoped tools (list_workflows). Pass a workspace_id from whoami.
list_workflowsWorkflows in the active workspace (or an explicit workspace_id), newest-updated first. Filter by name substring.
get_workflowFull diagnostic view of one workflow: publish state, draft-vs-live drift, graph analysis with the expected webhook routing (inline / worker handoff / worker up-front), node list, webhook trigger configs, and the last 10 executions. Accepts an id prefix or a name substring.
get_workflow_definitionFull nodes+edges JSON for the draft or the published live version. Size-capped; use get_workflow for a compact node list on very large graphs.
list_executionsRecent executions for a workflow, newest first. Filter by status.
get_executionDebug-first forensics for one execution: status/timing, heartbeat age with an alive/dead verdict, BullMQ queue-job state (primary + handoff), ALL WARN/ERROR logs, a log tail, and a node I/O summary. Node payloads are stripped by default — pass expand_node_ids to include capped input/output for specific nodes. Accepts an id prefix.
get_execution_logsPaginated raw logs for an execution, oldest first. Filter by level. Messages are truncated to 300 chars.
list_agentsAgents in the workspace (needed to create a workflow — every workflow lives inside an agent). Filter by name substring.
validate_workflowPre-flight checks on the DRAFT: unknown node types, dangling edges, missing credentials, empty conditions, empty Agent Loop prompts, empty AI Judge input/criteria, unreachable nodes, unknown {{template}} roots, and the webhook routing verdict. is_runnable=true means no blocking errors. Run after every edit and before publishing.
create_workflowCreate a new DRAFT workflow inside an agent, optionally with initial nodes/edges. Nodes: { type, id?, label?, config?, position? } (same shape as edit_workflow add_node); edges: { source, target, source_handle?, target_handle? }. The draft is not published and receives no production traffic until a human publishes it in the editor. Requires the edit_draft scope.
edit_workflowApply structured patch operations (add_node / update_node / remove_node / add_edge / remove_edge) to the DRAFT. Production keeps running the published version; a human publishes in the editor. Requires the edit_draft scope and the expected_updated_at from a fresh get_workflow or validate_workflow read (refuses if the draft changed underneath you). update_node shallow-merges config by default.
list_workflow_versionsPublished version history for a workflow, newest first, with the live version marked. Use before rollback_workflow.
publish_workflowSnapshot the current draft as a new immutable version and point production at it. FROM THIS MOMENT live traffic runs the draft you validated. Requires the publish scope, confirm=true, a fresh expected_updated_at, and a draft with zero validation errors. Rollback is available via rollback_workflow.
rollback_workflowRestore a previously published version over the draft and republish it as a NEW version (same as Restore + Publish in the editor — history stays linear). Production switches to the restored graph. Requires the publish scope and confirm=true. NOTE: this overwrites the current draft.
run_workflowExecute a workflow on the worker queue with the given input — draft by default (test your edit before publishing), or the live version. Nodes fire REAL side effects (HTTP calls, SMS, emails) and the run counts against the workspace execution limit. Requires the execute scope and confirm=true. Returns the execution id to poll with get_execution.
rerun_executionsReplay executions that already ran, with their ORIGINAL input — one, several, or every finished execution of a workflow (filter by status, date, and input_match on the stored payload). Each target becomes a NEW execution; originals are left untouched. By default each run replays the definition it originally executed (which="same"); pass "live" or "draft" to replay against the current graph instead. EVERY replay fires REAL side effects and counts against the workspace execution limit, so re-running 20 runs sends 20 sets of emails/SMS/HTTP calls — call with dry_run=true first: it fires nothing and reports total_matching, so you can size the job before spending it. In-flight runs (PENDING/QUEUED/RUNNING/WAITING) are skipped, never re-run. Batches are capped at 50; a workflow-mode reply hands back next_batch with the exact arguments for the next one (it pins until= so your own replays never re-enter the window). Requires the execute scope and confirm=true.
duplicate_workflowServer-side copy of a workflow (all node configs, edges, retry settings) into a new INACTIVE, unpublished draft — works on definitions of any size because nothing round-trips through context. Optionally rename and/or place in another agent (same workspace). Then use get_workflow_node + edit_workflow to change the details (name fields, AI prompts). Requires the edit_draft scope.
duplicate_agentDuplicate an agent and ALL of its workflows (with interfaces + redaction config) into a new DRAFT agent in the same workspace — server-side, same semantics as the editor. Credential references are kept. Requires the edit_draft scope.
get_workflow_nodeRead a single node's full config from the DRAFT — the way to inspect and then edit workflows whose full definition exceeds the get_workflow_definition size cap. Accepts node_id or a label substring. Pair with edit_workflow update_node.
list_interfacesHosted end-user interfaces (Form / Chat pages at /i/<slug>) in the workspace, with access mode (PUBLIC / PASSWORD / WORKSPACE_AUTH / EMAIL_ALLOWLIST / SSO) and publish state. A workflow can carry many interfaces — one per audience — so per-company password gates never require duplicating the agent. Filter by agent or workflow (id prefix or name substring).
get_interfaceFull detail for one end-user interface by id prefix or slug: appearance config, access mode, embed-domain allowlist, and (EMAIL_ALLOWLIST mode) every access rule. Secrets (password hash, SSO client secret) are never returned. The updated_at is informational — interface writes are last-write-wins like the dashboard.
create_interfaceCreate a new Form or Chat interface bound to a workflow — the way to grant a new audience access to an existing agent WITHOUT duplicating it (e.g. one PASSWORD interface per prospect company on the same intake workflow; each gets its own /i/<slug> URL and password). Starts UNPUBLISHED; publish_interface makes it live. Note: PASSWORD-mode chat sessions are anonymous and per-browser; use EMAIL_ALLOWLIST for durable per-person identity and server-side conversation history. Requires the edit_draft scope.
update_interfaceChange an interface's access_mode, set/rotate/clear its password, edit the embed-domain allowlist, retitle, change the slug, or merge appearance config. Publish state is NOT touched here — use publish_interface. If the interface is already published, changes take effect for end users immediately. Requires the edit_draft scope.
publish_interfaceFlip an interface live or dark. Publishing makes the /i/<slug> URL reachable by end users under the configured access mode FROM THIS MOMENT; unpublishing 404s it. Requires the publish scope and confirm=true.
add_interface_access_ruleAdd an EMAIL (alice@acme.com) or DOMAIN (acme.com) rule to an EMAIL_ALLOWLIST interface — the way to grant one person or one company access to a shared interface without duplicating anything. Allowed users verify by OTP and get durable per-person conversation history. Idempotent (re-adding an existing rule is a no-op). Requires the edit_draft scope.
remove_interface_access_ruleRemove an EMAIL or DOMAIN rule from an interface allowlist by value (as shown by get_interface). Revokes future logins; sessions already open survive until they expire. Requires the edit_draft scope.
delete_interfacePermanently delete an interface. Cascades its access rules, end-user identities, feedback, and stored conversations — this is NOT undoable, and unlike unpublishing it destroys end-user history. Prefer publish_interface with published=false to take a surface dark. Requires the edit_draft scope and confirm=true.