This server provides Solana blockchain tools and media utility transforms, paid per-call via USDC micropayments with no account or API key required.
Analyze Solana Transaction ($0.004): Explain a confirmed transaction including fees, compute usage, SOL/token deltas, failure classification, and retry guidance.
Simulate Solana Transaction ($0.008): Pre-broadcast simulation of a serialized transaction to classify potential failures before sending to the network.
Estimate Solana Priority Fees ($0.002): Retrieve network-wide or account-localized priority-fee quantiles to help choose an optimal compute-unit price.
Analyze Solana Token ($0.006): Inspect a token mint for authorities, Token-2022 controls, holder concentration, and risk flags.
Convert PDF to Markdown ($0.0025): Extract a PDF (URL or base64, up to 100 pages) into page-delimited Markdown with metadata and a source digest.
Normalize Audio Loudness ($0.01): Normalize a public HTTPS or base64 audio file to a bounded MP3 (default -16 LUFS, max 180s), returning loudness measurements and content digests.
Provides tools for analyzing Solana transactions, priority fees, token analysis, and transaction simulation, enabling AI agents to diagnose failed transactions, get fee estimates, and inspect token risks on the Solana blockchain.
Turn a failed Solana signature into a support-ready answer: what landed, what changed, why it failed, and what is safe to try next. The package connects to Utilia, handles x402 payments locally, and can run as a guarded CLI, a budget-capped fee watcher, or a standard stdio MCP server.
No Utilia account, API key, or subscription is required. Calls cost between $0.002 and $0.01 in USDC on Solana or Base.
Four guarded examples cover automatic x402 v2 payment and retry over Base MCP, Solana MCP, Base HTTP, and Solana HTTP. Each fixture pins the host, network, asset, receiver, resource, timeout, per-call maximum, one-call total budget, and exact tool before a wallet may sign.
See examples/buyers/README.md. Fixture output is explicitly labeled as an operator compatibility test, not customer demand.
For a single public, machine-verifiable Base artifact, use the stricter compatibility fixture:
BASE_PRIVATE_KEY=0xYOUR_32_BYTE_LOW_BALANCE_KEY npm run --silent compatibility:base -- --source your_runtime_fixtureIt caps the payment at $0.002, reuses one request ID across challenge and retry, prints a response SHA-256 and settlement evidence, and ships with a public JSON Schema plus an offline verifier.
Related MCP server: anchor-x402-mcp
Use a dedicated low-balance Solana automation wallet that holds a small amount of mainnet USDC and SOL for fees:
export SOLANA_KEYPAIR_PATH=/absolute/path/to/automation-wallet.json
npx -y utilia-solana-agent@0.5.8 doctor
npx -y utilia-solana-agent@0.5.8 transaction <signature>The diagnosis costs exactly $0.004 USDC and returns confirmation state, fee, compute use, SOL and token deltas, program logs, a stable failure class, and a retry-aware suggested action.
export SOLANA_KEYPAIR_PATH=/absolute/path/to/automation-wallet.json
npx -y utilia-solana-agent@0.5.8 watch-fees \
--every 12m \
--max-calls 25The first JSONL result is immediate, then one result is emitted every 12 minutes:
five calls per hour for $0.01, with an automatic $0.05 maximum. Each line
includes the observation time, fee quantiles, paid amount, and settlement
transaction. Add --accounts account1,account2 to localize the estimate to the
writable accounts in a transaction.
Agents that already use AgentCash can make the lowest-cost live call without handling a private key directly:
npx -y agentcash@latest balance
npx -y agentcash@latest fetch \
https://api.utilia.ink/base/v1/fees/priority --yesThis route returns live Solana priority-fee data and settles the exact $0.002
USDC payment on Base. AgentCash creates and manages its own wallet on first
use; balance reports its available funds and funding accounts. Utilia never
receives or controls the payer's key.
Install the transaction workflow into Codex, Claude Code, OpenClaw, Cursor, or any other agent supported by the open Skills CLI:
npx skills add mohamedkuch/utilia-solana-agent \
--skill utilia-solana-transaction-diagnosis -g -yThen ask the agent to use $utilia-solana-transaction-diagnosis to explain a
failed signature. The broader $utilia-solana-preflight skill also covers live
priority fees, token risk, and pre-broadcast simulation.
Tool | Result | Price |
| Recent priority-fee quantiles | $0.002 |
| Confirmed transaction, deltas, logs, failure guidance | $0.004 |
| Authorities, Token-2022 controls, concentration, risk flags | $0.006 |
| Pre-broadcast simulation and failure classification | $0.008 |
| Page-delimited Markdown, metadata, and a source digest | $0.0025 |
| Bounded normalized MP3, loudness measurements, and digests | $0.01 |
The same guarded client also exposes two bounded non-Solana transforms:
npx -y utilia-solana-agent@0.5.8 pdf-to-markdown \
https://example.com/document.pdf --max-pages 20
npx -y utilia-solana-agent@0.5.8 audio-normalize \
https://example.com/voice-note.wav --output voice-note-normalized.mp3PDF conversion costs $0.0025 USDC and returns page-delimited Markdown, metadata, and a source digest. Audio normalization costs $0.01 USDC, targets -16 integrated LUFS by default, verifies the saved MP3 locally, and returns loudness evidence plus content digests.
Dedicated skills are available as utilia-pdf-to-markdown and
utilia-audio-normalization.
Use a dedicated low-balance Solana automation wallet that holds a small amount of mainnet USDC and SOL for fees.
export SOLANA_KEYPAIR_PATH=/absolute/path/to/automation-wallet.json
npx -y utilia-solana-agent doctor
npx -y utilia-solana-agent feesFor a JSONL fee feed at five calls per hour, capped at 25 calls and $0.05 total:
npx -y utilia-solana-agent watch-fees --every 12m --max-calls 25The first result is immediate, then one result is emitted every 12 minutes. The
process stops after 25 calls; Ctrl-C stops it sooner. Localize estimates to the
writable accounts used by your transaction builder with
--accounts account1,account2.
You can alternatively set SOLANA_PRIVATE_KEY to a base58-encoded 64-byte private
key. Environment variables are inherited by the local process; the private key is
never sent to Utilia.
Use the same wallet already attached to Solana Agent Kit. The plugin adds four budget-capped, read-only actions without asking for a second private key:
import { SolanaAgentKit } from "solana-agent-kit";
import { createUtiliaPlugin } from "utilia-solana-agent";
const agent = new SolanaAgentKit(wallet, rpcUrl, {}).use(createUtiliaPlugin());
const fees = await agent.methods.utiliaPriorityFees(agent, {
accounts: writableAccounts,
});The registered agent actions are UTILIA_PRIORITY_FEES,
UTILIA_SIMULATE_TRANSACTION, UTILIA_ANALYZE_TRANSACTION, and
UTILIA_ANALYZE_TOKEN. Payments are signed by the Agent Kit wallet only after the
same receiver, asset, network, and per-call maximum checks described below pass.
The wallet must implement Agent Kit's signMessage() method and hold a small amount
of Solana mainnet USDC; the facilitator pays the transaction fee.
Add this stdio server to any MCP client that supports an executable command:
{
"mcpServers": {
"utilia": {
"command": "npx",
"args": ["-y", "utilia-solana-agent@0.5.8", "mcp"],
"env": {
"SOLANA_KEYPAIR_PATH": "/absolute/path/to/automation-wallet.json"
}
}
}
}The local bridge advertises all six Utilia tools without loading or transmitting a
wallet. When the agent calls one, the bridge loads the configured wallet locally,
verifies the payment request, signs the exact USDC payment, and returns the paid
result. A wallet is therefore required for tool execution, not for MCP initialization
or tools/list.
npx -y utilia-solana-agent fees [account1,account2]
npx -y utilia-solana-agent watch-fees [--every 12m] [--max-calls 25] [--accounts account1,account2]
npx -y utilia-solana-agent transaction <signature>
npx -y utilia-solana-agent simulate <serialized-transaction> [base64|base58]
npx -y utilia-solana-agent token <mint>
npx -y utilia-solana-agent@0.5.8 audio-normalize <public-https-audio-url> [--output normalized.mp3] [--target-lufs -16] [--max-seconds 180]
npx -y utilia-solana-agent@0.5.8 pdf <public-https-pdf-url> [max-pages]
npx -y utilia-solana-agent@0.5.8 pdf-to-markdown <public-https-pdf-url> [--max-pages 50]
npx -y utilia-solana-agent call <tool-name> '<json-arguments>'The package will only approve a payment when every field matches:
network: Solana mainnet
asset: official Solana mainnet USDC
receiver: Utilia's published wallet
maximum: 10,000 atomic USDC, or $0.01, per tool call
A changed receiver, asset, network, zero amount, malformed amount, or higher amount is rejected before signing. The package has no withdrawal, swap, token-launch, or arbitrary-transaction capability.
Remote MCP: https://api.utilia.ink/mcp
OpenAPI: https://api.utilia.ink/openapi.json
x402 discovery: https://api.utilia.ink/.well-known/x402
MCP registry package: ink.utilia/solana-preflight
MIT
Normalize public HTTPS or base64 audio to a bounded MP3 with loudness evidence and content digests. Costs $0.01.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| maxSeconds | No | ||
| targetLufs | No | ||
| audioBase64 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds value beyond annotations by mentioning the monetary cost ($0.01) and output details (bounded MP3, evidence, digests). It does not contradict the readOnlyHint, idempotentHint, or openWorldHint annotations.
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?
Single sentence with no filler, directly conveying the core functionality and cost. Every word contributes to understanding.
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?
Given no output schema and four optional parameters, the description covers the main use case and cost. It could elaborate on output format details or edge cases, but is largely adequate.
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 explains two parameters (url and audioBase64) as input sources, but does not clarify maxSeconds or targetLufs. With 0% schema coverage, the description partially compensates but leaves gaps.
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 the action (normalize), input sources (HTTPS or base64 audio), and output (bounded MP3 with loudness evidence and content digests). It is specific and distinguishes the tool from unrelated siblings.
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 for audio normalization but lacks explicit guidance on when to use or avoid it, or comparisons with alternatives. Since siblings are unrelated, confusion is minimal, but no direct usage instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract a PDF into page-delimited Markdown with metadata and a source digest. Costs $0.0025.
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | ||
| title | No | ||
| maxPages | No | ||
| pdfBase64 | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, open-world behavior. The description adds cost information ($0.0025), which is extra behavioral context. No contradictions.
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?
Two sentences that efficiently convey the core function and cost. No unnecessary words or repetition.
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?
Given 4 parameters with no schema descriptions and no output schema, the description is too brief. It fails to explain parameter usage (e.g., url vs base64) or output format details.
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%. The description does not elaborate on any of the 4 parameters (url, title, maxPages, pdfBase64), leaving them entirely to the schema names and types.
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 it extracts a PDF into page-delimited Markdown with metadata and a source digest, and mentions a cost. It distinguishes from unrelated sibling tools (blockchain, audio).
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?
No explicit guidance on when to use this tool vs alternatives. While siblings are unrelated, the description lacks any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return current network-wide or account-localized priority-fee quantiles before choosing a compute-unit price. Costs $0.002.
| Name | Required | Description | Default |
|---|---|---|---|
| accounts | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint. The description adds transparency about cost ($0.002). It does not mention other behavioral aspects like rate limits or data freshness, but the annotations cover safety and idempotency.
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 extremely concise with two sentences, front-loading the core purpose. Every word adds value, and there is no unnecessary information.
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 is simple with one optional parameter and no output schema. The description covers the purpose, scope, and cost, but does not describe the output structure (e.g., which quantiles are returned). This minor gap prevents a perfect score.
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%, but the description clarifies the sole parameter 'accounts' by implying that providing account addresses yields localized quantiles while omitting it yields network-wide ones. This adds meaning beyond the schema, though it does not detail account format or behavior of empty array.
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 the tool returns 'priority-fee quantiles' for either network-wide or account-localized scope, with the specific verb 'Return' and resource 'priority-fee quantiles'. It distinguishes itself from unrelated siblings, and the context 'before choosing a compute-unit price' clarifies its purpose.
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 implicitly indicates when to use ('before choosing a compute-unit price') and mentions cost ($0.002). However, it does not explicitly exclude scenarios or mention alternative tools, though siblings are unrelated, making this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a token mint, authorities, concentration, and risks. Costs $0.006.
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, and idempotentHint. The description adds useful behavioral info about cost ($0.006) and implies no side effects via 'Inspect'. However, it doesn't detail rate limits or authentication needs, which are covered by annotations.
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?
Extremely concise: one sentence and a cost note. The most critical action ('Inspect') is front-loaded. No wasted words.
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 simple tool with one parameter and rich annotations, the description covers the core purpose and cost. It does not explain what 'authorities, concentration, and risks' entail, but these are Solana-specific domain terms. Lacks output format details but acceptable given no output schema.
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?
With 0% schema description coverage, the description compensates by mentioning 'token mint' which clarifies that the 'mint' parameter is the token's mint address. This adds meaning beyond the schema's bare string type, though it could be more explicit.
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 the tool inspects a Solana token mint, listing specific aspects (authorities, concentration, risks). It distinguishes well from sibling tools like solana_priority_fees or pdf_to_markdown, which cover different domains.
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?
No guidance on when or when not to use this tool, nor any mention of alternative tools. The description only states what it does, leaving the agent without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool targets a completely different domain or operation: two focus on Solana blockchain (priority fees, token analysis), two on media processing (PDF to markdown, audio normalization). No overlap in functionality.
All tool names use snake_case with a clear verb_noun pattern: solana_priority_fees, solana_token_analysis, pdf_to_markdown, normalize_audio. Consistent and predictable.
Four tools is on the lower side but acceptable. The server covers two distinct domains, but the count is borderline for either domain alone. Could be expanded but not problematic.
The server lacks many expected operations: no Solana wallet/balance/transfer tools, no other media conversions (e.g., images, video), and no lifecycle coverage. Gaps are significant for both domains.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Multi-chain wallet MCP. 18 tools: balance, swap, bridge, stake, claim. Pay-per-call USDC (x402 v2).
Solana MCP for wallets, trades, markets, PnL, transfers, onchain data, signable swaps and API tools.
Metered MCP tools: free discovery over MCP; per-call execution settled in USDC via x402 v2.
Solana-native MCP gateway for SAP, DeFi tools, SNS identity, and x402 payments.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/mohamedkuch/utilia-solana-agent'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
