Singularity Agent

A universal CLI and MCP plugin for interacting with blockchains — one interface across EVM, Solana, Bitcoin/UTXO, and Cosmos, and Tessarq through a node you run.

Five chain families normally mean five SDKs, five address formats, five sets of field names, and five ways to be wrong about decimals. Singularity puts one normalized surface over all of them, for both a human at a terminal and a model over MCP.

It is read-only and holds no keys. It can build unsigned transactions for you to sign in your own wallet; it cannot sign, and it cannot broadcast.

---

Install

Nothing to clone and nothing to build:

npx singularity-agent chains

Or install it properly, for singularity and singularity-mcp on your PATH:

npm install -g singularity-agent

From source

For working on it, or running an unreleased commit:

npm install
npm run build
npm link          # provides `singularity` and `singularity-mcp`

…or with no build step at all:

npx tsx src/cli/index.ts chains

As a Claude Code plugin

Build first (npm install && npm run build) — the plugin runs the compiled server.

The repo is its own single-plugin marketplace, so installing is two steps. Note that the marketplace path must be in ./path or absolute form; a bare . is rejected.

claude plugin marketplace add ./Singularity-Agent   # run from the PARENT directory
claude plugin install singularity-agent@singularity

Or the same thing from inside a Claude Code session:

/plugin marketplace add ./Singularity-Agent
/plugin install singularity-agent@singularity

/plugin install takes a plugin-name@marketplace-name id, never a filesystem path — passing a path fails with "Marketplace not found".

Verify with claude plugin list. To update after a rebuild, bump version in both .claude-plugin/plugin.json and .claude-plugin/marketplace.json, then claude plugin update singularity-agent.

As a hosted MCP server, over HTTP

Nothing to install. The tools run on our infrastructure and the client only needs a URL:

claude mcp add --transport http singularity https://mcp-singularity.cicada71.net/mcp

Or by hand, in any MCP client that speaks streamable HTTP:

{
  "mcpServers": {
    "singularity": {
      "type": "http",
      "url": "https://mcp-singularity.cicada71.net/mcp"
    }
  }
}

The type field matters: a url without one is skipped silently by some clients.

This serves the same twenty-three tools as the local server, from the same catalogue, with full input schemas. It is read-only, holds no keys, and needs no credentials — so the trade is the obvious one: your queries reach our endpoint rather than staying on your machine. If that matters, use the local route below; it is identical in every other way.

A GET on the endpoint returns its name, version and tool count, which is the polite thing to hand a health check.

As a plain MCP server, locally

The quickest local route — no clone, no marketplace, no plugin:

claude mcp add singularity -- npx -y -p singularity-agent singularity-mcp

Or add it to any MCP client's config by hand:

{
  "mcpServers": {
    "singularity": {
      "command": "npx",
      "args": ["-y", "-p", "singularity-agent", "singularity-mcp"]
    }
  }
}

Running from a clone instead, point it at the built server:

claude mcp add singularity -- node /absolute/path/to/Singularity-Agent/dist/mcp/server.js

Working inside this repo, install the plugin (above) rather than adding a project server. The plugin runs dist/mcp/server.bundle.js, a single-file build of the same server that npm run build produces beside the tsc output. The unbundled server reads 1,363 files on start, which from a cold file cache took long enough to miss Claude Code's 30-second connect limit; the bundle reads one.

The committed .mcp.json carries only the hosted endpoint. Keep private or dev-only servers out of it: the marketplace installs this directory as the plugin, and the plugin has been seen to load that file as its own server list. Add them with claude mcp add --scope local … instead.

---

Conversational surfaces

Two long-running bots share one brain. Both use the same agent loop (src/grok/agent.ts), the same persona (src/grok/persona.ts), and the same tool catalogue (src/tools/catalog.ts) that MCP exposes — so Grok can answer a chain question by calling the tools, not by guessing at a number.

npm run agent    # both, with Telegram approving the X bot's posts
npm run bot      # Telegram only
npm run x-bot    # X only, publishing on its own switch

Telegram as the control terminal

npm run agent runs both halves in one process, which is what lets Telegram hold the X bot's posts back. Every reply and every scheduled update is composed as usual and then sent to the control chat as a card showing the exact text and its character count, with Post it / Discard buttons. Nothing reaches X until someone taps.

/drafts       re-send every waiting post as a card you can tap
/x status     what it is doing, what is pending, when it next posts
/x pending    the queue, as text with ids
/x post       draft an update now, without waiting for the timer
/x approve <id> · /x reject <id>     the buttons, as commands
/x pause · /x resume                 stop and restart answering mentions

/drafts exists because an approval card is a message, and messages scroll away. /x pending tells you what is waiting; /drafts puts a fresh, tappable card for each one at the bottom of the chat, where you are already looking.

Approval turns on when a control chat exists: TELEGRAM_CONTROL_CHAT, or the single allowlisted chat when TELEGRAM_ALLOWED_CHATS names exactly one. It refuses to guess between several, because guessing wrong would send drafts — and the power to publish — to the wrong room. Set X_REQUIRE_APPROVAL=false to let the bot post on its own switch again.

This is the beginning of the README. Read the rest at the original. Read the full README ↗