Solana MCP by Vybe: a hosted MCP endpoint for Solana API work

What this repository actually is, and who needs it

The name suggests a server. The repository is not one. It holds public Model Context Protocol registry metadata for a hosted Solana API endpoint operated by Vybe, and the README is explicit that what is published here is "Public Model Context Protocol (MCP) registry metadata for Solana MCP by Vybe." The top-level entries confirm that: server.json, .mcp.json, mcp.json, .codex-plugin/plugin.json, chatgpt-app-submission.json, plus docs/ and examples/. There is no server source tree.

The audience is therefore narrow and specific. It is for people who already use an MCP client such as Cursor, Claude, Codex, Windsurf or ChatGPT Developer Mode and want that client to browse Solana API schemas or make live Solana API calls. The README states the server lets those clients "browse schemas or make live Solana API calls through one public MCP server." If you are not an MCP client user, nothing in this repository changes your workflow.

The second audience is maintainers of the listing itself. server.json carries the registry name io.github.vybenetwork/solana-mcp-vybe and the display title Solana MCP by Vybe, and the repository documents how to publish a new version. That publishing path is a real part of the project's surface area, not an afterthought.

The five tools the endpoint exposes

The README lists five tools, and the split between them matters more than the count. Three are read-only schema tools: 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. These let an assistant answer questions about the Solana API without touching live data.

The fourth tool, execute-request, is the one that changes the risk profile. It makes live authenticated API calls. That means the MCP client is not just reading documentation on your behalf; it is acting against a Solana API with your credentials. The README's only guidance here is a single line: "Authenticate with OAuth when the client prompts. Do not commit API keys into this repo."

The fifth tool, pay-with-x402, is described as "x402 pay-per-call integration guidance." The README does not document the x402 flow, what currency or network it settles on, or how a client is expected to complete a payment. Treat that tool as guidance surfaced to the model rather than a documented billing mechanism, and check the live product docs at docs.vybenetwork.com/docs/mcp if you need the payment details before relying on it.

Installing it in Cursor, Windsurf or Codex over HTTP

For clients that speak streamable HTTP natively, setup is a config block. The README gives this exact snippet, and the same content is available as examples/cursor-mcp.json. The key is the explicit /mcp path; the README warns that clients requiring an explicit MCP path (it names ChatGPT Developer Mode, Codex and Cursor HTTP) should use the path form rather than the bare host, because server.json publishes the remote as https://mcp.vybenetwork.xyz without the path.

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

After adding that block to your client's MCP configuration and restarting the client, the server named solana-mcp-vybe should appear in the client's tool or server list with the five tools above. A first useful call is to ask the client to list the available endpoints, which maps to list-endpoints. If the server does not appear, the most common cause is the missing /mcp path.

Claude Desktop needs mcp-remote, and Claude.ai does not

Claude Desktop does not connect to a remote HTTP MCP server directly, so the README routes it through the mcp-remote shim. Note the npx invocation and the -y flag, both taken verbatim from the README.

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

This runs a Node process on your machine that proxies to the remote endpoint, so it requires Node and npx to be available, and it introduces a local process between your client and Vybe. That is a real difference from the native HTTP path, not just a syntax variation.

For Claude.ai the README gives a custom connector instead, with no local process at all. The fields are literally a name and a URL: Name is Solana MCP by Vybe, URL is https://mcp.vybenetwork.xyz/mcp. Authentication is OAuth, prompted by the client. The README does not describe what scopes the OAuth grant requests, what the token lifetime is, or how to revoke it.

Where this is the wrong tool

The clearest limitation is that you cannot self-host it from this repository. There is no server implementation here, no Dockerfile, no start command. If your constraint is that credentials must never leave infrastructure you control, this is not the project for you, regardless of how well the client integration works. The endpoint is external and the README treats it as a given.

Version pinning is the second gap. The registry listing has a version field that the publish workflow sets from a git tag, but that versions the metadata, not the behaviour of the remote endpoint. The README does not document a versioned endpoint path, a changelog for tool behaviour, or a deprecation policy for individual tools. If a tool's response shape changes upstream, nothing in this repository would tell you in advance.

The third gap is documentation coverage of the risky tool. execute-request makes live authenticated calls, and the README says nothing about rate limits, per-call cost, error semantics, or which Solana API endpoints are reachable through it. An assistant with execute-request enabled can act on your behalf, and the repository gives you no allowlist or scoping mechanism to constrain that. If you need least-privilege control over what an agent can call, the repository does not show how to get it.

Publishing a new listing version, and the 403 people hit

The maintainer workflow is tag-driven. Pushing a tag sets the version in server.json, and publishing runs through GitHub Actions using OIDC, so the README states no personal token secret is required. The alternative is to run the publish workflow manually, which uses whatever version is already in server.json.

git tag v1.0.0
git push origin v1.0.0

Verification is a single curl against the registry, with the search term vybenetwork. The README gives this command, and the expected result is the published listing in the registry's JSON response.

curl -sS "https://registry.modelcontextprotocol.io/v0.1/servers?search=vybenetwork" | jq .

The README also documents a specific failure mode for anyone publishing locally with mcp-publisher. A 403 for io.github.vybenetwork/... is not a Git credential problem, and Git Credential Manager is unrelated. The fix is to open GitHub Settings, then Applications, then Authorized OAuth Apps, select the app authorized during mcp-publisher login github, grant organization access for vybenetwork, complete SSO if the org enforces SAML, then run mcp-publisher logout, mcp-publisher login github and publish again. That level of detail in a README usually means the maintainers hit it themselves.

Licence, maintenance and what to check before depending on it

The repository listing carries no licence identifier, and the README does not name one. For a repository of metadata and config files that may be unremarkable, but it does mean you should not assume you have redistribution rights for the contents of server.json, .mcp.json, mcp.json or the plugin metadata without asking. The hosted endpoint itself is a separate question: a licence on repository files would not govern the API service, and the README says nothing about terms for the endpoint. That is a question for Vybe, not for this repository.

On maintenance, the last push was on 2026-08-24 and the repository is not archived. That is recent enough that the listing is being touched, but the README does not state a support commitment, a response time, or a deprecation notice period for the endpoint or its tools. Upgrades here are not something you schedule. The registry version moves when a maintainer tags, and the remote endpoint can change independently of any tag, so there is no upgrade step for you to run and no rollback you can perform from this side. The README does not document rollback of a published listing version.

One inconsistency is worth knowing about before you follow a link. The README notes that the live product guides at docs.vybenetwork.com/docs/mcp "still may show the old .com host until that site is updated," while the endpoint you should use is on vybenetwork.xyz. If a doc page tells you to point a client at a .com host, check it against the README before copying it.

Editorial conclusion

Adopt it if you want an MCP client to read Solana API schemas and make live authenticated calls without writing your own OpenAPI wrapper; the Cursor snippet and the mcp-remote snippet for Claude Desktop are the two fastest paths. Do not adopt it if you need to run the server yourself, pin a version, or audit the code that handles your credentials, because this repository contains metadata and config files only and the endpoint is external. Before wiring it into a workflow, confirm that https://mcp.vybenetwork.xyz/mcp still answers, check which authentication flow your client negotiates (OAuth, with the README's warning not to commit API keys into the repo), and read docs/mcp.md for the copy-paste setup the project maintains.

Frequently asked questions

Official sources

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