Paid Solana transaction safety and token risk checks over x402. No account or API key required.
Scored across 4 tools
The two check tools target distinct objects (token risk vs transaction simulation), and the job tools handle different lifecycle stages (retrieving results vs retrying failures). No two tools overlap in purpose.
All tool names use a snake_case verb_noun structure, with check_solana_* clearly marking the two main checks and get_job_result/retry_failed_job following the same verb-first pattern. The naming is predictable and consistent.
Four tools is a well-scoped surface for a focused security-checking service. Each tool serves a necessary role in the paid async workflow without redundancy.
The core lifecycle is covered: submit a token or transaction check, fetch the queued result, and retry on failure. An explicit job status endpoint or cancellation would be a minor addition, but the current set has no dead ends.
Check pump.fun token rug flags and measured precision. Costs $0.01 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | ||
| prefer_async | No |
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 the $0.01 USDC cost, which is useful, but it does not mention whether the operation is read-only, what happens when prefer_async is used, what a result looks like, or any failure behavior. The phrase 'measured precision' is vague and unexplained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary purpose is front-loaded, and the cost information is a discrete, useful second sentence that earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and an async-related parameter, the description is incomplete. It does not explain prefer_async, the relationship to get_job_result, or what information is returned. The cost and purpose are present, but an agent would not know how to handle the async path or interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'mint' parameter or the 'prefer_async' boolean. It also fails to mention that prefer_async likely relates to the job/result flow visible in sibling tools. The description adds no meaning beyond the bare schema field names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('pump.fun token rug flags and measured precision'), which clearly indicates the tool's purpose. It is distinct enough from sibling check_solana_transaction by focusing on token risk, though it does not explicitly name or contrast with any sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus check_solana_transaction, get_job_result, or retry_failed_job. It also does not mention any prerequisites, context, or exclusions. The only usage hint is the cost, not a selection condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Simulate an unsigned Solana transaction and return ALLOW, WARN or BLOCK with reasons. Costs $0.01 USDC.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | ||
| signer | No | ||
| transaction | Yes | ||
| prefer_async | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It adds useful context: the simulation returns a verdict (ALLOW/WARN/BLOCK) with reasons, and it costs $0.01 USDC. However, it does not explicitly state that the tool performs no on-chain side effects (simulation implies this but not guaranteed), nor does it mention authentication requirements, rate limits, or whether the result is returned directly or via an async job (given prefer_async). The cost disclosure is valuable, but the picture is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence plus the cost detail. It is front-loaded with the core action and outcome, and the cost is an important practical detail that earns its place. No filler or redundancy. This is exactly the right size for the information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 4 parameters, no output schema, and no annotations. The description explains what the tool does and the verdict types, but not how the result is returned (e.g., direct response vs. a job ID for get_job_result), what to do after calling, or the role of parameters like `prefer_async` and `signer`. An agent would lack critical context for integrating the call into a workflow, especially given the sibling get_job_result and retry_failed_job imply async processing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 implies that `transaction` is the unsigned transaction to simulate, but gives no meaning for `signer`, `intent`, or `prefer_async`. These parameter names are somewhat self-explanatory from the schema titles, but the description adds no semantic detail to help an agent construct correct arguments. It fails to bridge the documentation gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Simulate an unsigned Solana transaction') and the specific outcome ('return ALLOW, WARN or BLOCK with reasons'). This distinguishes it from the siblings: check_solana_token_risk focuses on token risk, not transaction simulation, while get_job_result and retry_failed_job are about job management. An agent can immediately tell this tool is for pre-transaction simulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you should call this tool when you have an unsigned Solana transaction you want to simulate before sending. However, it does not explicitly state when to prefer this over check_solana_token_risk or how to handle asynchronous execution via prefer_async. No alternatives or exclusions are mentioned, leaving some ambiguity about the decision boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the result of an accepted queued check for free.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds 'for free', which is a useful cost detail, but it does not mention whether the call is safe, what happens if the job is not ready, whether it deletes anything, or what the response structure is. For a tool with no annotation coverage, this is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the core action and resource. 'For free' is a brief but valuable addition. There is no fluff, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is too thin. It does not explain the prerequisite of having previously submitted an accepted queued check, nor what the result contains or how it is returned. An agent has enough to attempt the call but not enough to handle success or failure correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 for the undocumented parameter. 'job_id' is only described as belonging to an 'accepted queued check', which adds some context but does not explain format, how to obtain it, or any validation rules. The added meaning is marginal and insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('get the result') and a specific resource ('accepted queued check'), which distinguishes it from sibling tools that perform checks or retry jobs. The term 'accepted queued check' is somewhat niche but unambiguous in context. It does not explicitly contrast with siblings, but the purpose is evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus the siblings. It implies usage after a check is accepted and queued, but does not state that prerequisite, nor does it mention alternatives or exclusion conditions. The agent must infer the calling context from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retry a failed paid job for free.
| Name | Required | Description | Default |
|---|---|---|---|
| job_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the action is a retry and that it is free, but it does not disclose potential side effects, whether the job must be in a specific state, or what happens on success or failure. For a mutation tool, this is insufficient context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but at the expense of necessary detail. It is not padded, but it is under-specified; it fails to include any elaboration that would make it a useful, self-contained guide. This is closer to an under-specified tagline than a proper tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and no annotations, the description is minimal. It does not explain what the tool returns, what 'failed paid job' implies, or any prerequisites. An agent calling this tool would have only a vague idea of its behavior, so it is not complete enough for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the job_id parameter at all. Since schema description coverage is 0%, the description should compensate by explaining what job_id refers to, but it does not. The agent gets no additional meaning beyond the schema's type definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('retry') and resource ('failed paid job'), and adds the qualifier 'for free.' This distinguishes it from siblings like check_solana_token_risk, check_solana_transaction, and get_job_result, which are all read-oriented. However, it lacks detail on what 'retry' actually does operationally, so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description does not mention any preconditions (e.g., job must be in a failed state), nor does it explain why one might choose this over get_job_result or the check tools. The agent is left to infer the use case from the name and one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_solana_token_riskcheck_solana_transactionget_job_resultretry_failed_jobPay-per-call Solana token risk intelligence: 8 tools via x402. From $0.005 USDC, no API key.
Pay-per-call Solana data over x402 for AI agents: balances, tokens, txs, risk and MCP trust checks.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Solana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Add one secure layer between your agents and this server.