Solana MCP by Vybe: registry metadata, a Claude plugin and 44 read-mostly API tools

This repository holds listing files, and the running server lives in another repo

Solana MCP by Vybe is described as a developer toolkit for live Solana data: wallets, trades, markets, transfers and signable swaps. The public server publishes 44 tools, and each tool calls one Vybe API endpoint.

The important boundary is what this repository is. It is the directory listing, the Claude plugin and the MCP registry metadata. The running server is a different project, vybenetwork/vybe-mcp-oauth-proxy, and its current version is 1.3.2. The top level of this repository matches that scope: .claude-plugin/, .codex-plugin/, .mcp.json, server.json, commands/, skills/ and assets/, with no server source.

That matters for anyone who wants to audit behaviour or file a bug about tool output. Reading this repository tells you what is advertised, not how a tool computes its answer. The repository lists no license and has no GitHub releases, so the only version markers are the three numbers the project publishes for its separate pieces.

Three components carry three different version numbers

There is no single version for Solana MCP by Vybe. The live MCP server is 1.3.2, and you read that value from the `initialize` response on `https://mcp.vybenetwork.xyz/mcp`. The Claude plugin is 1.3.0, recorded in `.claude-plugin/plugin.json`. The MCP registry metadata is 1.1.3, recorded in `server.json`.

The spread is a practical trap. If you are filing an issue or comparing behaviour across machines, the number you quote has to say which piece it belongs to. A plugin at 1.3.0 can sit in front of a server at 1.3.2 without anything being wrong, and the registry entry at 1.1.3 can trail both. The server can change under you without any change in this repository, because the server is deployed from the other repo. The last push here was on 2026-10-27, and since no GitHub releases exist, that date and the manifest files are the only change signals.

Two URLs for the same server, and clients that need the /mcp path

The streamable HTTP endpoint is:

https://mcp.vybenetwork.xyz/mcp

The registry metadata in `server.json` publishes the remote without the path:

https://mcp.vybenetwork.xyz

Clients that require an explicit MCP path, such as ChatGPT Developer Mode, Codex and Cursor HTTP, should use the URL ending in /mcp. If you copy the bare host from the registry entry into one of those clients, you are using the form the project itself tells those clients not to use.

For Cursor, Windsurf and Codex-style HTTP clients the setup is one JSON entry:

{
  "mcpServers": {
    "solana-mcp-vybe": {
      "type": "http",
      "url": "https://mcp.vybenetwork.xyz/mcp"
    }
  }
}

The same snippet is in the .mcp.json file, which holds no secrets.

Claude Desktop needs the mcp-remote bridge

Claude Desktop is configured through a local command rather than a URL entry. The setup runs `npx` with `mcp-remote` pointed at the endpoint:

{
  "mcpServers": {
    "solana-mcp-vybe": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://mcp.vybenetwork.xyz/mcp"]
    }
  }
}

That means Claude Desktop users need Node's npx available on the machine, and `-y` lets npx fetch the bridge without a prompt. For Claude.ai there is no local process at all: you add a custom connector or use the Connectors Directory with the name Solana MCP by Vybe and the same /mcp URL.

For Claude Code and Cowork, the repository itself is a plugin. The step given is `claude plugin validate .`, after which you submit the public GitHub URL through the Claude.ai or Console plugin submission pages. The note on validation is candid: on Claude Code 2.1.138 the directory-only fields such as displayName, icon, links and classification are reported as unrecognized, although the plugin directory accepts them. So a warning from the validator is expected for those fields.

Swaps and cleanups return unsigned transactions, and nothing is broadcast

Three tools build transactions: `build-swap`, `build-close-token-accounts` and `build-withdraw-mev`. Each returns an unsigned transaction that you sign in your own wallet. The server does not take private keys, and it does not broadcast transactions.

For an agent builder this is the line that defines the risk. A model connected to this server cannot move funds by itself, because the signature step happens outside the server. It also cannot finish the job. If your goal is an autonomous trading loop, you must supply the signing and sending path yourself, and the safety review of that path is yours.

A similar boundary applies to payment. `get-x402-access-guide` returns x402 pay-per-call instructions and does not send a payment. It tells the agent how access works, and a human or a separate payer has to act on it. The OAuth guidance also says not to commit API keys or private keys into the repository, and no tool in the published description asks for a private key.

Tools map one to one onto Vybe API endpoints, with arguments instead of URLs

The published tool list has 44 entries, and each tool name corresponds to a single Vybe API call. The reads cover Pyth oracle feeds, markets, tokens, transfers, trades and wallets: for example `list-markets` calls GET /v4/markets, `get-token-top-holders` calls GET /v4/tokens/{mintAddress}/top-holders, and `get-wallet-pnl` calls GET /v4/wallets/{ownerAddress}/pnl. Batch wallet tools such as `get-token-balances-batch` use POST to /v4/wallets/batch/token-balances.

You pass each tool's own arguments. You do not pass a URL, a path or an HTTP method. This is what distinguishes the current server from the earlier design: the public guide at docs.vybenetwork.com/docs/mcp still describes older tools named `list-endpoints`, `search-endpoints`, `get-endpoint` and `execute-request`, and those names are not in the published tool list. A prompt or skill written from that guide will call tools that do not exist.

Some tools carry hard limits. `get-token-holder-count-history` requires `startTime` and `endTime` as unix seconds, at most 2592000 seconds apart, which is 30 days, and `interval` is `hour` or `day`. Asking for a longer window means several calls.

Sign-in uses a Vybe email and API key, and the bundled skills are only three

When a client asks you to sign in, you use OAuth. The username is your Vybe email and the password is your API key, after which you approve the consent screen. Without a Vybe account and key, the connection cannot be completed, so the free-looking setup snippets are only half the setup. The commands/connect-vybe.md file is the Claude command that walks through those steps.

The plugin bundles three skills under skills/: `vybe-api-explorer`, `vybe-token-market-intel` and `vybe-wallet-analytics`. A Codex plugin manifest in .codex-plugin/plugin.json points local installs at the same MCP URL.

The Claude plugin manifest also declares a classification: it acts on apis, finances, code and databases, with department engineering, industry software-saas and subject computing. The support, privacy and terms links point at vybe.fyi, and documentation at docs.vybenetwork.com. Because the finances classification is declared, review the privacy and terms pages before you give an agent access to wallet analytics tied to your key.

Editorial conclusion

Use this if you want an agent to read Solana wallets, token markets, trades and transfers through a hosted MCP endpoint, and you already hold a Vybe API key. Do not use it expecting the server to sign or send a transaction, or expecting this repository to contain server code. Before wiring it in, pick the URL with the /mcp path for your client and check that your documentation matches the published tool list.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. vybenetwork/solana-mcp-vybe on GitHub