soldefi-mcp

Server Quality Checklist

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

Latest release: v0.3.0
Disambiguation4/5
Tools have largely distinct purposes, such as pool analysis, deployer check, honeypot scan, and exit risk. Some overlap exists between 'can_i_sell' and 'check_exit_risk' as both involve selling, but their focus differs (simulation vs. risk assessment). Overall, agents should be able to differentiate based on descriptions.
Naming Consistency5/5
All tools use consistent snake_case with a verb_noun pattern (e.g., analyze_pools, check_deployer, scan_honeypot). Even compound names like 'can_i_sell' follow a predictable style. No mixing of conventions.
Tool Count5/5
With 10 tools covering various aspects of Solana token risk analysis, the count is well-scoped. Each tool has a clear role, and the set is neither too sparse nor bloated.
Completeness4/5
The tool set covers major workflows: deployer analysis, honeypot detection, exit risk, liquidity assessment, and pool ranking. A minor gap is the lack of a basic token metadata tool (e.g., supply, decimals). However, the focus on risk assessment is adequately covered.
Average 4/5 across 10 of 10 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 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
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.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It mentions the tool is paid ($0.04), but does not state whether it is read-only, has side effects, requires authentication, or has rate limits. This lack of transparency is a significant gap for a paid tool.
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 front-loaded with the core question and is information-dense. While slightly verbose, every sentence adds value. It avoids redundancy and is well-structured.
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 complexity (paid, multiple data sources, verdict output), the description explains inputs and the verdict levels. However, without an output schema, it lacks details on the response structure (e.g., additional data or errors). A bit more completeness would improve usability.
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 description adds minimal value beyond the schema. It provides context about the token being for exit risk assessment but does not elaborate on the format or constraints of the mint parameter beyond the schema's own description.
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: answering if a Solana token can be exited and at what cost, using Birdeye signals and Jupiter exit-slippage. It distinguishes from siblings like 'can_i_sell' by mentioning specific data sources and a verdict, making its unique value clear.
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 indicates the tool is for exit-planning and trading agents, but does not explicitly state when not to use it or mention alternative tools. No guidance on prerequisites or limitations is 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?
No annotations provided, so description carries full burden. It mentions the tool is paid ($0.02) and performs a live Jupiter trade (executes a buy-sell round trip). However, it does not disclose whether the trade might fail, any required permissions, or potential side effects. Some behavioral context is provided but key details are missing.
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 a single paragraph that efficiently conveys purpose, specific checks, outputs, and cost. It is front-loaded with the main purpose. Some restructuring for readability could improve it, but it is concise and each sentence adds value.
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 single parameter and no output schema, the description explains inputs, actions, outputs, and cost. It covers the key aspects but misses operational context such as prerequisites (e.g., network connectivity), failure scenarios, or execution time. Mostly complete for the tool's complexity.
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% with a single well-described parameter. The description adds context about the scan's use of the mint address but does not provide additional semantic meaning beyond what the schema already offers. Baseline score 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 the tool performs a rug/honeypot scan on a Solana SPL token by mint address. It lists specific checks (mint/freeze authority, transfer tax, top-holder concentration, live Jupiter round trip) and outputs (risk score, flags, verdict). This distinguishes it from sibling tools like scan_honeypot_batch and validate_mint.
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 evaluating Solana token safety, but does not explicitly state when to use this tool versus siblings like can_i_sell or check_exit_risk. No exclusions or alternatives are mentioned.
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 full burden. It discloses the tool's behavior: it retrieves deployer info, computes a risk score, and flags risks. It also notes the tool is paid. However, it does not mention failure modes or limitations (e.g., invalid mint address).
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 with no wasted words. The first sentence establishes the main action, the second details the output, and the third notes the cost. It is front-loaded and efficient.
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 tool with no output schema, the description covers essential functionality and output. It explains what information is returned and what risks are flagged. Minor details about edge cases or error handling are missing, but overall it is adequate.
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% with a clear description of the 'mint' parameter. The description adds context by mentioning 'creator wallet' and 'deployer still holds', but this does not significantly enhance understanding 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 specifically states it traces the deployer of a Solana token, including the creator wallet, holdings, and wallets' ages, and returns a risk score. This clearly distinguishes it from sibling tools like scan_honeypot or check_exit_risk, which focus on other aspects.
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 for checking deployer reputation but does not explicitly state when to use it versus siblings like scan_wallet_risk or validate_mint. No guidance on when not to use or prerequisites is 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?
No annotations are provided, so the description carries the full burden. It discloses that it is a paid call and outlines the output: per-token honeypot verdict with risk score, flags, and sellability. It does not cover other behavioral aspects like rate limits, authentication, or error handling.
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 long, front-loading the action and key details (batch size, cost, output). Every part adds value, and there is no redundant information.
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 batch scan tool with a single parameter and no output schema, the description covers the primary purpose, batch limit, cost advantage, and output summary. It could potentially mention validation of mint addresses, but overall 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 schema describes the 'mints' array parameter with min and max items. The description does not add additional meaning beyond '1-10 Solana SPL token mints to scan.' Since schema coverage is 100%, 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 states the tool scans up to 10 Solana token mints in one call, providing per-token honeypot verdicts (risk score, flags, sellability). It distinguishes itself from individual scan tools like 'scan_honeypot' by emphasizing batch processing and cost savings.
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 explicitly states ideal use cases: 'vetting a watchlist or a set of launch candidates at once.' It also mentions the cost ($0.10) and the advantage over individual scans. However, it does not specify when NOT to use it or provide direct comparisons to 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 provided, the description carries the full burden. It discloses that the tool filters out wash-traded and fake-volume pools, ranks by risk-adjusted fee yield, and returns an excluded list explaining dropped pools. It also mentions it's paid ($0.05). This provides key behavioral traits without contradictions.
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 with no fluff. The first sentence states the main purpose, the second details the output, and the third notes the cost. It is front-loaded and efficient.
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 no output schema, the description explains what is returned (clean pools and excluded list) and which DEXes are covered. It is fairly complete for a tool with 2 parameters, though it could be more explicit about the output format.
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 the baseline is 3. The description does not add parameter-specific meaning beyond what the schema already describes (limit and minTvlUsd with defaults). It adds context about the overall output (excluded list) but not parameter details.
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 returns the best Solana DEX pools with wash-trading and fake-volume filtered out, ranked by risk-adjusted fee yield. It specifies the specific verb 'returns' and the resource 'best Solana DEX pools', distinguishing it from sibling tools like 'analyze_pools' which likely analyze pools rather than return a ranked list.
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 context (for decision-ready pools from top DEXes) but does not explicitly state when to use this tool versus alternatives like 'analyze_pools' or when not to use it. No exclusions or alternative recommendations 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 takes full responsibility. It states 'free local' validation, implying no network calls or costs, but does not describe what happens on invalid input (e.g., error or boolean return) or any other behavioral 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 two sentences (16 words) with no redundancy. Every word serves a purpose: 'free local', 'validate', 'single Solana mint', and the use-case hint.
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 (1 param, no output schema), the description covers the purpose and when to use it. It could mention the return type or behavior on invalid addresses, but the core intent is clear.
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%, and the schema already describes the parameter as a base58 Solana mint address. The description adds 'base58 address-format validation' but does not enhance meaning 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 validates a Solana mint address using base58 format validation. It specifies the verb ('validate') and resource ('Solana mint address'), and the 'free local' qualifier distinguishes it from sibling tools like scan_honeypot or check_deployer which perform more complex analysis.
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 advises using the tool to avoid paying on a malformed mint, providing a clear use case. However, it does not explicitly mention when not to use it or suggest alternatives like scan_honeypot for deeper checks.
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 provided, the description carries full burden. It discloses it is a live simulation, answers specific metrics (USDC recovered, price impact, tax/friction loss), and importantly states it is paid ($0.01). It does not detail side effects or failure modes, but the simulation nature implies no destructive actions.
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 concise (three sentences) with no wasted words. It front-loads the core action immediately and provides additional context efficiently.
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 no output schema, the description covers key output aspects (USDC recovered, price impact, loss). It also mentions cost. For a tool with two parameters, it is fairly complete, though it could hint at the response format.
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 already documents both parameters clearly. The description echoes the parameter meanings but does not add new semantic information beyond the schema, hence baseline score of 3.
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 specific verbs ('Simulate exiting') and clearly states the resource (Solana token via Jupiter round trip). It answers concrete questions ('can I get $X out right now, and at what cost?') and distinguishes from siblings like scan_honeypot by focusing on live simulation at a given size.
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 for use (when checking sellability at a specific USD amount) but does not explicitly state when not to use it or compare to alternatives. The mention of catching honeypots could overlap with scan_honeypot, but the live simulation aspect differentiates it.
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 provided, so description must cover behavioral traits. It explains return value (score+verdict) and nature (durability signal). Does not discuss rate limits, auth, or side effects, but is upfront about paid 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?
Two sentences, front-loaded with key purpose, details, and limitations. No wasted 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?
Given the tool's simplicity (1 param, no output schema, no nested objects), the description sufficiently covers what it does and returns. Could mention if results are cached or real-time, but not essential.
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?
Only one parameter 'mint' with schema description at 100% coverage. Description adds value by specifying it's a Solana SPL token mint address and providing an example (USDC), which aids correct invocation.
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?
Clear verb ('Assess'), specific resource ('Solana token liquidity'), and detailed what it checks (pools, depth, burned supply, authorities). Distinguishes from siblings like check_exit_risk and scan_honeypot by focusing on liquidity durability.
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?
States it's a durability signal, not a proof, and mentions paid cost ($0.02). Implies use for rug-pull assessment, but lacks explicit when-to-use or when-not-to-use comparisons with siblings.
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?
Since no annotations are provided, the description fully discloses the behavior: reads holdings, performs scans, limits to 10 positions, returns risk summary, and costs $0.05. Lacks details on rate limits or return format, but sufficient for a read-only scan 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?
Three sentences, each earning its place: action, audience, cost. No wasted words, front-loaded with key information.
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 a single parameter, no output schema, and no annotations, the description covers essential aspects: input, process, limit, output summary, and cost. Missing explicit return format details but still comprehensive enough for an agent.
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 baseline is 3. The description does not add significant new meaning beyond the parameter's schema description (which already states 'Solana wallet address (base58)').
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?
Clearly states the action: read a Solana wallet's SPL holdings and run honeypot/rug scans on each (up to 10 positions). Returns per-token risk and a summary. Distinct from sibling tools by focusing on wallet-level scan with a positional limit.
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?
Explicitly targets portfolio-manager and risk agents auditing exposure. Notes the cost ($0.05). While it doesn't explicitly list alternatives, the sibling tool names and context imply when to use this vs individual token scans.
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?
Discloses all key behavioral aspects: real fee APR calculation, wash-trade risk checks, rug verdict, slippage ladder, recommendation. Also states it's paid ($0.04). With no annotations, description carries full burden and does it well.
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?
Concise paragraph front-loaded with purpose. Every sentence adds distinct information. No fluff.
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?
No output schema, but description lists all key outputs. Covers enough for an agent to understand return value. Could include response format or example but not necessary given brevity.
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?
Schema coverage 100% with good descriptions. Description adds context: mint example, optional trade sizes with default values. Adds value beyond schema without redundancy.
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?
Clearly states specific verb 'analyze' and resource 'liquidity pools' across multiple DEXes. Lists detailed outputs (fee APR, wash-trade risk, rug verdict, slippage ladder, recommendation), distinguishing it from siblings like 'top_pools' or 'scan_honeypot'.
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?
Implies use for deep analysis and risk assessment, mentions paid nature. No explicit when-not or alternatives, but context makes intended use 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:

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

Score Badge

Copy to your README.md:

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

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