solana-infra-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct operation: health check, fee estimation, transaction submission, epoch info, leader schedule, and latency comparison. No two tools overlap in purpose, despite rpc_health and latency_compare both touching latency metrics.
Naming Consistency4/5
All tool names use snake_case and are descriptive, but the pattern varies between noun-based (rpc_health, epoch_info), verb-initial (submit_transaction), and verb-final (latency_compare). This minor inconsistency prevents a perfect score.
Tool Count5/5
With 6 tools, the server is well-scoped for a Solana infrastructure toolkit. Each tool earns its place, covering monitoring, fee estimation, and transaction submission without unnecessary overhead.
Completeness4/5
The set covers health, fee estimation, transaction submission, and network timing comprehensively. Minor gaps like a getRecentBlockhash or getBalance tool exist, but the keyless submission design makes these optional rather than critical.
Average 3.8/5 across 6 of 6 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 6 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries full responsibility for behavioral disclosure. It does not explicitly state that this is a read-only query, how it handles RPC errors, or what the default behavior is regarding the optional URL parameter, aside from the schema's mention of defaults.
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 concise phrase that lists all relevant output fields without any fluff or repetition. It is front-loaded and adequately sized for the tool's simplicity.
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 simple nature of the tool (one optional parameter, no output schema), the description provides a clear list of returned values. However, it does not explain the return format or the effect of the 'url' parameter on which RPC endpoint is queried, so minor gaps remain.
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% because the only parameter ('url') has a clear description of its default behavior. The tool description adds no additional parameter semantics, but since the schema already covers it, a baseline score of 3 is appropriate.
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 clearly identifies the tool as returning current epoch, slot index/slots-in-epoch, absolute slot, and block height. Although it lacks an explicit verb like 'get' or 'retrieve', the content effectively distinguishes it from sibling tools such as rpc_health or next_leaders by its focus on timing/block data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description does not mention any specific conditions, prerequisites, or exclusions, leaving the agent to infer usage solely from the output fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must convey behavior. It mentions that latency is 'measured', implying a network call, but does not disclose side effects, error behavior, or that it performs a live request. It also does not state that the operation is read-only.
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, information-dense sentence with no filler. All listed items (health, version, slot, latency) are relevant and front-loaded.
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?
While the tool is simple (one optional parameter, no output schema), the description only lists return values without explaining the output format or any defaults (though defaults are in the schema). It is adequate but leaves room for details like JSON structure or error conditions.
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 fully describes the 'url' parameter with its default behavior (SOLANA_RPC_URL or public mainnet-beta), providing 100% coverage. The description adds no additional parameter details, so the 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 lists the specific outputs: health, solana-core version, current slot, and getSlot latency, for a Solana RPC endpoint. This distinguishes it from siblings like priority_fee_estimate or submit_transaction, which target different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus alternatives such as latency_compare or epoch_info. The intended use case is implied by the name and description, but no context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only query by describing the return data, but it doesn't explicitly state that it makes an RPC call, its dependencies, or any potential errors. The 'from the current slot' phrase adds useful context about the data source.
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 that efficiently states the tool's purpose and use case, with no redundant words.
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 description is sufficient for a simple read-only tool: it states what is returned (slot leaders), the reference point (current slot), and the intended use case. It doesn't describe return format or error behavior, but the absence of an output schema and the simplicity of the tool make this acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention any parameters. The schema covers url (with a description) but lacks a description for count, relying only on constraints. Since the description adds no parameter-level information, it does not compensate for the 50% schema coverage gap.
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 clearly states the tool returns the next N slot leaders (validator identities) from the current slot, distinguishing it from sibling tools like rpc_health or priority_fee_estimate. However, it lacks an explicit verb like 'get' or 'fetch', making it slightly less direct.
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 a clear use case ('for timing transaction submission'), indicating when to use the tool. It does not explicitly mention alternatives or exclusion criteria, but the context is strong enough to guide selection among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It adds useful behavioral context, such as 'network-inclusive - not a landing/first-seen proxy', which clarifies the measurement semantics. It does not mention auth or side effects, but these are less critical for a read-only latency 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 one concise sentence that front-loads the main action and includes a clarifying caveat. Every word earns its place, with no redundancy.
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 simplicity (2 optional params, no output schema), the description covers the core purpose, default behavior, and a key behavioral nuance. It does not explain the return format, but for a latency comparison tool this is not a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage for parameters, and the description only implicitly references the 'urls' parameter via 'endpoints' and default vs. public. The 'samples' parameter is not explained at all, leaving its purpose unclear.
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 measures getSlot read-latency (p50) across endpoints, which is a specific verb+resource. It also distinguishes itself from siblings by focusing on latency comparison, not health or transaction submission.
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 clear context by mentioning the default comparison between the configured endpoint and public mainnet-beta, and the network-inclusive behavior. It does not explicitly exclude alternatives, but the use case is evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavior. It indicates the tool reads recent fee distribution data, which is non-destructive, but it does not explicitly state it is read-only or mention rate limits or other side effects. The provided detail about the response format adds some value beyond the name.
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, well-structured sentence that front-loads the key information: what it returns, the specific percentiles, units, and the intended use. Every word earns its place, with no redundant phrasing.
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?
For a tool with one optional parameter and no output schema, the description fully explains the output distribution and its purpose. It is complete for a fee-estimation tool and does not leave significant gaps for an agent to misuse it.
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 already documents the single optional 'url' parameter with 100% coverage. The description does not add additional meaning about the parameter beyond its purpose, but the schema is sufficient. The baseline of 3 applies because schema coverage is high.
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 returns a prioritization-fee distribution with specific percentiles (p50/p75/p90/max) and units (micro-lamports per CU). It also states its purpose ('to price compute-unit fees for landing'), making it distinct from sibling tools like rpc_health or submit_transaction.
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 tool is used for pricing compute-unit fees before landing transactions. It does not explicitly name alternatives or exclusions, but the context is clear and no sibling tool serves a similar purpose, so no exclusions are necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden of behavioral disclosure. It transparently states the server never signs or holds keys and that it confirms on-chain inclusion (landed slot + time). However, it does not mention timeout/error behavior or irreversible 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?
Two short sentences with no filler; all content is functional and front-loaded.
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?
Description covers main purpose and key behavior, and hints at output (landed slot + time). But it omits semantics/edge behavior for maxWaitMs and error handling, and with no output schema, return details are sparse.
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?
Description clarifies that the signedTransaction is 'caller-SIGNED' and 'keyless', adding meaning beyond the schema's 'fully signed transaction'. The url and maxWaitMs parameters are not elaborated beyond schema/defaults.
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?
Description uses specific verb 'Relay' and resource 'caller-SIGNED base64 transaction', with clear goal 'confirm actual on-chain inclusion'. Clearly differentiates from read-only sibling tools like rpc_health and epoch_info.
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 states 'sign upstream, submit here' and 'Keyless', indicating this tool is for already-signed transactions. Provides clear context for when to use, though it doesn't explicitly exclude alternatives or name sibling alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![solana-infra-mcp MCP server](https://glama.ai/mcp/servers/rpc-edge/solana-infra-mcp/badges/card.svg)](https://glama.ai/mcp/servers/rpc-edge/solana-infra-mcp)

Score Badge

Copy to your README.md:

[![solana-infra-mcp MCP server](https://glama.ai/mcp/servers/rpc-edge/solana-infra-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rpc-edge/solana-infra-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/rpc-edge/solana-infra-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server