Furlow Mcp

io.github.virgilvoxPublished by GitHub account virgilvoxv1.0.1Updated Oct 24, 2026

Author FURLOW Discord bot YAML: validate specs, list actions/events/builtins, scaffold bots.

Overview

AI-generated overview

Lets an assistant author and validate FURLOW YAML specs for declarative Discord bots, listing available actions, events, and builtins.

What you can do
This server exposes tooling around FURLOW, a declarative Discord bot framework configured in YAML. It lets an assistant validate bot specifications, list the available actions, events, and builtin modules, and scaffold new bot projects. The framework itself covers 85 actions, 71 expression functions, 50 transforms, and 59 events, with CLI commands such as init, start, dev, validate, add, build, and export.
When to use it
Useful when building or maintaining a FURLOW-based Discord bot and you want an assistant to check YAML specs, discover which actions or events exist, or generate a starter project. Less relevant if you do not work with FURLOW or Discord bots.
Requirements
Runs as a local process over stdio, installed from the npm package @furlow/mcp, so Node.js and npm are needed. Desktop only; no remote endpoint. The manifest declares no authentication, environment variables, or headers. Running an actual bot separately requires Discord credentials such as DISCORD_TOKEN and DISCORD_CLIENT_ID, and optionally storage and dashboard settings.
Before you install
The server itself declares no credentials, but the FURLOW bots it helps author need secrets like DISCORD_TOKEN, DISCORD_CLIENT_ID, DISCORD_CLIENT_SECRET, DASHBOARD_SECRET, and DATABASE_URL, which should be kept out of shared files. Generated bots can send messages, moderate members, and persist state in a database; production deployments should run under a process supervisor and back up stored state.

Installation

In SourceWeft

  1. Open Furlow Mcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

FURLOW

Declarative Discord Bot Framework

[Maintained by @virgilvox] [License: MIT]

Build powerful Discord bots with YAML. No code required.

yaml
commands:  - name: ping    description: Check bot latency    actions:      - reply:          content: "Pong! ${client.ws.ping}ms"

Features

  • 85 Actions: messages, moderation, voice, channels, and more
  • 71 Expression Functions: date, math, string, array manipulation
  • 50 Transforms: pipe-based data transformations
  • 59 Events across Discord gateway, voice transitions, component interactions, and high-level FURLOW events (automod, scheduler, pipes)
  • Scoped State: global, guild, channel, user, and member scopes
  • Flows: reusable action sequences with parameters
  • External Integrations: HTTP, WebSocket, MQTT, TCP/UDP, webhooks

Quick Start

bash
# Install the CLInpm install -g @furlow/cli
# Create a botfurlow init my-botcd my-bot
# Add your Discord credentials to .envecho "DISCORD_TOKEN=your_token_here" > .envecho "DISCORD_CLIENT_ID=your_client_id_here" >> .env
# Startfurlow start

Example

yaml
version: "0.1"
identity:  name: "My Bot"
presence:  status: online  activity:    type: playing    text: "with FURLOW"
commands:  - name: hello    description: Greet someone    options:      - name: user        type: user        description: Who to greet    actions:      - reply:          content: "Hello, ${options.user.display_name || options.user.username}!"
  - name: roll    description: Roll a dice    options:      - name: sides        type: integer        description: Number of sides        min_value: 2        max_value: 100    actions:      - reply:          content: "🎲 You rolled **${random(1, options.sides || 6)}**"
events:  - event: member_join    actions:      - send_message:          channel: "${env.WELCOME_CHANNEL}"          content: "Welcome ${member.displayName}!"

CLI Commands

CommandDescription
furlow init [name]Create a new bot project
furlow start [path]Run the bot
furlow dev [path]Development mode with hot reload
furlow validate <path>Validate YAML specification
furlow add <builtin>Add builtin module
furlow build [path]Bundle for deployment
furlow export <path>Export Discord command JSON

Documentation

GuideDescription
InstallationSetup and requirements
Quick StartYour first bot
ConfigurationYAML specification
Actions ReferenceAll 85 actions
Expressions ReferenceFunctions and transforms
Events ReferenceEvent types
CLI ReferenceCommand-line interface
Pipes ReferenceExternal integrations
ExamplesComplete bot examples

Packages

PackageDescription
furlowCLI tool
@furlow/coreRuntime engine
@furlow/discordDiscord.js adapter
@furlow/schemaTypeScript types
@furlow/storageDatabase adapters
@furlow/builtinsPre-built modules
@furlow/pipesHTTP, WebSocket, MQTT, TCP/UDP, webhooks, database, file
@furlow/testingTest utilities

Production deployment

A short checklist for shipping a bot to production. Each item lines up with a runtime guarantee — skipping one usually shows up later as silent data loss, an unscheduled feature, or a publicly forgeable session.

Required environment

bash
# DiscordDISCORD_TOKEN=...DISCORD_CLIENT_ID=...
# Storage (pick one)DATABASE_URL=postgres://user:pass@host:5432/furlow   # production# or for single-server bots:SQLITE_PATH=/var/lib/furlow/bot.db
# Dashboard (only if running the web UI)DASHBOARD_SECRET=$(openssl rand -hex 32)             # required in NODE_ENV=productionDISCORD_CLIENT_SECRET=...DISCORD_CALLBACK_URL=https://dashboard.example.com/auth/discord/callback

The dashboard refuses to start in NODE_ENV=production without DASHBOARD_SECRET — there is no fallback default. WebSocket connections also require an authenticated session; unauthenticated clients are rejected at upgrade time and cannot subscribe to guild streams.

Storage

  • Use Postgres for any deployment that runs more than one process or needs point-in-time recovery. The SQLite adapter is fine for single-server bots and tests, but write contention degrades quickly past a few thousand active users.
  • Run database migrations on deploy. The SQLite adapter creates tables on demand; Postgres deployments should pre-create the tables defined in your state.tables: block.
  • Back up the database. Builtins persist real state (warnings, levels, AFK status, ticket transcripts); none of this is reconstructible.

Scheduling and voice

  • The CLI starts a CronScheduler that emits scheduler_tick every 60s. Builtins that rely on it (giveaways, polls, reminders) need the scheduler running — there is no separate cron process.
  • Voice playback requires the @discordjs/voice peer plus ffmpeg on the PATH. The voice_track_start / voice_track_end events used by the music builtin only fire when the voice manager is initialized.

Process supervision

  • Run furlow start under a process supervisor (systemd, pm2, Kubernetes Deployment) that restarts on exit. The bot does not self-daemonize.
  • Forward SIGTERM so the gateway connection closes cleanly. The CLI flushes pending state on shutdown; killing with SIGKILL can lose the last batched writes.

Dashboard hardening

  • Terminate TLS in front of the dashboard (nginx, Caddy, a load balancer). The session cookie sets secure: true in production and will not be delivered over plain HTTP.
  • Restrict the OAuth callback URL in the Discord developer portal to the exact DISCORD_CALLBACK_URL you ship.
  • POST endpoints whitelist their accepted fields and reject unknown or wrong-typed keys with 400. If you extend a settings shape, update the whitelist in apps/dashboard/server/routes/api.ts.

Observability

  • /health returns process uptime; wire it to your liveness probe.
  • /metrics exposes Prometheus-format counters. Add a scrape job pointed at the dashboard process.
  • The CLI honors --verbose for structured per-event logging during incident triage.

License

MIT

Source: README.md at commit 1885623

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v1.0.1LatestSep 16, 2026

Score

40% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts

    Declare a license in the repository or the registry entry.