solana-mcp-vybe Is Registry Metadata, Not an MCP Server

What the repository actually is

The README describes this as public Model Context Protocol registry metadata for Solana MCP by Vybe. That phrasing is doing real work. The repository is not an MCP server implementation. It is the listing layer: a server.json published to the official MCP Registry, root .mcp.json and mcp.json configs for directory UIs such as Cursor's Submit a Plugin flow, a .codex-plugin/plugin.json for Codex plugin install and refresh, and a chatgpt-app-submission.json draft. The live endpoint these files point at is hosted by Vybe at https://mcp.vybenetwork.xyz/mcp.

So the audience is narrower than the topic list suggests. The topics include mcp-server and mcp-servers, but nothing in the supplied material shows server code, a Dockerfile, or a runnable entrypoint. If your goal is to read the implementation, this repository will not give it to you. If your goal is to get a Solana-aware MCP client talking to live API data with a copy-paste config, the repository is exactly the right size for that job.

The five tools and the schema-first design

The README lists five tools. Three are read-only discovery: list-endpoints browses API paths with methods and summaries, search-endpoints searches paths, operations and schemas by keyword, and get-endpoint returns full OpenAPI details for one path and method. One is execution: execute-request makes live authenticated API calls. One is payment guidance: pay-with-x402 covers x402 pay-per-call integration.

That split is the design decision worth noticing. Three of five tools exist so the model can read the API surface before calling it, which keeps the OpenAPI description out of the system prompt and lets the client fetch only the endpoint it needs. The cost is round trips. A model that already knows which Vybe endpoint it wants still pays for a discovery call unless the client caches results. The README does not state whether responses are cached or how large get-endpoint payloads get, so treat context consumption as unverified until you watch it in your own client.

Two URLs, and which clients need which

The README gives two host forms and is explicit about when each applies. Registry metadata in server.json publishes the remote as https://mcp.vybenetwork.xyz, while clients that require an explicit MCP path (the README names ChatGPT Developer Mode, Codex, and Cursor HTTP) should use https://mcp.vybenetwork.xyz/mcp. That is a common source of a silent failure: a client that appends its own path to the base URL ends up at the wrong route, and the error usually surfaces as a transport failure rather than a clear message.

The README also flags a documentation drift problem. The live product guides at docs.vybenetwork.com/docs/mcp may still show the old .com host until that site is updated. If you follow a guide and the connection fails, check the host in the guide against the endpoint above before debugging anything else. The repository carries its own copy-paste setup in docs/mcp.md for exactly this reason.

Client config: HTTP, mcp-remote, and the connector form

For Cursor, Windsurf, and Codex-style HTTP clients, the README gives a JSON block with mcpServers keyed to solana-mcp-vybe, type set to http, and url set to https://mcp.vybenetwork.xyz/mcp. The same snippet is filed at examples/cursor-mcp.json.

Claude Desktop takes a different route because it does not speak native HTTP here. The config uses command npx with args -y, mcp-remote, and the same endpoint URL, which puts a Node process between the desktop app and the remote server. That means Claude Desktop users need a working Node and npx on the machine, and the connection now depends on an npm package resolving at launch time. Claude.ai instead uses a custom connector with a name and the URL, and the README says to authenticate with OAuth when the client prompts.

One instruction is unambiguous and worth repeating: do not commit API keys into this repository. The root .mcp.json and mcp.json are described as native HTTP with no secrets, and keeping them that way is what makes the directory submission path workable.

Publishing a listing uses OIDC, not a stored token

The release process is tag-driven. The README shows git tag v1.0.0 followed by git push origin v1.0.0, and states that the workflow sets the version field in server.json from the tag. Alternatively you can run Actions, then Publish to MCP Registry, then Run workflow, which uses the version already in server.json. Publishing uses GitHub OIDC in Actions, so no personal token secret is required.

The README documents one specific failure in detail, which suggests it is common. If you run mcp-publisher login github locally and get a 403 for io.github.vybenetwork, the cause is not Git Credential Manager. You open GitHub, go to Settings, then Applications, then Authorized OAuth Apps, pick the app you authorized during the device-flow login, and under Organization access grant access for vybenetwork. On SAML-enforced organizations you also complete SSO for that OAuth app. Then mcp-publisher logout, mcp-publisher login github, and publish again. Verification is a single curl against the registry search endpoint filtered on vybenetwork, piped to jq. That curl checks the listing exists; it does not tell you the server behind it is reachable, so test the MCP URL separately.

Where this is the wrong tool

Three cases stand out. First, if you need to run an MCP server on your own infrastructure, for air-gapped analysis, for data residency, or to inspect and modify behaviour, this repository gives you nothing to run. The endpoint is remote and Vybe-hosted. Second, if your client cannot do OAuth, the authenticated path is closed: execute-request is described as live authenticated calls, and the README's only authentication instruction is to authenticate with OAuth when the client prompts. A client that only accepts a static header cannot complete that flow as documented. Third, the payment story is a pointer rather than a mechanism. pay-with-x402 is described as integration guidance, not as a billing tool, so if you expect the MCP server to settle x402 payments for you, the README does not support that reading.

One more constraint: the README does not state rate limits, response size caps, or an uptime commitment for the hosted endpoint. Those are operational facts you would want before putting the server behind an automated agent, and they are not in the material.

Compared with a self-hosted Solana MCP server

The obvious alternative is running your own MCP server over an OpenAPI spec, for instance a generic spec-to-MCP bridge pointed at the Vybe OpenAPI document, or the Solana Agent Kit family of tools if you want on-chain actions rather than API queries. The difference is where the schema and the credentials live. A self-hosted bridge keeps the OpenAPI file and the key on your machine, so you control caching, logging, and which endpoints are exposed, and you can pin a version. This repository instead delegates all of that to https://mcp.vybenetwork.xyz/mcp: the tool surface is fixed at the five listed tools, the schema is whatever Vybe currently serves, and updates arrive without a pull on your side.

That trade is legible. You give up control of the surface and gain a maintained listing, OAuth handling, and no server process to run. For querying Vybe's own data the hosted route is less work. For anything where you need to audit exactly which endpoints a model can reach, the self-hosted bridge is the one you can read.

Maintenance cost and licensing

The maintenance surface is small. Root config files change only when the endpoint or client format changes, server.json changes when you publish a version, and the GitHub Actions workflow handles the registry push through OIDC. There are no dependencies to patch in the repository itself, and the README notes the old .com host may linger on the docs site, which means a host change is a documentation task as much as a code one.

The licence is not stated in the material supplied, and the primary language is also unlisted, so no licence implications can be described here. If you plan to redistribute the config files or vendor them into an internal directory listing, check the repository's licence file directly rather than assuming one. Nothing in the README grants or restricts rights, and the instruction not to commit API keys applies regardless of what the licence turns out to be.

Editorial conclusion

Adopt this if you already use Cursor, Claude, Codex or another MCP client and want Solana endpoint schemas plus live authenticated calls without writing an OpenAPI wrapper yourself. Do not adopt it if you need a locally runnable server, a self-hosted deployment, or a repository you can read to understand the implementation, because this repo holds metadata and configs only. Verify three things before wiring it into a workflow: that https://mcp.vybenetwork.xyz/mcp responds to your client's transport, that the OAuth flow completes against your Vybe account, and whether execute-request calls bill through your API key or through the x402 path described by pay-with-x402.

Official sources

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