Skip to main content
Glama
arcnow-io

@arcnow/mcp

Official
by arcnow-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

@arcnow/mcp

An MCP server that lets an AI assistant use arcnow.io on Arc: read the bonding curves, quote a trade with its full fee breakdown — on a token's curve before it graduates, or in its Uniswap v4 pool after — see how close a token is to graduating, and, only if the operator explicitly turns it on, launch, buy, sell and rescue a stranded migration.

Every chain interaction goes through @arcnow/sdk, pinned to an exact published version in pins.json. Nothing here encodes a call or computes a curve.

Install and run

The server is on npm as @arcnow/mcp (Node 22.12 or newer). Run it straight from the registry:

npx -y @arcnow/mcp                  # read-only. The default, and the useful part.
npx -y @arcnow/mcp --allow-writes   # can spend, if ARCNOW_PRIVATE_KEY is in the environment.

Every client below runs that same command with ARCNOW_MCP_NETWORK set. The examples say arc-mainnet, where arcnow.io is live — Arc mainnet, chain 5042. arc-testnet is the rehearsal network: the same contracts at other addresses, with test funds. With the variable unset the server starts on arc-testnet, so nobody is pointed at real money by omission.

Write mode, in every client: add --allow-writes to the arguments and put the signing key in a file the server reads through ARCNOW_PRIVATE_KEY_FILE — never the key itself in a client config, which gets committed and screenshotted. Read-only needs no key at all. On arc-mainnet every write is real money: the spend caps below are what bounds a mistake, and the server says so at startup and in every session. Every variable is in Configuration; examples/ has both shapes — the writes-enabled one on arc-testnet, as a rehearsal.

Claude Code

claude mcp add --env ARCNOW_MCP_NETWORK=arc-mainnet --scope user arcnow -- npx -y @arcnow/mcp

--scope is local (this project, you only; the default), project (checked into .mcp.json at the project root, shared with the team) or user (every project). The project-file form:

{
  "mcpServers": {
    "arcnow": {
      "command": "npx",
      "args": ["-y", "@arcnow/mcp"],
      "env": { "ARCNOW_MCP_NETWORK": "arc-mainnet" }
    }
  }
}

Claude Desktop

claude_desktop_config.json — macOS ~/Library/Application Support/Claude/claude_desktop_config.json, Windows %APPDATA%\Claude\claude_desktop_config.json:

{
  "mcpServers": {
    "arcnow": {
      "command": "npx",
      "args": ["-y", "@arcnow/mcp"],
      "env": { "ARCNOW_MCP_NETWORK": "arc-mainnet" }
    }
  }
}

Codex

~/.codex/config.toml (or .codex/config.toml in a project):

[mcp_servers.arcnow]
command = "npx"
args = ["-y", "@arcnow/mcp"]

[mcp_servers.arcnow.env]
ARCNOW_MCP_NETWORK = "arc-mainnet"

Or from the CLI: codex mcp add arcnow --env ARCNOW_MCP_NETWORK=arc-mainnet -- npx -y @arcnow/mcp.

Cursor

.cursor/mcp.json in the project (or ~/.cursor/mcp.json for every project):

{
  "mcpServers": {
    "arcnow": {
      "command": "npx",
      "args": ["-y", "@arcnow/mcp"],
      "env": { "ARCNOW_MCP_NETWORK": "arc-mainnet" }
    }
  }
}

VS Code (Copilot agent mode)

.vscode/mcp.json — note the key is servers, not mcpServers:

{
  "servers": {
    "arcnow": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@arcnow/mcp"],
      "env": { "ARCNOW_MCP_NETWORK": "arc-mainnet" }
    }
  }
}

For write mode, VS Code's inputs can prompt for the key-file path instead of writing it into the file; see its MCP documentation for the ${input:…} form.

Gemini CLI

~/.gemini/settings.json (or .gemini/settings.json in a project):

{
  "mcpServers": {
    "arcnow": {
      "command": "npx",
      "args": ["-y", "@arcnow/mcp"],
      "env": { "ARCNOW_MCP_NETWORK": "arc-mainnet" }
    }
  }
}

Or gemini mcp add -e ARCNOW_MCP_NETWORK=arc-mainnet arcnow npx -y @arcnow/mcp.

Windsurf, Cline

Both take the generic mcpServers JSON above — the same command, args and env — in their MCP settings file.

From source

Clone arcnow-io/arcnow-io-mcp, then npm ci && npm run build && node dist/index.js; the SDK comes from npm.

Related MCP server: arcium-mcp

The two rules this server is built around

1. A private key is never a tool argument

No tool here takes a key, a mnemonic or a credential of any kind. The signing key is read once, at startup, from ARCNOW_PRIVATE_KEY or a file named by ARCNOW_PRIVATE_KEY_FILE, and from nowhere else.

This is not a claim about environment variables being safer in general. It is about where a tool argument goes. An argument is written by a model into a transcript: to the model provider, into the client's logs, into the context of every later turn, and into the bug report somebody pastes into an issue. A key that has been through a tool call has been published, and there is no un-publishing it.

So the schemas declare no such field, and — because declaring nothing is not enough — every schema is strict. An argument this server did not ask for is a refusal, not a silently dropped key, and if the field was named like a credential the refusal says so and says to rotate it. test/unit/no-key-arguments.test.ts walks every published schema and asserts both halves.

2. Read-only is the default, and writing is the operator's decision

With an empty environment this server can read everything and spend nothing. The write tools are not published at all: a model that cannot see arcnow_launch does not offer to launch anything.

Writing requires --allow-writes (or ARCNOW_MCP_ALLOW_WRITES=1) and a key, from whoever starts the process — a person editing a config file, not a model mid-conversation. The mode is printed on stderr at startup and reported by arcnow_network, so nobody has to guess which one they are talking to.

Two edge cases, both deliberate:

  • A key with no opt-in starts read-only and warns that the key is present and unused. A key is not consent to spend it.

  • An opt-in with no key refuses to start. The operator asked for something this process cannot do, and a server that quietly downgrades produces its failure later, in the middle of somebody's trade.

The tools, and why each one exists

Nine read tools, always published. Six write tools, published only on opt-in.

Read

tool

what it answers

arcnow_network

Which chain, which contracts, which graduation venues, whether a v4 router is configured for graduated tokens, and which mode this server is in. The first call of any session that might trade.

arcnow_quote_tokens

The quote tokens a launch may use — native USDC and the ERC-20s the quote registry allowlists, such as EURC — each with its symbol, name, decimals, address, whether it is native, its launch fee in its own units (zero on both networks: launching is free, and the figure is read from the registry rather than assumed), whether the registry accepts it now, and this server's spend cap for it. At most three eth_calls. On a chain with no quote registry, it says so, shows the error, and lists the network's own quote-token metadata with nothing known to be accepted.

arcnow_list_tokens

Recent launches, newest first, from the launchpad's Launched log, back to the block it was deployed in. Reports the block window it actually covered — see the SDK gap.

arcnow_token

One token in full: metadata, its quote token (address, symbol, decimals, native or ERC-20), its curve's parameters (r0Wad, y0Wad), curve state, price, progress, and where it trades now — its curve, its v4 pool (with the router, whether it reaches the pool, the PoolManager, what a trade there costs — the hook's 0.80% and the pool's 0.20% LP fee, read off the pool — how the hook splits its part, and what it holds accrued), or nowhere. Takes a token or a curve address.

arcnow_quote_buy

What an amount of the token's quote (quoteIn) would buy, wherever the token trades. On a curve: tokens out, the 1% fee split four ways — creator, platform, referrer, protocol — with exactly who receives each share, the average fill price, minimum-out floors at four tolerances. In a pool: a quote that says it is a pool quote, with the fee hook's 0.80% and the pool's own 0.20% LP fee apart (1.00% in all, both read off the pool), the hook's three-way split, the average fill against the pool's spot price, and the price impact.

arcnow_quote_sell

The same for a sell — plus, on a curve, that selling needs no approval, ever, and in a pool, that it does, and how much the holder has approved already.

arcnow_quote_launch

What a launch in a given quote (native USDC by default, or an ERC-20 by symbol or address) would cost before anything is spent: the launch fee the registry reports (zero — launching is free), the initial buy and its own trade fee, with the predicted token and curve addresses.

arcnow_platform

A platform's four-way fee split, its default migrator and its curve template — every share printed both as bps of the fee and as a percentage of a trade.

arcnow_list_platforms

The registry's actual enumeration. Complete, unlike the token list.

The read tools are the valuable part. An assistant that can answer what is this token, what would 50 EURC buy me, how close is it to graduating with no key anywhere near it is useful to far more people than one that can trade.

Three things the read tools go out of their way to say, because each is a mistake that costs money:

  • A spot price is not a fill price. The curve integrates price across an order, so a buyer pays a rising price over their own trade. Every quote reports an average fill price next to the spot price, and the tool descriptions tell the model to quote rather than multiply.

  • A share of the fee is not a share of the trade. 3000 bps of the fee is 0.30% of a trade. Both are printed, every time. The fee has four parties — creator, platform, referrer, protocol; arcnow.io's own split is 3000 / 3500 / 1000 / 2500 — and no developer share: no tool takes a developer.

  • Graduated and migrated are different states. A curve can have stopped trading permanently while its pool was never created, and then the token trades nowhere. That is reported as its own thing, with the rescue named.

  • A pool quote is not a curve quote. It says so, and it names two charges, not one: the fee hook's 0.80%, taken in the pool's quote and split creator / platform / protocol, and the pool's own 0.20% Uniswap LP fee — 1.00% in all, the same as the curve charged. Both rates are read off the pool, never assumed.

Write

tool

what it does

irreversible?

arcnow_launch

Launches a token and its curve, priced for life in the quote it names. For an ERC-20 quote the SDK approves the launchpad for exactly the total first, and the result reports that approve.

Yes, in every respect.

arcnow_buy

Buys wherever the token trades — its curve, or its v4 pool once migrated. Spends quoteIn, in the token's quote; an ERC-20 quote is approved for exactly that first, and the approve is reported.

No — the tokens can be sold back, at a price.

arcnow_sell

Sells wherever the token trades. Receives the token's quote. In a pool, grants the router an approval only when told to, for exactly the amount sold.

No

arcnow_migrate

Creates the pool for a curve that graduated without one.

No — it only ever adds a market.

arcnow_withdraw_refund

Claims the quote a curve credited after a failed transfer.

No — it recovers funds.

arcnow_register_platform

Deploys a new PlatformConfig. Protocol admin only.

The config is permanent.

arcnow_launch's description says, in as many words, that the name, symbol, supply, curve shape and graduation venue are fixed at that transaction and can never be changed by anyone, that there is no admin key that can fix a typo in a symbol, and that the only remedy is another launch and another fee. It also requires acknowledgeIrreversible: true, which is not security — a model can set a boolean — but does make the assertion explicit in the transcript.

How a write is gated, in order

  1. The operator's opt-in. Not published, and refused by name if called anyway. (A cached tool list is why the refusal exists as well as the omission; "unknown tool" reads as "you guessed wrong" and invites a model to try variations.)

  2. The operator's ceilings, one per quote token. See spend caps. Not arguments, and they cannot be raised from a tool call.

  3. The caller's stated ceiling. Every spending tool requires maxTotalCost, in the token's quote: the most the caller believes this call will cost. A fresh quote is taken inside the call and compared against it. That catches a quote that went stale between being shown to a person and being acted on, a curve that moved, and a model talked into a bigger number than the conversation agreed to — none of which one session-wide ceiling catches.

  4. No default slippage. slippageBps is required on every trading tool. Zero means "fill me at any price", which on a public mempool is a donation, so it has to be typed rather than omitted.

  5. Nothing that does not apply. A curve trade pays the sender and has no recipient; a pool swap has no referrer and cannot graduate anything, so gasLimit guards nothing there. Each is refused on the venue it does not exist on, before anything is quoted or sent — never silently dropped. The SDK refuses the same things; this server says so first.

  6. The report. Each tool states the exact cost and the exact effect, and says afterwards what actually happened.

None of that makes an assistant trustworthy with money. It makes the blast radius a number somebody chose.

The gas trap, which this server handles for you

A graduating buy migrates the curve in its own transaction, under a bounded gas budget whose failure the curve catches rather than reverting. So eth_estimateGas — which searches for the lowest limit at which the transaction still succeeds, and a graduating buy succeeds either way — converges on exactly the limit at which the migration is starved. The buy fills, the curve graduates, the refund is correct, and the pool is simply never created. There is no revert and no error anywhere.

arcnow_buy therefore takes a fresh quote, and when that quote says the buy graduates it sends an explicit 8,000,000 gas limit rather than letting the node estimate one. (The curve budgets 6,000,000 for the migrator and keeps 100,000 back; a limit is a ceiling, not a charge.) A gasLimit below 6,200,000 on a graduating buy is refused outright. The result reports migratedInThisTransaction, which is a different question from whether the curve graduated — and when the migration was starved anyway, it names arcnow_migrate as the permissionless rescue.

Trading a graduated token

A token's market moves once, irreversibly: from its bonding curve to a Uniswap v4 pool, when the curve graduates and migrates. The quote and trade tools go through the SDK's client.trade(token), which decides the venue, so the same four tools work across that line. Three states, told apart out loud:

state

quote

buy / sell

on its curve

a curve quote, as before

through the curve; recipient refused

graduated and migrated

a pool quote, labelled as one

through arcnow.io's router; gasLimit, referrer refused

graduated, not migrated

refused: tradeable nowhere until migrate()

refused, naming arcnow_migrate

What a pool quote contains. The SDK prices a pool trade by simulating the real swap through the router, so the figures are the real fill with two charges inside them. The quote takes them back out and names each: the fee hook's 0.80%, which it takes in the pool's quote and splits creator 5000 / platform 1875 / protocol 3125 bps (a pool swap has no referrer), and the pool's own 0.20% LP fee — the pool key's fee, in hundredths of a bip — which Uniswap charges and the pool's liquidity keeps. 1.00% in all, the same as the curve. Every rate comes from the SDK's Pool.fees(), which reads the hook's feeBps() and feeConfigOf() and the key; this server holds no fee constant, so a pool whose key carries another LP fee is reported at the fee it carries. It shows the average fill price, the pool's spot price, and the price impact between them. The SDK has no reader for a pool's price, so the spot price is the SDK's own quote of a probe buy with both fees taken out — 0.000001 of an 18-decimal quote, or 10,000 raw units of a smaller one (0.01 EURC), so the fees' raw-unit rounding stays below one part in ten thousand — and the report says so.

The pool's quote is the SDK's. A v4 key orders its currencies by address: native USDC is always currency0, an ERC-20 such as EURC can be either. Nothing here reads currency0 as the quote; arcnow_token says which currency of the key the SDK found the quote to be.

The sell approval. A curve sell needs no approval; a pool sell does, because the router pulls the tokens with transferFrom. That approval is a separate transaction granting spending rights, and it is the one thing this server does that grants rights rather than spending money. So arcnow_sell:

  • never sends it unless the call says approveRouter: true. Without it, a sell whose allowance is short is refused, nothing is sent, and the refusal says exactly what the approval would be: token, owner, spender, amount;

  • approves exactly the amount being sold, never an unlimited allowance, and only if the existing allowance does not already cover the sale;

  • reports it — token, owner, spender, amount, transaction, and the allowance left afterwards — including when the sell that followed it then failed, in which case it says the approval still stands.

approveRouter on a curve sell is refused: nothing would use it.

A revert inside the pool. Uniswap v4 wraps a revert from inside a hook, and a failed transfer out of the PoolManager, in WrappedError (0x90bfb865). The SDK unwraps it: a known inner error keeps its own code with the wrapper layers on details.wrappedBy, and an empty one is WrappedRevert, with each layer named — NativeTransferFailed or ERC20TransferFailed for a transfer. This server names the failed transfer from the decoded layers, points at arcnow_quote_buy for a smaller amount, and shows the SDK's reason and the layers once. It adds no cause of its own.

How a failure is said. A code the SDK raises itself (SDK_ERROR_CODES) is a refusal made before any transaction — AddressIsNotACurve, UnknownCurveVersion, UnknownHookVersion and the rest. A decoded contract error or revert failed on-chain. RpcFailure could not reach the chain: the public endpoint rate-limits, and that says nothing about the token.

One curve, on two networks

arcnow.io has one bonding curve — the constant-product curve, arcnow/bonding-curve@4.x.x, priced in a quote token, with parameters r0Wad (the virtual quote reserve at launch, in WAD) and y0Wad (the virtual token reserve at launch) — launched through one contract stack, and a fee hook, arcnow/arc-now-fee-hook@4.x.x, that takes its 0.80% in the pool, accrues each fee as a PoolManager claim and pays it out at the start of a later swap. The same build is live on Arc mainnet (arc-mainnet) and Arc testnet (arc-testnet), at different addresses; a token address from one means nothing on the other, and the server's instructions say which network a session is on.

  • Nothing a tool prints names a curve kind or a stack. There is one of each. arcnow_token prints the curve's own parameters, and a pool trade reports the fees it paid out from earlier trades (FeesDistributed) apart from the trader's fill.

  • Any other version is refused by name, and never priced. A curve or a platform of another version — the retired multi-quote stack, @3.x.x, which carried a developer share and whose data was wiped; the @2.x.x contracts before it; the retired linear curve, @1.x.x — is the SDK's UnknownCurveVersion, naming the version, before any quote or send. A fee hook of another version — the @3.x.x hook that charged 1% in the pool included — is UnknownHookVersion, and neither its accrual nor its rates are read.

  • An address that is not a curve is refused by name. The SDK's AddressIsNotACurve for an arcnow.io token's address is followed to its curve; for anything else — an ordinary ERC-20, an account, nothing at all — it is the refusal, saying the address is not an arcnow.io token either.

  • arcnow_list_tokens reads the one launchpad, back to the block its stack was deployed in (21,179,866 on Arc mainnet, 62,386,232 on Arc testnet).

Configuration

Everything is an environment variable, because an MCP client's config file is where an operator's decisions belong. See examples/ for a read-only and a writes-enabled client config.

variable

default

what it does

ARCNOW_MCP_NETWORK

arc-testnet

The network preset: arc-mainnet (Arc mainnet, chain 5042, where arcnow.io is live — real money) or arc-testnet (the rehearsal, chain 5042002). Both come from the SDK's networks.json; a name it does not know refuses to start, naming the two it does. The default is the rehearsal on purpose.

ARCNOW_MCP_NETWORK_FILE

unset

A path to a JSON document in the SDK's CustomNetwork shape, for a deployment no preset names — a local anvil stack, or a stack deployed onto a fork. Mutually exclusive with a preset name. See below.

ARCNOW_RPC_URL

the preset's endpoint

Override the endpoint. Redacted of credentials before it is ever printed.

ARCNOW_MCP_ALLOW_WRITES

unset

1 enables the write tools. --allow-writes does the same.

ARCNOW_PRIVATE_KEY

unset

The signing key. Read once, at startup. Never printed, never serialised, never a tool argument.

ARCNOW_PRIVATE_KEY_FILE

unset

The same, from a file — so the key is not in the client's config file either. Setting both is an error rather than a guess.

ARCNOW_MCP_MAX_SPEND_USDC

100

The ceiling on any single write call spending native USDC, in whole USDC.

ARCNOW_MCP_MAX_SPEND_<SYMBOL>

unset: refused

The ceiling on any single write call spending that quote token, in its own units: ARCNOW_MCP_MAX_SPEND_EURC=50. No default.

ARCNOW_MCP_LOG_CHUNK_BLOCKS

10000

Block range per eth_getLogs request in the launch scan.

ARCNOW_MCP_LOG_MAX_CHUNKS

20

How many such requests one arcnow_list_tokens call may make.

There is no secret anywhere in this repository, and nothing here writes one to disk. ARCNOW_PRIVATE_KEY_FILE is the recommended shape: a client config that names a path holds no key even when it is committed or screenshotted.

Spend caps: per quote token, fail-closed

A token is priced in one quote for life, and a cap in USDC cannot bound a spend in EURC. So every quote token has its own cap, in its own units:

  • ARCNOW_MCP_MAX_SPEND_USDC caps native USDC, and defaults to 100.

  • ARCNOW_MCP_MAX_SPEND_<SYMBOL> caps each other quote — ARCNOW_MCP_MAX_SPEND_EURC=50 is 50 EURC. The symbol is upper-cased; a character that is not a letter or a digit is written _. The cap is matched to the network's own token by address: on arc-mainnet that is EURC at 0xbEf5f6d5…, on arc-testnet at 0x89b50855…, each read from the preset.

It fails closed, four ways:

  • A quote with no cap is refused for every spending write — arcnow_launch and arcnow_buy — with a refusal that names the variable to set. Non-native quotes have no default. A cap can never be got round by switching quote.

  • A symbol resolves only against the network's own quoteTokens — the SDK's networks.json, or ARCNOW_MCP_NETWORK_FILE — and a cap is matched to a token by address. A token's on-chain symbol() is never consulted, so a token calling itself EURC does not get EURC's cap, and a quote the network does not list can have no cap at all: it is always refused.

  • A ARCNOW_MCP_MAX_SPEND_… variable that names no quote token of the network refuses to start the server, which catches a typo such as …_EURO.

  • Two quote tokens of the network sharing a symbol refuses to start it: one variable cannot mean two caps.

What counts: a launch spends its totalCost — the initial buy plus any launch fee (zero on both networks), in the launch's quote; a buy spends its quoteIn. For an ERC-20 quote the SDK approves exactly that spend, so the same check covers the approve. The caller's own maxTotalCost is read in the same quote. The startup banner, arcnow_network and arcnow_quote_tokens show every cap, and describe() reports maxSpendPerCallUsdc and maxSpendPerCall ({ "USDC": "100", "EURC": "50" }, or null where none is set).

A network the SDK has no preset for

ARCNOW_MCP_NETWORK_FILE=/path/to/network.json points the server at a deployment by its addresses — a local anvil stack, or the stack this repository's fork proof deploys onto a fork of Arc testnet:

{
  "name": "arc-testnet-fork",
  "rpcUrl": "http://127.0.0.1:8545",
  "chainId": 5042002,
  "contracts": { "launchpad": "0x…", "tokenFactory": "0x…", "curveFactory": "0x…",
                 "migratorRegistry": "0x…", "platformRegistry": "0x…",
                 "arcnowPlatform": "0x…", "quoteRegistry": "0x…",
                 "v4Migrator": "0x…", "feeHook": "0x…", "v4Router": "0x…" },
  "v4": { "poolManager": "0x…" },
  "quoteTokens": [
    { "address": "0x0000000000000000000000000000000000000000", "symbol": "USDC", "name": "USD Coin", "decimals": 18, "isNative": true },
    { "address": "0x89b50855aa3be2f677cd6303cec089b5f319d72a", "symbol": "EURC", "name": "EURC", "decimals": 6, "isNative": false }
  ],
  "quoteAllowanceSlots": { "0x89b50855aa3be2f677cd6303cec089b5f319d72a": 10 }
}

It is validated by the SDK's own resolveNetwork: a missing required contract, an invalid quote token or unreadable JSON stops the server at startup. quoteAllowanceSlots may be numbers or decimal strings. ARCNOW_RPC_URL still overrides the endpoint. Setting it together with ARCNOW_MCP_NETWORK or --network= is an error, not a guess.

Amounts are decimal strings

"25", "1.5" — never JSON numbers. A JSON number is an IEEE double, and a double cannot hold 0.000193050193050194 (the shipped curve's last price) or any 18-decimal quantity above about nine million.

Every amount is in the token's own quote, parsed exactly in that quote's decimals. quoteIn, initialBuy and maxTotalCost are read with the SDK's QuoteAmount.parse in the decimals of the quote they are in — 18 for native USDC, 6 for EURC — so "1.0000001" of EURC is refused, naming the decimals, rather than rounded to an amount nobody typed. Nothing this server prints is a bare number: money is always 123.75 USDC or 1.5 EURC, in the symbol of the quote it is actually in.

On Arc, native USDC is the gas currency, at 18 decimals. The USDC ERC-20 predeploy is the same asset reporting 6; it pays for nothing and is not a quote token. Gas is always native USDC, whatever a token's quote.

The SDK, and how the pin works

@arcnow/sdk is published to npm from arcnow-io/arcnow-io-sdk, one tagged release per version, and this server depends on it at an exact version — "@arcnow/sdk": "0.2.0", never ^0.2.0. The tool descriptions promise what one known SDK does; a range would let npm install move the code under them with no commit here saying so. Moving the pin is a pull request.

pins.json records it:

"sdk": {
  "package": "@arcnow/sdk",
  "version": "0.2.0",
  "integrity": "sha512-…",
  "public_repo": "arcnow-io/arcnow-io-sdk",
  "tag": "v0.2.0",
  "why": ["what this server uses from that SDK, in prose"]
}

integrity is the sha512 of that version's tarball, as npm records it in package-lock.json and serves it as dist.integrity. The tarball is the surface: every module, the generated ABIs that encode every call, the networks.json every address comes from — one hash. (Until the SDK was published this file hashed its sources file by file and the gate recompiled its dist/; the integrity replaces all of that.)

Before every release the maintainers verify that the manifest, the lockfile, the installed package and the registry all name that one tarball; moving the pin is a pull request that reads the SDK's changelog and re-reads every tool description.

Testing

npm test     # the unit suite: no chain, no container, no key

It runs against a fake chain that does exactly what each test says, and proves what can be proved offline:

  • A key is never an argument. Every published schema is walked for credential-shaped field names and asserted strict; passing privateKey or mnemonic anyway is refused, named, answered with "rotate it", and sends nothing.

  • A write refuses without the opt-in, names --allow-writes and ARCNOW_PRIVATE_KEY, and has sent nothing.

  • Both spend ceilings stop a transaction, on a curve and in a pool, per quote token, on either preset — mainnet's EURC is capped by its mainnet address; a typo'd cap variable refuses to start; a USDC cap does not apply to EURC or the reverse.

  • Every amount is labelled with its own quote, an input with more decimals than its quote is refused, and an ERC-20 approve is reported whether it was sent or not.

  • The gas trap is handled, the venues are told apart (a stranded token is refused everywhere with arcnow_migrate named), the sell approval is never sent without approveRouter: true and never for more than the amount sold, and the reports say true things: a curve fee broken out four ways, a pool's 0.80% and 0.20% read off the pool and never assumed, a free launch printed from the registry's zero, average fill price apart from spot, graduated apart from migrated.

  • Both presets resolve to the SDK's live deployments, arc-mainnet says it is real money, and nothing of one network's addresses appears in a report about the other.

  • The wire works: a real MCP client against a real MCP server over an in-memory transport.

What the unit suite cannot prove — that the built server, driven by a real MCP client over stdio, lists the quote tokens, launches, buys and sells a token on its curve and in its Uniswap v4 pool, and launches and buys a token priced in EURC under the EURC cap, against arcnow.io's real contracts, every quote equal to its fill to the wei — the maintainers prove before every release, on an anvil fork of Arc testnet with those contracts deployed onto it. A fork re-executes with anvil's EVM, so Arc's own execution semantics are outside even that; and no test can prove that a tool description is true or that a model behaves — every guard here is a bound on damage, not a guarantee of judgement.

Licence

GPL-3.0-or-later, the same licence as @arcnow/sdk, which this server builds on. See LICENSE.

Available Tools

9 tools
arcnow_list_platformsList registered platformsA
Read-onlyIdempotent

Every platform the registry has deployed, with its fee split and default graduation venue. Unlike arcnow_list_tokens this is a real enumeration held in contract storage, so it is complete — there is no scan window and nothing is missed.

Use it to answer 'what can I launch under' or 'who else builds on this'. Launching does not require your own platform; arcnow.io's is the default and is one entry here among the others, not a privileged one.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many platforms to return.
offsetNoHow many to skip, for paging through a long registry.

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover read-only, idempotent, non-destructive, and open-world behavior, lowering the bar. The description adds useful behavioral context beyond annotations: the enumeration is complete, held in contract storage, and includes arcnow.io's platform as a normal entry. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Every sentence earns its place: primary purpose, the contrast with the sibling, the concrete use cases, and the non-privileged default platform. The description is front-loaded with the most important information and contains no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description's mention of fee split and default graduation venue helps set return expectations. It also provides enough context for when to use the tool and what makes it trustworthy. Minor gaps like sorting order or exact response envelope are not critical for a simple paginated list.

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

Parameters3/5

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

Schema description coverage is 100%, and both limit and offset already have clear descriptions. The tool description does not add parameter-specific semantics but does not need to; the schema carries that weight adequately.

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?

The description clearly identifies the resource ('every platform the registry has deployed'), the operation (listing), and the key returned fields (fee split, default graduation venue). It also explicitly distinguishes itself from arcnow_list_tokens, so an agent can tell them apart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description names the sibling alternative (arcnow_list_tokens) and explains the key difference: this is a complete contract-stored enumeration with no scan window, whereas the sibling presumably scans. It also states concrete use cases: 'what can I launch under' and 'who else builds on this', plus clarifies that arcnow.io's platform is not privileged.

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

arcnow_list_tokensRecent token launchesA
Read-onlyIdempotent

Recent arcnow.io launches, newest first, read from the launchpad's Launched log.

There is no index and no backend behind this: it walks the chain backwards from the tip in bounded chunks, so it sees a WINDOW of recent history and the result says exactly which blocks it covered. If it stopped on its budget before finding what you asked for, that is reported and is not the same as 'there are no more' — do not tell a user a token does not exist on the strength of this tool.

Filter by creator to find what one address launched. Set includeState to false when you only need the addresses; each token's curve state is an extra round trip.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoHow many launches to return. Each one with includeState costs a round trip.
creatorNoOnly launches by this creator address.
includeStateNoAlso read each curve's live state: price, reserve, progress to graduation, whether it graduated. Off is faster and tells you only what the launch log recorded.

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the lack of an index/backend, the bounded backward chain walk, the meaning of budget exhaustion, and the extra round-trip cost of `includeState`. This is substantive behavioral context that annotations alone would not convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core listing behavior and every paragraph adds distinct information: purpose, window limitation, and parameter guidance. No sentence is filler.

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?

Even without an output schema, the description tells the agent what the result will contain (addresses, optional curve state, covered blocks) and how to interpret a budget stop. This is complete for correct invocation and result interpretation.

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

Parameters4/5

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

Schema coverage is 100%, so the structured descriptions already handle the parameters. The description adds value by mapping `creator` to a use case and by framing `includeState` around a trade-off between speed and returned data.

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?

The description opens with 'Recent arcnow.io launches, newest first' and identifies the source as the launchpad's `Launched` log. This names a specific verb and resource and is clearly distinct from siblings like arcnow_token or arcnow_list_platforms.

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?

It provides concrete conditional guidance: use `creator` to find a single address's launches and set `includeState` to false when only addresses are needed. It also gives a clear 'when not' by warning that the bounded window must not be used to assert nonexistence, though it doesn't explicitly name alternative sibling tools.

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

arcnow_networkNetwork and server modeA
Read-onlyIdempotent

Which chain this server is pointed at, which arcnow.io contracts are deployed there, which graduation venues exist, whether a Uniswap v4 router is configured for trading graduated tokens, and — the part that decides what else you can do — whether this server is READ-ONLY or has writes enabled.

Call this first in any session that might trade. It tells you the spend ceilings the operator set — one per quote token, and a quote with none is refused — the address that would sign, and whether the write tools exist at all. It lists the network's quote tokens: a token is priced for life in native USDC (the gas currency, 18 decimals) or an ERC-20 such as EURC (6 decimals), and every amount is in that quote. The 6-decimal USDC ERC-20 predeploy is a separate view of native USDC that pays for nothing. Takes no arguments and touches no chain state; arcnow_quote_tokens asks the registry which quotes a launch accepts.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.8/5.0
Behavior5/5

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

Even with annotations already declaring readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, the description adds genuine behavioral detail: it can report whether writes are enabled, reveals operator-set spend ceilings and the signing address, and states it 'touches no chain state.' It also documents the quote token semantics (native USDC with 18 decimals vs ERC-20 such as EURC with 6 decimals) and the special USDC predeploy, helping the agent interpret results safely.

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?

The description is compact enough despite its detail, and it front-loads the tool's purpose and scope before giving operational facts and a sibling pointer. There is some redundancy between 'READ-ONLY or has writes enabled' and 'whether the write tools exist at all,' so it is not perfectly tight.

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 zero-argument discovery tool with a rich output payload and no output schema, the description compensates by enumerating the main content: chain, contracts, venues, router, server mode, spend ceilings, signer, and quote tokens. It also states side-effect-free behavior and usage precedence. This leaves the agent with enough context to invoke it correctly and interpret the result.

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

Parameters4/5

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

The input schema is empty with additionalProperties false, and the description explicitly states 'Takes no arguments,' so there is nothing further for parameter documentation to add. Per the zero-parameter baseline, this is fully covered.

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?

The description names a concrete informational resource (network/server mode) and enumerates the exact facts it reveals, from chain and deployed contracts to the read-only/writable mode. It also differentiates itself from the sibling arcnow_quote_tokens, which accesses quote-token registry data. Despite lacking a leading verb, 'Call this first ... It tells you' provides a clear operative purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly says 'Call this first in any session that might trade,' giving a direct when-to-use trigger. It also explains that the tool has no arguments and touches no chain state, and contrasts with arcnow_quote_tokens by saying that tool asks the registry which quotes a launch accepts. This is actionable routing guidance relative to the sibling set.

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

arcnow_platformInspect a platform's fees and defaultsA
Read-onlyIdempotent

One platform's configuration: who administers it, who receives its cut, how the 1% trade fee is divided FOUR ways — creator, referrer, the platform and the protocol; there is no developer share — which migrator it launches tokens into by default, and the curve template it stamps onto every token it launches.

With no address, reports arcnow.io's own platform — the default a launch uses.

The single easiest thing to misread here is what a share means. Every share is basis points OF THE FEE, never of the trade. A creator share of 3000 bps is 30% of the fee and 0.30% of the trade. This tool prints both, every time. The platform's own share is never configured: it is the residual, whatever is left after the protocol, creator and referrer shares — arcnow.io's own is creator 3000 / referrer 1000 / platform 3500 / protocol 2500.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressNoOptional: the PlatformConfig address. Defaults to arcnow.io's own platform.

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already establish read-only, idempotent, non-destructive behavior, so the description adds valuable context beyond them: fee shares are basis points of the fee, not the trade; the platform share is always the residual; and the tool always prints both bps and percentage. This prevents a likely misinterpretation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured in clear paragraphs: what the tool reports, how the optional address behaves, and the critical share-semantics warning. Every sentence carries useful information without redundancy.

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?

With no output schema, the description compensates by naming the key returned aspects: administrators, fee recipients, the four-way fee division, migrator default, and curve template. It also clarifies the default no-address case and the exact share semantics, giving an agent enough to understand and invoke the tool correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the optionality and default behavior already present in the schema ('Defaults to arcnow.io's own platform') but does not add materially new parameter semantics beyond that.

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?

The description states a specific action and resource: inspecting one platform's configuration, covering administrators, fee splits, migrator defaults, and curve templates. It clearly distinguishes itself from the sibling list tool by saying 'One platform's configuration' rather than a list.

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?

It gives clear usage context, especially the key behavior that omitting the address defaults to arcnow.io's own platform. However, it does not explicitly contrast with arcnow_list_platforms or state when one should be chosen over the other.

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

arcnow_quote_buyQuote a buyA
Read-onlyIdempotent

What a given amount of the token's quote would buy right now, wherever the token trades: tokens out, every fee and who receives it — on a curve the flat 1% split four ways between creator, platform, referrer and protocol — the average price the order would fill at, and the minimum-out floor at several slippage tolerances.

Costs nothing and signs nothing. Use it before every buy, and use it INSTEAD of a spot price whenever someone asks what an amount would get them — an order moves the price across its own size, so the spot price is only ever its first infinitesimal slice.

ON A BONDING CURVE: if the buy would fill the curve, this says so, reports the refund, and explains the gas-limit trap that decides whether the token's market is created in that same transaction or never. Read that part before quoting a graduating buy to anyone.

IN A UNISWAP V4 POOL (the token graduated and migrated): the quote says it is a pool quote, priced by simulating the real swap through arcnow.io's router. It shows the two charges apart — arcnow.io's fee hook's 0.80% and the pool's own 0.20% LP fee, 1.00% in all, both read off the pool — the average fill price against the pool's spot price, and the price impact. referrer does not exist on a pool swap and is refused.

A token that graduated but never migrated trades nowhere; this says so and names arcnow_migrate. A quote is a snapshot of one block. Anyone else's trade changes it.

THE AMOUNT IS IN THE TOKEN'S QUOTE: native USDC, or the ERC-20 (such as EURC) it was launched in — arcnow_token names it. Every figure in the answer is labelled with that quote's symbol. An ERC-20 quote is pulled with an exact approval, which the answer says.

ParametersJSON Schema
NameRequiredDescriptionDefault
addressYesThe curve address, or the token address. Either works.
quoteInYesHow much of the token's quote to spend, in whole units as a person writes it — "25", "1.5" — in the quote the token is priced in: native USDC (18 decimals) or an ERC-20 such as EURC (6). It is read exactly in that quote's decimals; more decimal places than the quote has is refused, never rounded. A string, because a JSON number cannot hold 18 decimals.
referrerNoCURVE ONLY: the address credited with the referral share of the fee. With no referrer that share goes to the platform instead. Refused for a token in its pool, whose swap has no referrer. (There is no developer share and no developer argument: the fee has four parties — creator, platform, referrer, protocol.)

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already mark readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, and the description adds meaningful behavior beyond those: 'Costs nothing and signs nothing,' the quote is a one-block snapshot, anyone else's trade changes it, ERC-20 quotes use an exact approval, and the curve fill/gas-limit trap is disclosed. No contradiction with annotations.

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?

The description is long but deliberately structured with labeled sections for curve, pool, and no-market cases, and the core purpose is front-loaded. There is little filler, though some details are re-emphasized across sections. The length is justified by the tool's multi-context behavior.

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?

Even without an output schema, the description tells an agent what the answer contains: tokens out, fees and recipients, average fill price, minimum-out floors, slippage, refunds, pool-quote indicators, price impact, and no-market messaging. It also covers edge cases like graduating buys and ERC-20 exact approvals, making it complete for invoking the tool.

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

Parameters4/5

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

Schema coverage is 100%, and the schema already documents address, quoteIn, and referrer well. The description adds useful extra semantics: the amount is denominated in the token's quote currency, figures are labelled with that symbol, ERC-20 quotes are pulled with an exact approval, and referrer is refused on pool swaps. This exceeds the baseline but is somewhat redundant with the schema.

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?

The description states a specific verb and resource: 'What a given amount of the token's quote would buy right now' and explicitly contrasts itself with a spot price. It also enumerates the returned information (tokens out, fees, recipients, average fill price, minimum-out floor), making it clearly distinguishable from siblings like quote_sell or quote_tokens.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives direct guidance: 'Use it before every buy, and use it INSTEAD of a spot price whenever someone asks what an amount would get them.' It also differentiates when the token is on a bonding curve, in a Uniswap v4 pool, or nowhere tradable, and specifies when referrer is refused.

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

arcnow_quote_launchQuote a launchA
Read-onlyIdempotent

What launching a token would cost, before anything is spent: the launch fee the quote registry sets for the quote (zero on arcnow.io's networks — launching is free — but read live, never assumed), the initial buy, the 1% trade fee the initial buy itself pays, the tokens the creator would receive, and — given a creator address — the exact addresses the token and its curve would land at.

Costs nothing and signs nothing. Always call this before arcnow_launch and show the user the total, because a launch is irreversible: the name, symbol, supply, curve shape and graduation venue are fixed at that transaction and can never be changed afterwards, by anyone, including whoever launched it.

THE QUOTE. A token is priced for life in the quote it launches in: quote names it by symbol or address — native USDC by default, or an ERC-20 such as EURC that the quote registry accepts (arcnow_quote_tokens). The initial buy — and any launch fee — is in that quote, and so is every trade in the token afterwards. Native USDC is paid as msg.value; an ERC-20 is pulled by the launchpad after an exact approval.

The total is EXACTLY what a launch requires, not a minimum — for native USDC the launchpad reverts on an overpayment as readily as an underpayment, because it has no refund path.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesThe token's name. Permanent — there is no setter for it, on any contract, ever.
quoteNoOptional: the quote token to launch in, by symbol ("USDC", "EURC") or by address. Defaults to native USDC. The token is priced in it FOR LIFE: its initial buy and every trade in it afterwards. A symbol is looked up in this network's own quote tokens only. arcnow_quote_tokens lists them with whether the quote registry accepts each and this server's spend cap for it; a quote with no cap cannot be launched in here.
symbolYesThe token's ticker. Permanent, and not unique: two tokens may share a symbol, so an address is the only identifier that means anything.
creatorNoOptional: the address that would launch. Given one, this also predicts the token and curve addresses — valid only for that address's CURRENT launch nonce and exactly these parameters.
migratorNoOptional: where this token graduates to, snapshotted into the curve at launch and immutable thereafter. Defaults to the platform's default migrator.
platformNoOptional: the PlatformConfig to launch under. Defaults to arcnow.io's own, which is what almost every launch uses.
initialBuyYesHow much of the launch's quote the creator spends buying their own token in the launch transaction, in whole units, with no more decimals than the quote has. It is an ORDINARY buy: it runs through the curve and pays the 1% trade fee. There is no fee-free entry into a curve, and no launch fee on top of it on arcnow.io's networks. "0" is allowed.
metadataUriYesREQUIRED. An ipfs:// or https:// URI for the token's metadata — image, description, links. The launchpad reverts a launch whose URI is empty (InvalidLaunchParameters), so there is no launching without one. Permanent: it is stamped into the token at launch and there is no setter.

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent; description adds that it costs nothing and signs nothing, reads live fee (never assumed), and that total is exact with revert on overpayment. No contradiction; adds substantial behavioral context.

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?

Well-structured with clear sections (purpose, usage, quote semantics, exactness). Each sentence adds substantive info, but it's slightly longer than necessary; still front-loaded and no filler.

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?

No output schema, so description lists output components (fee, initial buy, trade fee, tokens, addresses) and explains irreversibility and payment exactness. Complete for an agent to call correctly.

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

Parameters4/5

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

Schema covers all 8 params with detailed descriptions (100% coverage), so baseline is 3. The description adds conceptual context (quote concept, payment methods, exactness) but doesn't restate per-param details; it enhances understanding of parameter roles beyond schema.

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?

Clearly states the tool's purpose: it returns the exact cost of launching a token (launch fee, initial buy, trade fee, tokens received, and predicted addresses). It differentiates itself from sibling quote tools (arcnow_quote_buy/sell) by focusing on launch and names arcnow_launch as the execution counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to call this before arcnow_launch and show the user the total, with a strong rationale (irreversibility). Also references arcnow_quote_tokens for quote token selection, giving clear when-to-use and alternatives.

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

arcnow_quote_sellQuote a sellA
Read-onlyIdempotent

What a given quantity of tokens would fetch right now, wherever the token trades: gross proceeds, every fee and who receives it — on a curve the flat 1% split four ways between creator, platform, referrer and protocol — net proceeds in the token's quote (native USDC or an ERC-20 such as EURC), and the minimum-out floor at several tolerances.

Costs nothing and signs nothing.

ON A BONDING CURVE: selling needs NO approval, ever. The curve pulls the tokens through a privileged path that reads no allowance at all, so a holder who has approved nobody can always sell. If you find yourself suggesting an approve step before a curve sell, you are fixing the wrong problem.

IN A UNISWAP V4 POOL (the token graduated and migrated) it is the other way round, and worth telling a user before they sell: the router pulls the tokens with transferFrom, so a pool sell needs an ERC-20 APPROVAL to the router first — a separate transaction. This quote says it is a pool quote, shows arcnow.io's fee hook's 0.80% and the pool's own 0.20% LP fee apart (1.00% in all, read off the pool), the average fill against the pool's spot price, the price impact, and how much holder has approved the router for already. A pool sell is priced as a real holder, so holder must actually hold the tokens; on a writing server it defaults to the signing address. referrer is refused on a pool.

A token that graduated but never migrated trades nowhere; this says so and names arcnow_migrate.

ParametersJSON Schema
NameRequiredDescriptionDefault
holderNoPOOL: the address whose tokens would be sold. A pool sell is priced by simulating the real swap as that address, so it must actually hold the tokens. Defaults to the signing address on a writing server; required on a read-only one. Not needed on a bonding curve, where a sell is priced for nobody in particular.
addressYesThe curve address, or the token address. Either works.
referrerNoCURVE ONLY: credited with the referral share of the fee. Refused for a token in its pool. There is no developer argument: the fee has four parties.
tokensInYesHow many whole tokens to sell, as a string — "1000", "12.5". Tokens are 18-decimal.

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare read-only, open-world, idempotent, and non-destructive behavior. The description goes well beyond this by disclosing that the call costs nothing and signs nothing, that curve sells need no approval while pool sells do, that referrer is refused on pools, and how holder requirements differ. This is exactly the kind of behavioral nuance annotations cannot capture.

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?

The description is long but appropriately structured with clear sections for curve and pool behavior, and it front-loads the core result definition. The extra guidance about not suggesting approvals on curve sells and the graduated-but-not-migrated edge case is helpful rather than filler. The length is justified by the tool's complexity, but a slightly tighter version would be even stronger.

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 quote tool with no output schema and a nontrivial two-environment behavior, the description covers everything needed to call it correctly: result components, fee breakdowns, approval requirements, holder semantics, referrer restrictions, and the dormant-token edge case. No missing context that would prevent correct invocation or interpretation.

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

Parameters4/5

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

The schema already documents all four parameters in detail, so the baseline is 3. The description adds meaningful cross-parameter context: address accepts either a curve or token address, referrer is curve-only and refused on pools, holder must genuinely hold tokens for a pool quote, and tokensIn reflects 18-decimal token amounts. This raises it above baseline even though some content overlaps the schema.

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?

The description opens with a precise statement of what the tool computes: current sell proceeds for a given token quantity, including fees, net proceeds, and minimum-out floors. The distinction between a sell quote and the sibling buy/quote tools is clear from the explicit 'selling' framing throughout.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides rich contextual guidance about when the tool applies: on a bonding curve, in a Uniswap V4 pool, or for a token that graduated but never migrated. However, it never explicitly contrasts this with sibling quote tools like arcnow_quote_buy or arcnow_quote_tokens, so the agent must infer selection from the name and content.

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

arcnow_quote_tokensQuote tokens a launch may useA
Read-onlyIdempotent

The quote tokens a token can be launched in — what its bonding curve, and later its pool, is priced in for life: native USDC (the gas currency, 18 decimals, paid as msg.value) and the ERC-20s arcnow.io's quote registry allowlists, such as EURC (6 decimals, pulled with an exact ERC-20 approval). For each: symbol, name, decimals, address, whether it is native, its launch fee in its own units (zero on arcnow.io's networks — launching is free — but read from the registry, never assumed), whether the registry accepts it for new launches now, and this server's spend cap for it.

SPEND CAPS ARE PER QUOTE, AND FAIL CLOSED. The operator caps native USDC with ARCNOW_MCP_MAX_SPEND_USDC (default 100) and every other quote with ARCNOW_MCP_MAX_SPEND_, in that quote's own units (ARCNOW_MCP_MAX_SPEND_EURC=50). A quote with no cap is REFUSED for every launch and buy, and a quote this network does not list can have no cap at all. Tell the user which quotes they can actually spend here before offering a launch or a buy in one.

Reads the registry in at most three eth_calls. If the chain has no quote registry to ask — a deployment older than quote registries has none — this says so, shows the error, and lists this network's own quote-token metadata instead, with NOTHING known to be accepted. Takes no arguments and spends nothing.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.6/5.0
Behavior5/5

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

The description provides extensive behavioral detail beyond annotations: it explains spend caps are per-quote and fail closed, that missing caps cause refusal, that the tool reads the registry in at most three eth_calls, and that it falls back to network metadata if no registry exists. This fully complements the readOnlyHint and idempotentHint.

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?

The description is long but densely informative. Key points (list of quotes, spend caps, fallback) are covered without redundancy, though the capitalized warning could be trimmed slightly, but it is front-loaded with the core purpose.

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?

Given zero parameters and no output schema, the description is remarkably complete: it details the return data semantics, the spend cap logic, failure modes, and fallback behavior, making it fully self-contained for an agent.

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

Parameters4/5

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

With no parameters, baseline is 4. The description adds no parameter semantics but that is not needed; it adds value by explaining the output structure (symbol, name, decimals, address, native flag, launch fee, etc.) which is not in the schema.

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?

The description clearly states what the tool does: it retrieves the list of quote tokens a launch can use, including their metadata and spend caps. It distinguishes itself from siblings like arcnow_quote_launch, arcnow_quote_buy, and arcnow_quote_sell by being a read-only informational tool.

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?

The description implies when to use it: before offering or making a launch or buy, to know which quotes are spendable. It explicitly instructs to inform the user about available quotes before proceeding, but does not explicitly name alternative tools for other operations, though sibling names are clear.

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

arcnow_tokenInspect a token and where it tradesA
Read-onlyIdempotent

Everything about one arcnow.io token: its metadata, its bonding curve's live state, the price, how far it is from graduation, whether it has graduated — and WHERE IT TRADES NOW: its bonding curve, its Uniswap v4 pool, or nowhere.

For a token in its pool this reports the router this server would trade through, whether that router can actually reach the pool, the PoolManager the liquidity is in (a v4 pool has no address of its own), and what a trade there costs — arcnow.io's fee hook's 0.80% plus the pool's own 0.20% LP fee, 1.00% in all, both read off the pool.

It names the token's QUOTE TOKEN — native USDC or an ERC-20 such as EURC, fixed at launch — with its address and decimals: every amount here, and every amount the trade tools take for this token, is in that quote.

Pass either the token address or its curve address; this works out which it got. Pass holder to include that address's balance and any refund the curve is holding for it.

Two things this tool reports that are easy to misread. The spot price is the marginal price of the next infinitesimal token, NOT the price a trade of any size fills at — use arcnow_quote_buy for that. And 'graduated' and 'migrated' are different states: a curve can have graduated (trading on it is over, permanently) while its pool was never created, which leaves the token tradeable nowhere until somebody runs migrate().

ParametersJSON Schema
NameRequiredDescriptionDefault
holderNoOptional: also report this address's token balance and any of the token's quote the curve is holding for it after a failed payout.
addressYesThe token address, or its curve address. Either works.

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the tool is safe and side-effect-free. The description adds valuable behavioral context beyond that: it reports the router, reachability, PoolManager, fees (1.00% total), and the concept that a v4 pool has no address. It also warns about potential confusion in interpreting spot price and graduation state, which is extra transparency. However, it doesn't mention any rate limits or failure modes, but no annotations contradict.

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?

The description is fairly long but justified given the complexity of the tool's output. It front-loads the purpose and key information, then provides necessary warnings at the end. Each paragraph adds value: overview, details on trading venue, quote token, and parameter usage. The warning about spot price is crucial and placed appropriately. It could be slightly tighter, but every sentence earns its place.

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?

Given the complexity (bonding curve, migration states, Uniswap v4 specifics, trade fees) and that there is no output schema, the description is remarkably thorough. It covers key outputs (metadata, price, graduation status, trading venue), explains how to interpret them (spot vs fill price, graduated vs migrated), and provides necessary domain knowledge (quote token, fee structure). An agent has enough to call this tool correctly and interpret results properly.

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

Parameters4/5

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

Schema coverage is 100%, with descriptions for both parameters: 'address' says token or curve address, and 'holder' explains it adds balance and refund info. The description adds significant meaning beyond the schema: it explains that the token address or curve address both work, and elaborates on the 'holder' parameter's purpose in detail (including failed payout refunds). It also clarifies the quote token context, which directly relates to parameter usage. Baseline is 3, and the description clearly adds more, so 4.

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?

The description states a clear, specific purpose: inspect a token and its trading venue, covering metadata, bonding curve state, price, graduation status, and where it trades. It explicitly distinguishes from siblings like arcnow_quote_buy by noting the spot price is not the fill price and pointing to that tool for actual trade quotes. The opening line 'Everything about one arcnow.io token' immediately signals scope and differentiates from list-type tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly explains when to use this tool versus alternatives: use arcnow_quote_buy for trade fill prices, and clarifies the distinction between 'graduated' and 'migrated' states, warning about misreading these. It also specifies that either token address or curve address can be passed, and the optional 'holder' parameter for balance queries. This provides clear decision guidance for an agent.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv0.2.0
    • Changedarcnow_quote_buy2 fields changed
      • removedInput schema / properties / developer
        Removed value: -{
-  "description": "CURVE ONLY: the address credited with the developer share of the fee. With none, it goes to the platform. Refused for a token in its pool.",
-  "pattern": "^0x[0-9a-fA-F]{40}$",
-  "type": "string"
-}
      • changedInput schema / properties / referrer / description
        Previous value: -"CURVE ONLY: the address credited with the referral share of the fee. With no referrer that share goes to the platform instead. Refused for a token in its pool, whose swap has no referrer."New value: +"CURVE ONLY: the address credited with the referral share of the fee. With no referrer that share goes to the platform instead. Refused for a token in its pool, whose swap has no referrer. (There is no developer share and no developer argument: the fee has four parties — creator, platform, referrer, protocol.)"
    • Changedarcnow_quote_launch2 fields changed
      • changedInput schema / properties / initialBuy / description
        Previous value: -"How much of the launch's quote the creator spends buying their own token in the launch transaction, in whole units, with no more decimals than the quote has. It is an ORDINARY buy: it runs through the curve and pays the 1% trade fee on top of the flat launch fee. There is no fee-free entry into a curve. \"0\" is allowed."New value: +"How much of the launch's quote the creator spends buying their own token in the launch transaction, in whole units, with no more decimals than the quote has. It is an ORDINARY buy: it runs through the curve and pays the 1% trade fee. There is no fee-free entry into a curve, and no launch fee on top of it on arcnow.io's networks. \"0\" is allowed."
      • changedInput schema / properties / quote / description
        Previous value: -"Optional: the quote token to launch in, by symbol (\"USDC\", \"EURC\") or by address. Defaults to native USDC. The token is priced in it FOR LIFE: its launch fee, its initial buy, and every trade in it afterwards. A symbol is looked up in this network's own quote tokens only. arcnow_quote_tokens lists them with whether the quote registry accepts each and this server's spend cap for it; a quote with no cap cannot be launched in here."New value: +"Optional: the quote token to launch in, by symbol (\"USDC\", \"EURC\") or by address. Defaults to native USDC. The token is priced in it FOR LIFE: its initial buy and every trade in it afterwards. A symbol is looked up in this network's own quote tokens only. arcnow_quote_tokens lists them with whether the quote registry accepts each and this server's spend cap for it; a quote with no cap cannot be launched in here."
    • Changedarcnow_quote_sell2 fields changed
      • removedInput schema / properties / developer
        Removed value: -{
-  "description": "CURVE ONLY: credited with the developer share of the fee. Refused for a token in its pool.",
-  "pattern": "^0x[0-9a-fA-F]{40}$",
-  "type": "string"
-}
      • changedInput schema / properties / referrer / description
        Previous value: -"CURVE ONLY: credited with the referral share of the fee. Refused for a token in its pool."New value: +"CURVE ONLY: credited with the referral share of the fee. Refused for a token in its pool. There is no developer argument: the fee has four parties."
  2. 9 tool updatesv0.1.1
    • First observedarcnow_list_platforms
    • First observedarcnow_list_tokens
    • First observedarcnow_network
    • First observedarcnow_platform
    • First observedarcnow_quote_buy
    • First observedarcnow_quote_launch
    • First observedarcnow_quote_sell
    • First observedarcnow_quote_tokens
    • First observedarcnow_token
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.4/5.0

Scored across 9 tools

Disambiguation5/5

Each tool targets a distinct concern: quote token registry, launch quoting, token state, buy/sell quoting, platform config, platform/token listings, and network info. Even where topics touch (quote_tokens vs network both mention quote tokens), their roles are clearly separated by description.

Naming Consistency4/5

All tools share the arcnow_ prefix, but the pattern after it is mixed: some are noun-only (token, platform, network) while others are verb_noun (list_platforms, list_tokens, quote_buy, quote_sell). The prefix provides strong coherence, though a uniform verb_noun style would be more predictable.

Tool Count5/5

Nine tools cover the read/quote side of a token launch and trading platform without redundancy. The count feels well-scoped for the apparent domain.

Completeness2/5

The set is severely incomplete for a launch/trading server: arcnow_quote_launch explicitly references arcnow_launch, and arcnow_token references arcnow_migrate, but no actual execution tools (launch, buy, sell, migrate) are present. Agents can quote but never act, leaving core lifecycle operations missing.

Maintenance

ActivityNo data
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers