Solana MCP by Vybe

Name: Solana MCP by Vybe
Author: vybenetwork

Server Details

Solana MCP developer toolkit: wallets, trades, markets, PnL, transfers, onchain, swaps & API tools.

If you are the author of this connector, you can claim ownership with GitHub, an HTTP challenge, or a DNS record. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Uptime: 91.6% over 41 days
Last Tested: 2026-09-27 11:09
Transport: Streamable HTTP · MCP 2025-11-25
URL
Repository: vybenetwork/solana-mcp-vybe
GitHub Stars: 1,352
Server Listing: Solana MCP by Vybe

TDQS

A4.1/5.0

Scored 2026-09-21 21:46 across 7 tools

Disambiguation4/5

The three discovery tools (list, search, get) and the two query tools are clearly separated by descriptions, with query-vybe-api and query-vybe-api-batch being the closest pair but explicitly scoped differently. build-vybe-transaction and pay-with-x402 occupy distinct roles, so confusion is unlikely.

Naming Consistency4/5

Most tools follow a predictable verb_object snake_case pattern (list-endpoints, search-endpoints, get-endpoint, query-vybe-api). The main deviation is pay-with-x402, which uses a verb-preposition-noun structure, and the 'vybe' infix is slightly inconsistent but still readable.

Tool Count5/5

Seven tools is a well-scoped count for an API wrapper server, covering endpoint discovery, single reads, batch reads, payment access, and transaction building. Each tool earns its place without redundancy or bloat.

Completeness5/5

The tool surface covers the full workflow: discovering and inspecting endpoints, running single and batch read queries, paying for API access, and constructing common Solana transactions. The lack of transaction submission is explicitly intentional for security, so it does not create a dead end.

Available Tools

7 tools

build-vybe-transactionBuild Unsigned Solana TransactionA

Destructive

Inspect

Builds an unsigned Solana transaction with the Vybe Solana API (see https://docs.vybenetwork.com) for a token swap, a token-account close, or an MEV withdrawal, and returns it as base64 for the user to review and sign in their own wallet. This tool never signs, submits, or broadcasts a transaction, never moves funds on its own, and never accepts private keys. Use query-vybe-api with /v4/trading/swap-quote first when the user only wants a price quote.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	JSON request body for the endpoint. Call get-endpoint for the exact schema.
`path`	Yes	Transaction builder endpoint to call.

Output Schema

ParametersJSON Schema

Name	Required	Description
`body`	No
`status`	No

TDQS

A4.6/5.0

Behavior5/5

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

Despite having annotations (readOnlyHint=false, destructiveHint=true), the description adds critical context: it never signs, submits, or broadcasts, never moves funds, and never accepts private keys. This goes beyond what annotations indicate, clarifying the safe nature despite the destructive hint, and is especially valuable for a transaction-building tool.

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 three sentences: front-loaded with the core purpose and source, followed by safety disclaimers and usage guidance. Every sentence earns its place with zero waste, making it concise and well-structured.

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?

Given the tool's complexity (mutation, destructive hint, output schema present) and rich schema coverage, the description is quite complete—it covers purpose, usage, safety, and routing to sibling tools. It could be a 5, but the body parameter relies on get-endpoint for details, which slightly reduces completeness.

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?

The input schema provides detailed descriptions for both parameters (path enum with descriptions, body with reference to get-endpoint for exact schema). The description does not add extra parameter semantics beyond pointing to get-endpoint for the body schema, so a baseline of 3 is appropriate given 100% schema coverage.

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 the verb 'builds an unsigned Solana transaction' and the resource (Vybe Solana API), and lists the three specific operations it supports (swap, close-token-accounts, withdraw-mev), which distinguishes it from query-vybe-api and other siblings. This is specific and unambiguous.

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 provides explicit guidance on when to use this tool vs alternatives: 'Use query-vybe-api with /v4/trading/swap-quote first when the user only wants a price quote.' This explicitly names the sibling and the condition that selects it, which is excellent.

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

get-endpointGet Endpoint DetailsA

Read-onlyIdempotent

Inspect

Gets detailed information about a specific API endpoint, including security schemes and servers

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	The API endpoint path (e.g. /api/v1/users).
`method`	Yes	The HTTP method (e.g. GET, POST, PUT, DELETE).

Output Schema

ParametersJSON Schema

Name	Required	Description
`path`	No
`method`	No
`operation`	No

TDQS

A4.2/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, covering the safety profile. The description adds value by specifying that the response includes security schemes and servers, which is behavioral information about the output. There is no contradiction; the description aligns with the read-only nature.

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 a single, efficient sentence that front-loads the purpose and includes the most relevant output aspects. No wasted words, and it avoids redundancy with the schema or annotations.

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?

The tool is a simple getter with a clear output schema (has_output_schema=true), so return values are already defined. The description covers the essential purpose and key output content. It could be improved by explicitly mentioning that this is for a single endpoint, but that is implied. Given the schema and annotations, it is sufficiently complete.

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?

The input schema has 100% description coverage for both parameters (path and method), so the schema already fully documents them. The description adds no new syntactic or semantic detail beyond what the schema provides. Per the rubric, with high coverage, a baseline of 3 is appropriate.

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 a specific verb ('gets'), a resource ('detailed information about a specific API endpoint'), and names two concrete content aspects ('security schemes and servers'). This distinguishes it from siblings like list-endpoints (which lists all) and search-endpoints (which searches), making the tool's role unambiguous.

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 the appropriate use case: retrieve details for one known endpoint (path+method). It does not explicitly mention alternatives or exclusions, but the wording 'specific API endpoint' signals when to choose this over list or search tools. Given sibling names in context, the agent can infer the distinction, though explicit guidance would be stronger.

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

list-endpointsList API EndpointsA

Read-onlyIdempotent

Inspect

Lists all API paths and their HTTP methods with summaries, organized by path. Results can be passed directly into 'get-endpoint'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`endpoints`	No

TDQS

A4.2/5.0

Behavior3/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 safety profile is covered. The description adds the useful behavioral detail that results are organized by path and can be piped into get-endpoint, but doesn't describe pagination or response size limits. With annotations covering the safety profile, a 3 is appropriate.

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?

Two sentences with no wasted words. The core function is stated first, and the downstream usage hint is a valuable addition that earns its place.

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?

The tool has no parameters and an output schema exists, so the description doesn't need to explain return values. The only minor gap is not mentioning whether the list is exhaustive or if there are limits, but for a simple listing tool with strong annotations, this is nearly complete.

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 tool has zero parameters, so the schema provides no parameter documentation. The description compensates by explaining what the tool returns (paths, HTTP methods, summaries) and how results can be used downstream. This is sufficient for a no-parameter tool.

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 the tool lists all API paths and their HTTP methods with summaries, organized by path. This is a specific verb+resource combination that distinguishes it from siblings like get-endpoint and search-endpoints.

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 notes results can be passed directly into 'get-endpoint', which provides a clear usage context. It doesn't explicitly mention when not to use it versus search-endpoints, but the zero-parameter design and 'all endpoints' scope make the use case clear.

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

pay-with-x402Pay With X402B

Read-onlyIdempotent

Inspect

Before calling any Vybe endpoint without an API key (e.g. AI agent, throwaway script, premium-only path), use this to access the same endpoint via x402 pay-per-call USDC on Solana.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`baseUrl`	No
`guidance`	No

TDQS

B3.4/5.0

Behavior1/5

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

The description usefully discloses the x402 pay-per-call USDC mechanism. However, the annotations declare readOnlyHint=true and idempotentHint=true, while a pay-per-call action that spends USDC implies a financial side effect and is not naturally idempotent. This is an annotation contradiction that could mislead an agent about the tool's side effects.

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 a single sentence with the triggering condition front-loaded and the action stated immediately after. It contains no filler, no repetition of the title, and every clause contributes useful selection guidance.

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

Completeness3/5

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

Combined with the empty input schema and the presence of an output schema, the description provides the core selection and invocation context. It leaves operational details unstated, such as prerequisites like a Solana wallet or what happens if no endpoint is pending, and the annotation contradiction further reduces completeness and trust.

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 has zero properties, so schema-description coverage is trivially 100%, giving a baseline of 4. The description adds no parameter-specific detail because there are none, though it hints at an implicit 'same endpoint' context without defining how that context is established.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear action: use this tool to access a Vybe endpoint via x402 pay-per-call when no API key is available. The mechanism and resource are specified, and the 'without an API key' condition helps distinguish it from API-key-based call tools, though it does not explicitly name a sibling alternative.

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 provides an explicit when-to-use rule: before calling any Vybe endpoint without an API key, with concrete examples like AI agents and premium-only paths. It does not mention when not to use it or name alternative tools, but the context is clear and actionable.

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

query-vybe-apiQuery Vybe Solana APIA

Read-onlyIdempotent

Inspect

Runs a read-only GET request against a documented /v4 path on the Vybe Solana API (see https://docs.vybenetwork.com) and returns live Solana data: token prices, holders, liquidity and candles; wallet balances, PnL, counterparties and DeFi positions; markets, trades, transfers, top traders and labeled accounts. Use list-endpoints or search-endpoints to find a path and get-endpoint to check its parameters first. This tool cannot create, modify, or delete anything.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Vybe API path beginning with /v4, with any path parameters already substituted (e.g. /v4/wallets/HN7.../pnl).
`query`	No	Optional query string parameters as name/value pairs (e.g. {"limit": "3", "resolution": "1d"}).

Output Schema

ParametersJSON Schema

Name	Required	Description
`body`	No
`status`	No

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds behavioral context beyond these: it specifies the HTTP method (GET), notes the data is 'live,' and restates the read-only nature. It does not cover rate limits or auth, but given the strong annotation coverage this is sufficient.

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 two sentences and front-loads the core purpose. The long enumeration of data types adds clarity but is somewhat verbose. The inline documentation link is helpful but could be a footnote. Overall, each part contributes to usability, though slightly more concise would be ideal.

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?

The tool has an output schema, so return values are covered. The description appropriately covers purpose, usage routing, read-only safety, and includes a link to full documentation. For a tool with only two parameters and clear annotations, nothing essential is missing.

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 input schema fully documents both path and query with examples. The description does not add meaning beyond the schema; it only reiterates the path format (via schema) and points to get-endpoint for checking parameters. Baseline 3 is appropriate.

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 a specific verb and resource: runs a read-only GET request against a documented /v4 path on the Vybe Solana API, and enumerates the types of data returned. It distinguishes itself from siblings by mentioning list-endpoints, search-endpoints, and get-endpoint for finding paths, and by explicitly stating it cannot create, modify, or delete anything, which separates it from build-vybe-transaction and pay-with-x402.

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 gives explicit when-to-use guidance for related tools: 'Use list-endpoints or search-endpoints to find a path and get-endpoint to check its parameters first.' It also provides a when-not-to-use signal by stating the tool cannot create, modify, or delete anything, implying write operations belong elsewhere. This is direct, actionable routing.

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

query-vybe-api-batchQuery Vybe Solana API (Batch Wallets)A

Read-onlyIdempotent

Inspect

Reads Solana wallet data for many addresses in one call from the Vybe Solana API (see https://docs.vybenetwork.com). These endpoints use a POST body only to carry the list of wallet addresses; they do not create, modify, or delete any data. Use query-vybe-api for single-wallet and all other reads.

ParametersJSON Schema

Name	Required	Description	Default
`body`	Yes	JSON request body for the endpoint, typically the list of wallet addresses. Call get-endpoint for the exact schema.
`path`	Yes	Batch read endpoint to call.

Output Schema

ParametersJSON Schema

Name	Required	Description
`body`	No
`status`	No

TDQS

A4.4/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 description reinforces safety by stating it does not create, modify, or delete data. It adds context that endpoints use POST body only to carry addresses, which is useful for understanding the API's behavior. It could mention rate limits or response format, but with strong annotations, this is sufficient.

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 two sentences with no fluff. It front-loads the primary purpose and immediately provides routing guidance. Every sentence earns its place, covering purpose, usage, and safety in a compact form.

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?

Given the tool has an output schema and full schema coverage, the description covers the essential for calling it correctly. It explains the batch nature, the safety profile, and the distinction from the sibling. It might benefit from mentioning error handling or rate limits, but the annotations and output schema fill the gaps. It is complete enough for an agent to select and invoke.

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 coverage is 100%, so parameters are fully described in the schema. The description adds the crucial insight that the body is typically a list of wallet addresses, which the schema already hints at, but it also directs to get-endpoint for exact schema, adding value. However, it doesn't explain path parameters beyond what the enum provides.

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 it reads Solana wallet data for many addresses in one call, specifying the resource (batch wallets) and the action (read). It distinguishes from the sibling query-vybe-api by name and scope, noting it is for single-wallet and other reads, which prevents confusion.

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 to use query-vybe-api for single-wallet and all other reads, providing an exclusion. It also notes the POST body is only for carrying addresses, implying no side effects. This gives clear when-to-use guidance and names the alternative.

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

search-endpointsSearch API EndpointsA

Read-onlyIdempotent

Inspect

Performs a deep search through paths, operations, and parameters to discover relevant API endpoints. Use this tool to find specific API capabilities, required parameters, or data models based on search keywords. Results can be passed directly into 'get-endpoint'.

ParametersJSON Schema

Name	Required	Description	Default
`pattern`	Yes	Search pattern (case-insensitive)

Output Schema

ParametersJSON Schema

Name	Required	Description
`matches`	No

TDQS

A4.2/5.0

Behavior4/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds behavioral context about the deep search scope and the integration with get-endpoint, which goes beyond the annotations. There is no contradiction.

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?

Three sentences, each earning its place: purpose, usage, and workflow integration. No unnecessary words. Front-loaded with the action.

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?

For a single-parameter read-only search tool with an output schema, the description covers purpose, usage, and workflow. It doesn't discuss result limits or output details, but the output schema is expected to handle that. The description is sufficient for an agent to call it 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?

The schema covers the only parameter 'pattern' with a description 'Search pattern (case-insensitive)'. The description doesn't add much beyond that, only referring to 'search keywords'. Since schema coverage is 100%, a baseline of 3 is appropriate; the description adds minimal value but doesn't need to compensate.

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 the verb 'search' and the resource 'API endpoints', and specifies the search scope (paths, operations, parameters). It also distinguishes from siblings by emphasizing 'deep search' and the workflow integration with 'get-endpoint', making it clear when to use this tool over list-endpoints or others.

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 explicitly says 'Use this tool to find specific API capabilities, required parameters, or data models based on search keywords.' This gives clear usage context. It also notes that results can be passed to 'get-endpoint', implying a follow-up workflow. However, it doesn't explicitly contrast with alternatives like 'list-endpoints', so a score of 4 is appropriate.

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.

4 tool updatesSep 16, 2026
- Addedbuild-vybe-transaction
- Removedexecute-request
- Addedquery-vybe-api
- Addedquery-vybe-api-batch

5 tool updatesSep 16, 2026

Changedexecute-request2 fields changed

changedInput schema / properties / harRequest / properties / postData / anyOf

Previous value: -[
-  {
-    "properties": {
-      "mimeType": {
-        "description": "e.g. application/json, text/plain",
-        "type": "string"
-      },
-      "text": {
-        "description": "Raw request body as a string",
-        "type": "string"
-      }
-    },
-    "required": [
-      "mimeType",
-      "text"
-    ],
-    "type": "object"
-  },
-  {
-    "properties": {
-      "mimeType": {
-        "description": "e.g. multipart/form-data, application/x-www-form-urlencoded. Use multipart/form-data for form submissions.",
-        "type": "string"
-      },
-      "params": {
-        "description": "Form parameters. Use this instead of text for multipart/form-data and url-encoded requests.",
-        "items": {
-          "properties": {
-            "name": {
-              "type": "string"
-            },
-            "value": {
-              "type": "string"
-            }
-          },
-          "required": [
-            "name"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    },
-    "required": [
-      "mimeType",
-      "params"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "mimeType": {
+        "type": "string"
+      },
+      "text": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "mimeType",
+      "text"
+    ],
+    "type": "object"
+  },
+  {
+    "properties": {
+      "mimeType": {
+        "type": "string"
+      },
+      "params": {
+        "items": {
+          "properties": {
+            "name": {
+              "type": "string"
+            },
+            "value": {
+              "type": "string"
+            }
+          },
+          "required": [
+            "name"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "mimeType",
+      "params"
+    ],
+    "type": "object"
+  }
+]

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "body": {},
+    "status": {
+      "type": "integer"
+    }
+  },
+  "type": "object"
+}

Changedget-endpoint1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "method": {
+      "type": "string"
+    },
+    "operation": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "path": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedlist-endpoints1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "endpoints": {
+      "additionalProperties": {
+        "items": {
+          "properties": {
+            "method": {
+              "type": "string"
+            },
+            "summary": {
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "type": "object"
+    }
+  },
+  "type": "object"
+}

Changedpay-with-x4022 fields changed

addedInput schema / $schema

Added value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "baseUrl": {
+      "type": "string"
+    },
+    "guidance": {
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changedsearch-endpoints1 field changed

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "matches": {
+      "items": {
+        "properties": {
+          "method": {
+            "type": "string"
+          },
+          "path": {
+            "type": "string"
+          },
+          "summary": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}

5 tool updatesAug 24, 2026
- First observedexecute-request
- First observedget-endpoint
- First observedlist-endpoints
- First observedpay-with-x402
- First observedsearch-endpoints

Related MCP Connectors

Solana MCP by Vybe A
io.github.vybenetwork
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
Blockchain Cryptocurrency Web3 & Decentralized Tech
521,352
Noesis — Solana On-Chain Intelligence A
io.github.Rengon0x
Solana on-chain intelligence — token scans, wallet profiling, bundle detection, 19 MCP tools.
Blockchain Web3 & Decentralized Tech Cryptocurrency
21
tenzro-solana A
xyz.tenzro
Solana tools over MCP: Jupiter swaps, SPL tokens, Metaplex NFTs, SNS domains, network stats.
Blockchain Cryptocurrency Web3 & Decentralized Tech
2
Tenzro Solana MCP A
network.tenzro
Solana MCP: Jupiter swaps, SPL transfers, Metaplex NFTs, Bonfida SNS, slot/TPS, staking.
Blockchain Cryptocurrency
2

Related MCP Servers

NoesisAPI
Blockchain Web3 & Decentralized Tech Finance
Rengon0x
A
license
Not graded
quality
D
maintenance
Solana on-chain intelligence API — token scans, wallet PnL, bundle detection, fresh wallets, dev profiling. MCP server for Claude, Cursor & AI agents. Live PumpFun/Raydium streams
Updated 4 months ago (2026-05-18 14:26 UTC)
1
MIT
solagent-mcp
Blockchain Cryptocurrency Web3 & Decentralized Tech
warfield2016
A
license
Not graded
quality
D
maintenance
Enables AI agents to interact with the Solana blockchain through MCP, supporting wallet queries, token swaps via Jupiter, token transfers, and market data.
Updated 6 months ago (2026-04-08 06:29 UTC)
MIT
Sol MCP — Solana Token Risk &
Blockchain Cryptocurrency Finance
autonsol
A
license
A
quality
F
maintenance
Real-time Solana token risk scoring, momentum signals, and graduation alerts via MCP. Free tier with 4 tools (no auth), PRO tier with 6 tools + batch analysis ($0.01/call via x402).
Updated 6 months ago (2026-04-05 12:58 UTC)
6
1
MIT
helius-forensics-mcp
drtiibiird
A
license
Not graded
quality
D
maintenance
Enables Solana wallet forensics via MCP, including tracing funds, identifying entities, scoring risk, and comparing wallets using Helius APIs.
Updated 6 months ago (2026-03-16 18:44 UTC)
MIT

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Server Details

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Related MCP Connectors

Related MCP Servers

Glama MCP Gateway

Resources