Sonar-MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool targets a distinct resource or query, but get_slot and get_epoch_info overlap slightly since both report the current slot. The descriptions clarify their different scopes, so ambiguity is minimal.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with the 'get_' prefix. Variations like get_epoch_info or get_token_supply still adhere to the pattern, and there is no mixing of styles.
Tool Count5/5
Eight tools is well within the ideal range and appropriate for a read-only Solana RPC server. Each tool provides a needed query without bloat or redundancy.
Completeness4/5
The set covers core Solana read operations: slot, epoch, health, balances, token accounts, transactions, signatures, and supply. Missing queries like get_block or get_program_accounts are minor gaps, and the server's scope is clearly read-only.
Average 3.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool returns current epoch progress and lists the return fields, which is useful. However, it does not describe how the 'commitment' or 'min_context_slot' parameters affect behavior, nor any other behavioral details beyond the basic read operation.
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, compact sentence that is front-loaded with the core purpose. Every word adds value, and the list of return fields is densely informative without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description must explain return values, and it does list the fields. However, it completely omits parameter semantics and does not clarify how commitment values work or what min_context_slot means. Given the lack of annotations and schema descriptions, the tool is under-specified for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description does not mention the parameters commitment or min_context_slot at all. The agent must infer meaning solely from parameter names and defaults, which is insufficient for correct usage.
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's purpose with a specific verb ('Get') and resource ('current epoch progress') and lists the exact fields returned (absolute slot, block height, epoch, slot index/total). This is easily distinguishable from sibling tools like get_slot or get_health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving epoch progress information but does not explicitly mention when to choose this tool over alternatives. No exclusion context is given, but the purpose is clear enough that an agent would know to use it when epoch-related data is needed.
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?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It only says 'recent' without detailing the ordering, default limit, return format, or whether it returns only confirmed transactions. This is insufficient transparency for a tool that returns a list of signatures.
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, focused sentence with no superfluous words. It front-loads the core function and is appropriately sized for a simple read operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain the expected response, the meaning of 'recent' (e.g., time range, confirmation status), and how parameters like 'limit' affect results. It does none of this, leaving the description incomplete for effective tool invocation.
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?
Schema description coverage is 0%, and the description only mentions 'address' without adding semantic meaning beyond the parameter name. The 'limit' parameter is completely ignored, leaving the agent to guess its purpose and behavior. The description fails to compensate for the lack of schema documentation.
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 function: 'Get recent transaction signatures involving an address.' It uses a specific verb and resource, and the scope ('involving an address') distinguishes it from sibling tools like get_transaction or get_sol_balance.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing recent signatures for a given address, but it does not explicitly state when to choose this over alternatives, nor does it mention any exclusions or prerequisites. The purpose is clear, but no direct comparative guidance is provided.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get full details' which indicates a read operation, but gives no information about return format, possible errors (e.g., invalid signature), permissions, rate limits, or what 'full details' actually includes. This is a minimal disclosure that goes little beyond the tool's purpose.
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, short sentence of 13 words, front-loaded with the verb 'Get' and the resource. Every word earns its place, with no redundancy or filler. It is appropriately sized for the tool's simplicity.
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?
With only one parameter, no output schema, and no annotations, the description is relatively simple. However, 'full details' is vague—it does not enumerate what details are returned (e.g., timestamp, fee, status), which is significant because there is no output schema to clarify. It also does not link to sibling tools to help the AI choose among them. Thus, while adequate for a basic getter, it leaves notable gaps.
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 0%, so the description must compensate. It does explain that the 'signature' parameter identifies the transaction ('by its signature'), which adds meaning beyond the schema's bare string type. However, it does not specify the expected format or any constraints (e.g., length, encoding), which prevents a higher score.
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's action: 'Get full details for a transaction by its signature.' It uses a specific verb ('Get') and resource ('transaction details'), and the parameter ('signature') is included. This distinguishes it from siblings like get_signatures_for_address, which lists signatures rather than retrieving full details for one.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you have a signature and want full transaction details, use this tool. However, there is no explicit guidance on when NOT to use it, no alternatives are named, and no distinction from other siblings (e.g., get_signatures_for_address) is provided. Thus guidance is implied but not explicit.
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 bears the full burden. It discloses that the result includes both lamports and SOL, which is useful. However, it does not mention how the commitment parameter affects the result, potential errors, or network behavior. For a simple read operation, this is adequate but not rich.
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, efficiently structured sentence that front-loads the core purpose and return format. No wasted words.
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?
The tool is simple, but the absence of output schema and annotations increases the description's responsibility. It covers purpose and return units, but omits the commitment parameter's role and potential edge cases. The description is adequate for a basic balance check but not fully complete.
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?
Schema description coverage is 0%, so the description must compensate. It only implicitly covers the 'address' parameter by mentioning 'wallet address.' The 'commitment' parameter is entirely undocumented in both the schema and description. Since half of the parameters are unexplained, the description fails to fully compensate for the schema gap.
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's function: 'Get the SOL balance (in lamports and SOL) for a wallet address.' It uses a specific verb ('Get'), identifies the resource ('SOL balance'), and specifies the scope ('wallet address'). This distinguishes it from siblings like get_token_accounts_by_owner or get_token_supply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (for checking SOL balance of a specific wallet) but provides no explicit exclusions or alternatives. It doesn't mention that it is for SOL only, not SPL tokens, or when another tool might be more appropriate. Context is clear but guidance is minimal.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool returns and does not mention read-only guarantees, error behavior (e.g., invalid mint), or any rate limits or other operational traits. The word 'Get' implies a read operation, but that is not explicitly disclosed.
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, front-loaded sentence with no filler. Every word adds value, succinctly conveying the tool's purpose.
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 (one parameter, no output schema, no annotations), the description is fairly complete: it states the return value (total supply and decimals) and the required subject (SPL token mint). It does not explain return structure or error cases, but these are less critical for such a straightforward getter.
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 has only one parameter 'mint' with no description, and schema coverage is 0%. The description partially compensates by explaining that the mint is an 'SPL token mint', giving context to the parameter, but it does not specify format (e.g., base58 string) or any additional constraints beyond the schema.
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's function: 'Get total supply and decimals for an SPL token mint.' It uses a specific verb ('Get') and identifies the exact resource (total supply and decimals) and scope (SPL token mint), distinguishing it from siblings like get_sol_balance or get_token_accounts_by_owner.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied by the description—one would use this tool to obtain token supply information—but there is no explicit guidance on when to choose this tool over alternatives, nor any mention of exclusions or prerequisites.
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 carries the full burden of behavioral disclosure. It only states the purpose and does not mention what the response looks like (e.g., boolean, status object), whether it performs a lightweight check, or any side effects. This leaves the agent uncertain about the return format and how to interpret the result.
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 sentence that directly states the purpose. Every word is useful, and it is appropriately sized for such a simple tool with no parameters. There is no redundancy or unnecessary detail.
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?
Given the tool's low complexity and absence of parameters or annotations, the description is minimally viable but has clear gaps. Most notably, it does not specify the return value, which is critical since there is no output schema to provide that information. An agent may not know how to interpret the result or whether 'healthy' is conveyed as a boolean, string, or object.
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, and the schema is empty with 100% coverage. There is nothing to explain, so the description does not need to add parameter details. The baseline score for 0 parameters is 4, and the description does not detract from this.
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's function: 'Check whether the RPC node is healthy.' This uses a specific verb ('check') and a specific resource ('RPC node'), and it is unambiguous in distinguishing itself from sibling tools like get_slot or get_balance, which query other kinds of data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you need to determine node health, but it provides no explicit guidance on when to use it versus alternatives, nor any exclusions. Given the tool's simplicity, the implied usage is clear enough, but it lacks the explicit context present in higher-scoring examples.
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 provided, the description carries the full burden. It accurately indicates a read operation ('get'), which implies non-mutating behavior, but it does not disclose additional behavioral traits such as return format, potential errors, or latency. The transparency is adequate but not rich.
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, compact sentence (12 words) that is front-loaded with the verb and resource. It contains no redundant information, making it highly 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?
The tool is simple with one optional parameter and no output schema. The description sufficiently explains the tool's purpose and the key parameter, making it complete for a basic getter. It does not explain return values, but for such a simple tool, this is a minor gap.
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 schema leaves the 'commitment' parameter undocumented with 0% coverage. The description adds significant meaning by mentioning 'at the given commitment level', clarifying that the commitment parameter influences which slot is returned. This compensates for the schema's lack of detail.
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 'Get' and the resource 'slot', and specifies the nuance of 'the node has reached' with 'commitment level'. It is distinct from sibling tools like get_epoch_info or get_health, which target different data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving the current slot, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context is clear but lacks explicit comparison to sibling tools.
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 provided, the description carries the full burden. It discloses that the tool lists token accounts and can filter by mint, but it does not mention pagination, response format, ordering, or any rate limits. As a simple read operation, this is partially sufficient but lacks deeper behavioral context.
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 is both concise and information-dense. It front-loads the core action and resource, and every word adds value. No filler or repetition.
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 (two scalar parameters, no output schema), the description covers the essential usage. However, it does not describe the return structure or any edge cases, such as what happens if the wallet has no token accounts. A slightly more detailed description would fully satisfy this dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain the parameters. It implicitly defines 'address' as the wallet and 'mint' as the optional filter token, which adds meaningful semantics beyond the bare schema titles. Both parameters are covered, fully compensating for the lack of schema descriptions.
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 uses a specific verb 'List' with a clear resource 'SPL token accounts' and scope 'owned by a wallet'. It also mentions the optional mint filtering, which differentiates it from sibling tools like get_sol_balance and get_token_supply.
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 primary use case: retrieving token accounts for a given wallet, with an optional filter by mint. It does not explicitly state when not to use it or name alternatives, but the sibling tools are clearly distinct in function, so the context is sufficiently clear.
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:

[![Sonar-MCP MCP server](https://glama.ai/mcp/servers/AllenGeorge08/Sonar-MCP/badges/card.svg)](https://glama.ai/mcp/servers/AllenGeorge08/Sonar-MCP)

Score Badge

Copy to your README.md:

[![Sonar-MCP MCP server](https://glama.ai/mcp/servers/AllenGeorge08/Sonar-MCP/badges/score.svg)](https://glama.ai/mcp/servers/AllenGeorge08/Sonar-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/AllenGeorge08/Sonar-MCP'

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