The Agent Server: Let the Bot Look, Not Hold the Keys 🫡

The buzz

An AI agent can read the launchpad, quote a trade, and line one up for you. Whether it can press the button is a decision you make in the environment of the process, not a thing the agent can talk its way into. The limits live in the server, not in the model's good manners. Few understand. 🧠

The boring part

What it is

An MCP (Model Context Protocol) server, started with fly-mcp or fly mcp, that speaks over stdio. It runs on your machine with your RPC and, if you give it one, your key. No FLY server is involved in reading or trading (saving a launch's logo and links is the one exception, below). It is hand-written, with no protocol library behind it, because a process that can hold a key should not have a long tree of packages to trust.

Configure it

{
  "mcpServers": {
    "fly": {
      "command": "node",
      "args": ["path/to/packages/sdk/bin/fly-mcp.mjs"],
      "env": {
        "FLY_RPC_URL": "https://your-rpc.example/KEY",
        "FLY_PRIVATE_KEY": "0x... a small separate wallet only ...",
        "FLY_ENABLE_WRITES": "1",
        "FLY_MAX_PER_TX": "ETH=0.005,USDG=10"
      }
    }
  }
}

Leave the last three variables out for a read-only agent. It can list launches, quote and prepare, and the send tool does not exist at all: it is not in the tool list.

The package is not published yet (Builders and Agents), so the path above is to a checkout of the repository.

The tools

Tool	What it does	Sends?
`fly_info`	network, RPC host, whether a signer and writes are enabled, contracts	no
`fly_terms`	launch fee and the fixed curve shape	no
`fly_list_launches`	newest first, with state, progress and price	no
`fly_get_launch`	one launch by id or token address	no
`fly_balances`	ETH, USDG, $FLY and extras for a wallet	no
`fly_claimable_fees`	fees credited to a wallet	no
`fly_quote_trade`	what a buy or sell would give, along the best route	no
`fly_quote_swap`	a swap between listed assets	no
`fly_prepare_trade`	build and simulate a buy or sell; returns a `prepared_id` and a summary	no
`fly_prepare_swap`	the same for a swap	no
`fly_prepare_launch`	the same for creating a token	no
`fly_prepare_claim`	the same for claiming credited fees	no
`fly_send_prepared`	sign and send a prepared transaction	yes (only with a signer and the limits)
`fly_prepare_details`	preview saving a launch's logo, description and links (creator only)	no
`fly_save_details`	sign as the creator and save them on the launchpad	yes (only with a signer and `FLY_ALLOW_DETAILS=1`)

Every tool except fly_send_prepared is marked read-only in the protocol; fly_send_prepared is marked destructive. Tool arguments are checked strictly: unknown names, wrong types and oversized strings are rejected.

The send path

The agent calls a fly_prepare_* tool. The server simulates it and returns the plan, any warnings, whether the limits would allow it, and how many seconds are left (120).
The agent shows you that plan. The server's own instructions tell it to send only after you explicitly approve that exact transaction.
fly_send_prepared takes the prepared_id. It is single use: after a send, or after the 120 seconds, the id is gone and the agent has to prepare again. Sends are at least 5 seconds apart.
Inside, the SDK does everything in What send does: the limits, an exact approval, a fresh simulation, gas for graduation, the receipt.

Logo, description and links

These are stored by the launchpad website, not on chain, so they work differently: the two details tools exist only when a signer is configured and the operator sets FLY_ALLOW_DETAILS=1. Saving costs no gas and moves no funds, but it is public and replaces what was there, so the same rule applies: prepare, show you, save only after you approve that exact save. It is the only thing the agent server sends to a FLY server.

A logo has to be a file inside the folder you name in FLY_LOGO_DIR. Without that variable an agent cannot upload a logo at all, and a path that leaves the folder is refused, so an agent cannot be talked into uploading something else from your disk. The file must also really be a PNG, JPEG, GIF or WebP up to 1 MB.

Who holds the limits

The same variables as the SDK: FLY_ENABLE_WRITES, FLY_MAX_PER_TX, FLY_MAX_PER_DAY, FLY_MAX_SLIPPAGE_BPS, FLY_ALLOW_TOKENS, FLY_ALLOW_LAUNCH, FLY_ALLOW_OTHER_RECIPIENT, and for details FLY_ALLOW_DETAILS and FLY_LOGO_DIR. They are read when the server starts, from its environment. No tool argument can change them. Nothing is enabled by default, and an asset with no per-transaction cap cannot be spent. Proceeds can only go to the signing wallet, and launching a token needs its own switch.

Token names are strangers' text

Names, symbols and descriptions of launches are written by whoever launches. A token can be called anything, including something that reads like an instruction. So:

tools that return creator text open with a note saying that text is data, not instructions;
the server's instructions tell the agent the same, and to tell you if a launch's text tries to direct it;
symbols are never trusted for identity: assets are resolved to the registered pairing assets, and launch tokens are addressed by id or address.

This lowers the chance of a bad outcome. It cannot remove it, which is why the limits above are enforced by the server and why your MCP client's own approval prompt for the destructive tool matters: keep it on, and read what it shows.

Keep the wallet small

The key in the environment is a hot wallet. Fund it with what you are comfortable letting an agent trade with, and nothing else. Never put a main wallet or a hardware wallet that holds real funds behind it.

Back to Builders and Agents.