This server enables AI agents to make payments and purchases on Solana through the Solinkify platform, with built-in spending caps and authorization controls.
Wallet & Authorization
wallet_status — View agent wallet address, SOL balance, stablecoin balances, pre-paid balance, and remaining budget
spend_authority_status — Inspect the on-chain SpendAuthority (caps, daily spending, revocation status) for owner-mode payments
Gate (x402 Paywalls)
gate_get_price — Preview the price of an x402 paywall without paying
gate_fetch — Fetch gated content with automatic payment
gate_prepaid_balance — Check the pre-paid stablecoin balance for gate payments
gate_prepaid_deposit — Deposit stablecoin into a pre-paid balance for future requests
gate_subscribe — Buy or renew a subscription plan for a gated endpoint
DataHub Marketplace
datahub_search — Search datasets by keyword, category, or browse all listings
datahub_buy — Purchase a dataset and receive a download link
datahub_review — Rate and review a purchased dataset (verified-purchase only)
datahub_subscribe — Subscribe to a recurring dataset for time-based access
datahub_download — Get a fresh download link for an already-owned dataset
Merchant Checkout
pay_get_session — Inspect a checkout session (WooCommerce, OpenCart, PrestaShop) before paying
pay_checkout — Pay a pending checkout session via agent or owner wallet (using on-chain SpendAuthority)
Social Commerce (Blinks)
social_get_blink — Inspect a Solana Blink product link from social media before buying
social_buy_blink — Purchase a product from a Blink link, returning a receipt and download link
Allows inspecting and paying checkout sessions from PrestaShop stores via Solinkify Pay.
Provides tools for making payments on the Solana blockchain, including paying for datasets, gated content, checkout sessions, and Blink purchases using stablecoins like USDC/USDT.
Allows inspecting and paying checkout sessions from WooCommerce stores via Solinkify Pay.
MCP (Model Context Protocol) server that lets any AI agent — Claude Desktop, Claude Code, Cursor, or your own MCP host — pay for things on Solana through Solinkify, with hard spending caps. Agentic payments on the x402 standard, as a set of tools your agent already knows how to call:
Gate (x402 paywalls): find priced endpoints in the public registry, preview prices, auto-pay HTTP 402 content, manage a pre-paid balance, buy subscriptions.
DataHub: search the dataset marketplace and buy datasets (99% goes to the seller, download link returned).
Pay: inspect and settle store checkout sessions (WooCommerce, OpenCart, PrestaShop, hosted checkout).
Social Commerce: inspect and buy products from Blink links exactly as they circulate on X (share link, Actions URL, or raw id).
Add to your MCP host config (e.g. Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"solinkify": {
"command": "npx",
"args": ["-y", "@solinkify/mcp"],
"env": {
"SOLINKIFY_WALLET_PATH": "/path/to/agent-keypair.json",
"SOLINKIFY_MAX_PAYMENT_USD": "1",
"SOLINKIFY_DAILY_CAP_USD": "10"
}
}
}
}The wallet is a standard Solana JSON keypair (solana-keygen new -o agent-keypair.json),
funded with a little SOL for fees and the stablecoin you want to spend
(USDC/USDT).
It is optional at startup: the server connects and lists its tools with no wallet configured, and the read-only tools (price preview, dataset search, checkout quotes) work as they are. Only the tools that spend ask for a keypair, and they say so in the tool result rather than failing at launch.
docker build -t solinkify-mcp .
docker run -i --rm solinkify-mcp # starts, tools listed
docker run -i --rm -v "$PWD/agent-keypair.json:/wallet.json:ro" \
-e SOLINKIFY_WALLET_PATH=/wallet.json solinkify-mcp # able to pay-i is required: stdin and stdout carry the MCP protocol.
Related MCP server: BotWallet MCP Server
Tool | What it does |
| Address, SOL, stablecoin balances, prepaid balance, remaining budget |
| On-chain SpendAuthority (owner mode): caps, spent/left today, revoked |
| Browse the public registry of x402-priced endpoints (price, network, access modes, fits-your-cap) |
| Preview an x402 paywall without paying |
| Fetch gated content, auto-paying (prepaid preferred, escrow otherwise); files a signed delivery record when the gate keeps one |
| Compare what the gate says it served with what the agent says it received |
| Manage the pre-paid balance (no per-request signing) |
| Buy a creator's subscription plan (price read on-chain first) |
| Search the DataHub marketplace (results carry |
| Buy a dataset and get the download link |
| Rate a dataset you bought (verified-purchase gated server-side) |
| Time-based access to a recurring dataset (on-chain plan; renew extends expiry) |
| Fresh download link via purchase receipt or active subscription (no payment) |
| Inspect a checkout session (accepts the full checkout URL) |
| Pay a pending checkout session; the merchant's order is marked paid. With |
| Inspect a Blink product link (title, price, seller) without paying |
| Buy from a Blink link; returns the receipt + download link |
Moving money was never the hard part; scoped, revocable authority is. The agent never holds your main wallet: it runs on a dedicated keypair funded only with what it is allowed to spend (the outer bound), and the server enforces two hard caps before any funds move, on every tool:
SOLINKIFY_MAX_PAYMENT_USD — max for a single payment (default 1)
SOLINKIFY_DAILY_CAP_USD — max total per UTC day (default 10, persisted
in ~/.solinkify/mcp-spend.json, fail-closed)
For Gate paywalls there is an on-chain scoped budget too: a prepaid balance is
deposited once into a program-owned account and debited per request at
on-chain prices; withdraw_prepaid pulls the remainder back at any time — the
kill switch.
Set SOLINKIFY_OWNER_WALLET to the base58 address of a funds owner and
pay_checkout stops spending from the agent keypair: it settles through
pay_spl_delegated, drawing from the owner's token account under a
SpendAuthority the owner created on-chain — per-payment cap, daily ceiling,
and revoke-as-kill-switch all enforced by the Solana program, not by this
server. The agent wallet only signs and pays tx fees; it never holds the
owner's funds or keys. Inspect the allowance with spend_authority_status.
The owner grants (and can instantly revoke) the allowance with the contract's
create_spend_authority / update_spend_authority / revoke_spend_authority
instructions, keyed to the agent's public key. One SpendAuthority covers one
stablecoin mint. The local SOLINKIFY_MAX_PAYMENT_USD / SOLINKIFY_DAILY_CAP_USD
caps still apply on top (defense in depth). Other paying tools (gate, DataHub,
Blinks) still spend from the agent wallet.
Refusals come back as readable messages the agent can relay to the user. The
server also self-identifies as an AI agent via User-Agent (override with
SOLINKIFY_USER_AGENT), so Gate-protected sites answer with a clean 402
instead of being scraped.
Var | Default | Purpose |
| — (required) | Agent wallet |
| devnet public RPC | Solana RPC |
|
|
|
|
| Solinkify backend |
|
| Per-payment cap |
|
| Daily budget |
| — (off) | Owner mode: |
scripts/qa-battery.mjs drives every tool through a real MCP stdio client
against live devnet; scripts/qa-guard-probe.mjs proves both caps refuse.
Buy a DataHub dataset (x402 settlement on Solana, 99% goes to the seller) and return the download link. Pays in USDC by default; set token to USDT to settle in USDT instead. Spending caps apply.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Stablecoin to pay with. The agent wallet must hold this token and a little SOL for fees. Defaults to USDC. | USDC |
| book_id | Yes | The dataset id returned by datahub_search (a uuid), not its title. Buying the same dataset twice pays twice; use datahub_download to re-fetch something already owned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It covers the purchase flow, settlement (x402 on Solana), token options, and that spending caps apply. However, it omits details about error conditions, refunds, or post-purchase state changes, which would improve transparency.
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 sentences long, front-loading the core action and result. Every phrase adds value: the settlement info, default token, alternative, and the caveat about re-buying. No redundant 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?
Given the tool has 2 parameters, no output schema, and no annotations, the description covers the essential context: what the tool does, what information is needed (book_id, token), and key gotchas (spending caps, duplicate purchase). However, it could be more complete by describing error handling or the download link format.
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 coverage is 100%, but the description adds value beyond the schema: for token, it explains the default and wallet requirements; for book_id, it specifies the correct format (uuid from datahub_search) and warns against duplicate purchases. This enriches the schema definitions.
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 (buy), resource (DataHub dataset), and the outcome (returns download link). It also distinguishes from siblings like datahub_download (for re-fetching) and datahub_subscribe by mentioning the one-time purchase nature.
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 specifies when to use this tool (to buy a dataset) and when not to (buying again if already owned, use datahub_download instead). It also notes the default token (USDC) and alternative (USDT), and mentions spending caps, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a fresh download link for a DataHub dataset the agent already owns, either from a past purchase receipt or an active subscription. Proves ownership with a signed wallet message. Costs nothing, so prefer it over buying the same dataset again.
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Id of a dataset this wallet already owns through datahub_buy or datahub_subscribe. Fails if there is no receipt and no active subscription. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It discloses ownership proof requirement, cost-free nature, and failure conditions. However, it does not specify the return format or any side effects, which would be ideal.
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, front-loaded with the core action, and no wasted words. Every sentence adds value.
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 one-parameter tool with no output schema, the description covers usage conditions, cost, and alternatives. It could be slightly more complete by describing the response (e.g., URL), but not a major gap.
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?
Only one parameter (book_id) with 100% schema coverage. The schema description already includes the same information as the tool description regarding ownership conditions, so the description adds no new semantic value beyond the schema.
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 fetches a download link for a dataset the agent already owns, distinguishing it from buying or subscribing via siblings like datahub_buy and datahub_subscribe.
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?
Explicitly says when to use (when owning dataset from purchase or subscription), advises to prefer it over buying again due to zero cost, and notes the requirement of a signed wallet message.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rate a DataHub dataset you have purchased (1-5 stars, optional comment). Verified-purchase only: the marketplace rejects wallets without a receipt for the dataset. No payment involved.
| Name | Required | Description | Default |
|---|---|---|---|
| rating | Yes | Star rating from 1 (worst) to 5 (best), whole numbers only. | |
| book_id | Yes | Id of a dataset this wallet has already bought. Reviewing without a purchase receipt is rejected. | |
| comment | No | Optional review text, up to 2000 characters. Published publicly next to the rating. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the review is public (via schema comment description, not in description) but does not state whether ratings can be updated, if multiple reviews per dataset are allowed, error states beyond rejection, or if changes are irreversible. This is sparse for a mutation tool.
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 with only essential information: action, constraint, and scope. No wasted words, front-loaded with key purpose.
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?
With 3 parameters, no output schema, and no annotations, the description covers core action and constraint but omits important details: success behavior, error messages, whether review can be edited/deleted, and full public exposure. Adequate but not comprehensive.
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 coverage is 100%, so the description adds minimal value beyond schema. It mentions 'optional comment' and '1-5 stars,' which are already in the schema descriptions. Baseline 3 is appropriate as schema does the heavy lifting.
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?
Description clearly states the action: 'Rate a DataHub dataset you have purchased (1-5 stars, optional comment).' It uses a specific verb ('rate') and resource ('dataset'), and the 'verified-purchase only' condition distinguishes it from siblings like datahub_buy or datahub_download.
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?
Explicit condition: 'Verified-purchase only: the marketplace rejects wallets without a receipt for the dataset.' This tells the agent when to use (only after purchase) and implies when not to (if no receipt). Also clarifies 'No payment involved,' differentiating from transaction tools. No explicit alternatives, but context signals provide sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the Solinkify DataHub marketplace. Returns id, title, price (USD stablecoin), seller, category, and sales count. Datasets: buy with datahub_buy. API listings (kind "api"): the price is per request — access them by calling gate_fetch on their api_base_url.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of listings to return, 1 to 50. Defaults to 10. | |
| query | No | Free-text filter matched against title, author, description, category and format. Omit to browse everything. Plain keywords work best; there is no query syntax. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool returns search results with specific fields and notes price is in USD stablecoin. It also reveals that API listings have per-request pricing and are accessed via gate_fetch, which is important behavioral context. However, it doesn't mention authentication or rate limits.
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 concise (two sentences) and front-loads the main purpose. The second sentence, though slightly run-on, packs useful information about how to handle different result types. Minimal waste.
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, the description lists the return fields explicitly. It also covers the two distinct data kinds and their follow-up tools. It does not mention pagination, ordering, or error handling, but for a search tool this is largely sufficient.
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?
Input schema coverage is 100%, so baseline is 3. The description adds value by explaining that the 'limit' parameter defaults to 10 and must be between 1 and 50, and that the 'query' parameter uses plain keywords with no syntax. It also provides usage guidance for different listing kinds, which goes beyond schema.
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 starts with a clear verb+resource ('Search the Solinkify DataHub marketplace') and specifies the return fields (id, title, price, etc.). It further distinguishes between dataset listings (use datahub_buy) and API listings (use gate_fetch), effectively differentiating this tool from sibling tools.
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 explains when to use the tool (to search the marketplace) and how to act on results: buy datasets with datahub_buy, access API listings via gate_fetch. It also clarifies query behavior ('Plain keywords work best; there is no query syntax'). It doesn't explicitly state when not to use it, but the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Subscribe to a recurring DataHub dataset (time-based access, on-chain payment with the plan's USDC price). While active, every update of the dataset can be fetched with datahub_download — no per-download payment. Renewing extends from the current expiry. Spending caps apply.
| Name | Required | Description | Default |
|---|---|---|---|
| book_id | Yes | Id of a dataset that offers a subscription plan. datahub_search reports one under "subscription"; datasets without a plan must be bought with datahub_buy instead. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: recurring subscription, on-chain payment, no per-download fee, renewal extends from current expiry, and spending caps. Without annotations, the description carries the full burden and provides a clear behavioral picture.
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 three sentences, about 50 words, and front-loads the core purpose. Every sentence adds value without redundancy.
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 the tool's simplicity and lack of output schema, the description covers the essential aspects: subscription nature, payment, usage, renewal, and spending caps. Missing details about return value are minor.
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 single parameter 'book_id' is well-described in the schema, specifying it must be a dataset with a subscription plan. The description does not add additional parameter details beyond the schema, but schema coverage is 100%, so baseline is appropriate.
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 subscribes to a recurring DataHub dataset with time-based access and on-chain payment. It distinguishes from siblings like datahub_buy (for datasets without a subscription plan) and datahub_download (for fetching updates after subscription).
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 indicates when to use the tool: for datasets with a subscription plan, identified via datahub_search. It contrasts with datahub_buy for datasets without a plan, and mentions using datahub_download for fetching updates while subscribed. However, it does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check what each side says was delivered for a payment: the hash the gate filed for what it served, and the hash the agent filed for what it received. Use it to confirm a purchase arrived intact, or to show a discrepancy. Read-only and free. Note it records WHICH bytes were delivered, not whether their contents were correct.
| Name | Required | Description | Default |
|---|---|---|---|
| payment_id | Yes | The payment id returned by gate_fetch. Only payments settled through an escrow have one; prepaid and subscription access do not. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It explicitly states the tool is read-only and free, and notes a key nuance: it records which bytes were delivered, not content correctness. This is comprehensive for a simple 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loading the core action and adding necessary nuance. No superfluous 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?
Given the tool has one parameter, no annotations, and no output schema, the description covers purpose, usage context, behavioral traits, and parameter origin. It is complete for effective agent selection and 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?
Schema coverage is 100% for the single parameter, but the description adds valuable context: payment_id is returned by gate_fetch and only exists for escrow-settled payments. This goes beyond the schema's description and aids correct usage.
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 checks delivery hashes for a payment, comparing gate and agent records. It specifies the purpose: confirm purchase arrival or show discrepancy. This differentiates it from sibling tools like gate_fetch (which returns payment IDs) and datahub_buy (purchase).
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 explains when to use the tool (post-purchase verification) and the parameter description clarifies that payment_id only exists for escrow-settled payments, implying it should not be used for prepaid or subscription access. However, it does not explicitly state when not to use it or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a Gate-protected URL, automatically paying the x402 paywall from the agent wallet (prepaid balance preferred, escrow payment otherwise). Returns the page content plus what was paid. Refuses and explains if the price exceeds the per-payment or daily cap. Ungated URLs are fetched normally and cost nothing.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https:// URL to retrieve. If it answers HTTP 402 the paywall is paid automatically, so check the price with gate_get_price first when the cost matters. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: automatic payment, payment priority (prepaid then escrow), refusal on cap exceed, and no cost for ungated URLs. Since no annotations are provided, the description adequately carries the transparency burden, though it could mention that it deducts from the wallet balance.
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?
Three concise sentences with no fluff. The main action is front-loaded, making it easy to understand quickly.
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 one parameter, no output schema, and no nested objects, the description provides sufficient information about purpose, usage, and behavior. It mentions return value (content and payment info).
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?
Only one parameter 'url' with 100% schema coverage. The parameter description adds value by explaining the automatic payment on HTTP 402 and advising to check price first when cost matters.
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 fetches a Gate-protected URL and automatically pays the paywall. It is distinct from sibling tools like gate_get_price and gate_prepaid_balance.
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 explains that the tool automatically pays from the wallet, prefers prepaid, uses escrow otherwise, and refuses if caps exceeded. It also mentions ungated URLs are free. It suggests checking price first with gate_get_price, but does not explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the public Solinkify registry of x402-priced endpoints: paid APIs and content an agent can buy per request. Returns url, price per request, currency, network and access modes for each one, plus whether it fits the configured spending caps. Use it to find a paid data source without being handed the URL, then call gate_get_price or gate_fetch on the url. Read-only and free. Every entry was verified by machine: it answers a real HTTP 402 with a valid x402 manifest that pays the wallet which listed it.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of endpoints to return, 1 to 100. Defaults to 20. | |
| query | No | Free-text filter matched against title, description and tags. Omit to list everything. Plain keywords work best; there is no query syntax. | |
| max_price_usd | No | Drop endpoints priced above this many USD per request. Omit to see every price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses important behavior: read-only, free, entries verified by machine. With no annotations, this provides adequate transparency. Could note pagination or rate limits, but still good.
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?
Three sentences, front-loaded purpose, no fluff. Every sentence adds value: purpose, return fields, workflow, data quality.
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 3 optional params and no output schema, the description covers what the tool returns and its place in the workflow. could mention default limit behavior, but still complete enough.
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 coverage is 100%, so baseline is 3. The description adds minimal extra semantics beyond schema descriptions, but it does tie params to the tool's purpose (finding paid sources).
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?
Clearly states it browses a registry of x402-priced endpoints, lists returned fields (url, price, etc.), and distinguishes from siblings like gate_get_price and gate_fetch by describing the workflow: find endpoint, then call those tools.
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?
Explicitly tells when to use it ('find a paid data source without being handed the URL') and what to do next ('call gate_get_price or gate_fetch'). Could be improved by mentioning when not to use it compared to sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a Solinkify Gate paywall (HTTP 402 / x402) without paying: price, currency, and available access modes (pay-per-request, prepaid, subscription). Call this before gate_fetch to learn the price. Costs nothing and never moves money.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Absolute https:// URL of the gated page or API endpoint to inspect, e.g. https://example.com/api/report. If the URL is not paywalled the tool says so instead of returning a price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fully discloses non-monetary nature ('costs nothing and never moves money'), behavior when URL not paywalled ('the tool says so instead of returning a price'), and preview functionality without side effects.
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?
Three concise sentences, each providing essential information: first states purpose and outputs, second provides usage guidance, third confirms no cost. No redundant 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?
Given simple tool (1 parameter, no output schema, no nested objects), description is fully complete: covers purpose, inputs, return info, edge case, and usage context. No gaps.
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 has 100% description coverage for the single 'url' parameter. The description adds context: specifies absolute https URL, gives example ('https://example.com/api/report'), and explains edge case behavior if not paywalled, exceeding schema info.
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 uses specific verb 'Preview' and resource 'Solinkify Gate paywall', detailing price, currency, and access modes. It distinguishes itself from sibling tool 'gate_fetch' by stating 'Call this before gate_fetch to learn the price' and clarifies it costs nothing and never moves money.
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?
Clearly states when to use ('Call this before gate_fetch'), what it does not do (cost nothing, never moves money), and provides safety guarantee. Explicitly tells the agent to use this to learn price before gate_fetch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the agent's Solinkify pre-paid balance for a stablecoin (deposited once, then debited per request without signing a transaction each time). Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Stablecoin whose pre-paid balance to read. Balances are tracked per token, so USDC and USDT are separate pots. Defaults to USDC. | USDC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Explains prepaid mechanism (deposited once, debited per request, no signing each time). Declares read-only nature clearly. Could mention auth requirements or rate limits, but sufficient.
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?
One sentence with parenthetical qualifier and 'Read-only'. Front-loaded key info, no filler. Efficient given tool simplicity.
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 no output schema, description covers purpose, behavior, and parameter semantics. Does not specify output format, but not critical given low complexity. Differentiates from siblings adequately.
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 has 100% coverage, but description adds context: 'Balances are tracked per token, so USDC and USDT are separate pots' and notes default. This adds meaning beyond enum description.
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?
Clearly states it shows the prepaid balance for a stablecoin, with specific verb 'show' and resource 'pre-paid balance'. Distinguishes from siblings like gate_prepaid_deposit (deposit) and gate_get_price (price).
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?
Indicates read-only nature but lacks explicit when-not-to-use or alternatives. Implies usage for checking balance without signing, but no direct guidance on when to use this versus gate_fetch or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Deposit stablecoin into the Solinkify pre-paid balance so future gate_fetch calls debit it without a per-request transaction. Moves money: the full deposit counts against the daily spending cap at once, and the balance can be withdrawn later.
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | Stablecoin to deposit. Must match the token the target endpoints price in, since balances do not convert between tokens. Defaults to USDC. | USDC |
| amount_usd | Yes | Amount to deposit, in whole currency units (1.5 means $1.50, not 1500000 base units). Must be positive and within the remaining daily cap. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description covers key behaviors: moves money, affects daily cap, supports withdrawal. Adds useful context about token matching requirement. Little missing on return value or confirmation, but overall informative.
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, no filler. First sentence states purpose and action, second explains consequences. Highly efficient.
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 2 parameters, no output schema, the description covers behavior (daily cap, withdrawal, token matching). Could mention confirmation or transaction ID, but overall sufficient for typical deposit tool.
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 coverage is 100% with decent descriptions, but the description adds value beyond schema: clarifies token must match endpoint pricing and amount_usd is in whole units with daily cap constraint. This extra context earns above baseline 3.
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?
Clearly states the action 'Deposit stablecoin' into 'Solinkify pre-paid balance' and explains the purpose: to enable future gate_fetch calls to debit it without per-request fees. This distinguishes it from siblings like gate_fetch and gate_prepaid_balance.
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?
Provides context: full deposit counts against daily cap and is withdrawable, implying use for prepayment without per-request charges. Does not explicitly state when not to use, but siblings and context make alternatives clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy (or renew) a creator's subscription plan for a Gate endpoint: one payment, then unlimited access until expiry. Moves money. The plan price is read on-chain and checked against the spending caps before paying. Fails if the endpoint has no subscription plan.
| Name | Required | Description | Default |
|---|---|---|---|
| endpoint_id | Yes | Identifier the creator gave the endpoint, e.g. "premium-api". Also comes from the 402 manifest; it is not a URL. | |
| creator_wallet | Yes | The creator's Solana wallet address in base58 (the endpoint owner, not the agent's own wallet). Shown in the 402 manifest returned by gate_get_price. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure responsibility. It discloses that the tool 'moves money,' reads the plan price on-chain, checks spending caps, and fails if no plan exists. These are important behavioral traits beyond the basic action, though it could mention success response or 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 exceptionally concise at three sentences. The main action ('Buy or renew ... plan') is front-loaded, and every sentence adds essential information without redundancy.
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?
While the description covers the input and failure condition, it does not mention the return value or success behavior. Given the absence of an output schema, this gap could confuse an agent about what to expect after a successful subscription purchase.
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 coverage is 100% with decent descriptions, but the tool description adds value by clarifying that 'creator_wallet is the endpoint owner, not the agent's wallet' and that 'endpoint_id comes from the 402 manifest, not a URL.' This extra context helps an agent avoid common mistakes.
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 'Buy (or renew) a creator's subscription plan' and identifies the resource as a 'Gate endpoint with unlimited access until expiry.' It differentiates from siblings by specifying the one-payment subscription model and mentions moving money, which is unique to this tool among 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 provides clear usage context: it is for buying or renewing a subscription, and it fails if the endpoint has no subscription plan. However, it does not explicitly compare to alternatives like gate_get_price or datahub_subscribe, nor does it provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pay a pending Solinkify Pay checkout session. Settles on Solana, the merchant receives 99% instantly, and the order is marked paid. Spends from the agent wallet — or, when SOLINKIFY_OWNER_WALLET is configured, from the owner wallet under its on-chain SpendAuthority caps (ADR-008); check spend_authority_status first in that mode. Moves money and is not reversible, so confirm the amount with pay_get_session first. Sessions that are already paid or expired are refused.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Session id (uuid) or full checkout URL of a session whose status is still "pending". The amount and token are fixed by the merchant and cannot be overridden here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: settles on Solana, 99% instant transfer to merchant, spends from agent or owner wallet, irreversible, and refuses paid/expired sessions. 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?
The description is well-structured and covers all necessary points without redundancy. Slightly verbose due to technical details like ADR-008, but still efficient. Could be trimmed slightly.
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 single-parameter tool with no output schema or annotations, the description provides complete context: payment flow, wallet modes, prerequisites, and restrictions. No gaps remain.
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 coverage is 100%, and the description adds meaning: session must be 'pending', amount/token are fixed by merchant, and it accepts UUID or full URL. This enhances clarity beyond the schema's basic description.
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 verb (pay) and resource (pending Solinkify Pay checkout session). It distinguishes from sibling tools like pay_get_session and spend_authority_status by specifying 'pending' status and the settlement process.
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?
Explicit guidance: check spend_authority_status when owner wallet is used, confirm amount with pay_get_session first, and note that paid/expired sessions are refused. Clearly differentiates from read-only tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a Solinkify Pay checkout session (from a merchant store such as WooCommerce, OpenCart or PrestaShop) before paying: amount, merchant, order id, and status. Read-only, so call it first to confirm what pay_checkout would spend.
| Name | Required | Description | Default |
|---|---|---|---|
| session | Yes | Either the session id (a uuid) or the full checkout URL such as https://solinkify.com/checkout/<id>. Both forms are accepted; the id is extracted from the URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It declares 'Read-only,' which is a key behavioral trait. It does not detail auth needs or rate limits, but for a simple read-only tool, this is sufficient.
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 concise sentences with zero waste. The main purpose is front-loaded, and every word adds value.
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?
With no output schema, the description mentions return fields (amount, merchant, order id, status) but does not specify format or additional details. For a simple inspection tool, this is nearly complete, though a bit more detail on the output would push it to 5.
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 coverage is 100%, and the schema already provides a detailed description of the 'session' parameter (accepts UUID or URL, extracts ID). The description adds no extra parameter information beyond the schema, so baseline 3 is appropriate.
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 Solinkify Pay checkout session and lists key fields (amount, merchant, order id, status). It differentiates from sibling pay_checkout by noting it should be called before spending.
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 explicitly says 'call it first to confirm what pay_checkout would spend,' providing clear guidance on when to use it. It does not explicitly state when not to use it, but the context implies it's for pre-payment inspection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect a Solinkify Blink (a product shared on X as a Solana Action) before buying: title, description, price, and seller. Read-only, so use it to confirm the price before social_buy_blink.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Any form the link circulates in: a share link (https://solinkify.com/book/<id>), an Actions URL (…/api/actions/buy/<id>), or the raw product id. The id is extracted automatically. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It declares the tool is 'Read-only', which is a key behavioral trait. However, it could mention behavior on invalid URLs or other potential issues, but is sufficient for a simple inspection tool.
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, no wasted words. The most important information (purpose, usage, parameter flexibility) is front-loaded and concise.
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 the tool's simplicity (1 parameter, no output schema, no annotations), the description is fully adequate. It covers what the tool does, what data it returns, and when to use it.
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 coverage is 100%, but the description adds significant meaning beyond the schema's property description. It explains that the parameter accepts multiple formats (share link, Actions URL, raw product id) and that the id is extracted automatically, which is not in the schema.
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 uses a specific verb 'inspect' and states the resource 'Solinkify Blink', listing what information it returns (title, description, price, seller). It also distinguishes from the sibling tool social_buy_blink, making the purpose clear.
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?
Explicitly states when to use: 'confirm the price before social_buy_blink'. It also notes the tool is read-only, guiding the agent to use it before performing a purchase.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the on-chain SpendAuthority (ADR-008) that lets this agent pay merchants from an owner's wallet: per-payment cap, daily ceiling, what is spent/left today, and whether it has been revoked. All of it is enforced by the Solana program, not by this server. Read-only. Defaults to the SOLINKIFY_OWNER_WALLET the server is configured with.
| Name | Required | Description | Default |
|---|---|---|---|
| owner | No | Base58 wallet address of the funds owner to inspect. Omit to use the configured SOLINKIFY_OWNER_WALLET. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It declares read-only behavior, that enforcement happens on-chain, and that it defaults to a configured wallet. It does not contradict any annotations (none provided) and adds useful context about trust boundaries, though it lacks detail on error conditions or authentication requirements.
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 concise sentences cover the purpose, output fields, read-only nature, enforcement, and default wallet. Every sentence adds value with no redundancy or filler.
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 optional parameter and no output schema, the description is largely complete: it specifies what data is returned (cap, ceiling, spent/left, revoked), the read-only behavior, and default wallet. It could be improved by mentioning error cases (e.g., if authority doesn't exist) but is still solid.
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 coverage is 100% with one optional parameter 'owner'. The description adds value by explicitly stating to omit it to use the configured wallet, which goes beyond the schema's basic description.
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 shows the on-chain SpendAuthority (ADR-008), listing specific details like per-payment cap, daily ceiling, usage, and revocation status. It uses a specific verb ('Show') and resource, distinguishing it from sibling tools that deal with payments, subscriptions, or data purchases.
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 explains it is read-only and defaults to the configured SOLINKIFY_OWNER_WALLET, providing clear context for when to use it. However, it does not explicitly state when not to use it or mention alternatives, though no sibling tool duplicates this functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show the agent wallet: address, SOL for fees, stablecoin balances, Solinkify pre-paid balance, and today's remaining spending budget under the caps. Takes no arguments and never moves money. Call it first when a payment fails, to tell an empty wallet apart from a cap that has been reached.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 clearly states that the tool 'takes no arguments and never moves money,' which are key traits. However, it does not mention possible error conditions or output format, but given the simplicity and read-only nature, the description is sufficiently transparent.
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: two sentences. The first sentence lists what the tool provides, and the second gives usage guidance. No unnecessary words, and the key information is front-loaded. It 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?
Given the tool has no parameters, no annotations, and no output schema, the description must be self-sufficient. It fully enumerates what information is returned: address, SOL, stablecoin balances, pre-paid balance, and spending budget. This is complete for a status-check tool.
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 input schema has no parameters, so schema_description_coverage is 100%. The description reinforces that there are no arguments, adding no further parameter detail needed. Baseline 4 is appropriate as the schema already handles it.
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 what the tool does: it shows the agent wallet details including address, SOL balance, stablecoin balances, pre-paid balance, and remaining budget. It uses specific verbs ('Show') and resource identifiers, and the detail distinguishes it from sibling tools that handle payments or subscriptions.
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 explicitly states when to use the tool: 'Call it first when a payment fails, to tell an empty wallet apart from a cap that has been reached.' This provides clear context and a concrete use case, which helps the agent decide when to invoke it over alternatives.
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. Dates show when Glama detected each change.
v0.3.3datahub_searchgate_check_deliverygate_find_endpointssocial_get_blinkv0.3.0datahub_buydatahub_downloaddatahub_reviewdatahub_subscribegate_fetchgate_get_pricegate_prepaid_balancegate_prepaid_depositgate_subscribepay_checkoutpay_get_sessionsocial_buy_blinkspend_authority_statuswallet_statusEach tool targets a distinct operation within its domain (wallet, gate, datahub, pay, social). No two tools have overlapping purposes; even similar actions like fetching vs. buying are clearly separated by context.
All tools follow a consistent pattern: domain prefix (gate_, datahub_, pay_, social_) followed by verb_noun. This makes the toolset predictable and easy to navigate.
18 tools cover multiple subdomains (wallet, gate, datahub, pay, social) without being overwhelming. Each tool serves a clear purpose, and the count is well-scoped for the server's comprehensive payment/access functionality.
Core workflows (discover, price check, pay, fetch, verify, and manage prepaid/subscriptions) are well-covered. Minor gaps exist, such as lacking a tool to cancel subscriptions or list owned purchases, but these do not severely impede typical agent tasks.
x402 paid API tools for AI agents on Solana: crypto safety, market data, KYB/AML verification.
162 AI agents for Solana crypto intelligence, wallets, and x402 micropayments.
54 AI agent tools: OSINT, intel feeds, DeFi, crypto, weather, DNS, proxies. x402 micropayments.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Zenidp/solinkify-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
social_buy_blinkA
Buy a product from a Solinkify Blink link as shared on X. Moves money: settles on Solana through the same escrow rails as DataHub and returns the receipt plus the download link. The price is read from the catalog and checked against the spending caps first.
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: moves money, settlement on Solana, returns receipt and download link, checks price against spending caps. Since no annotations are present, the description fully carries the burden and does so thoroughly.
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 (two sentences plus a short third) with no wasted words. Front-loaded with the core purpose, then adds behavioral details efficiently.
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?
Covers purpose, behavior, parameters, and return values well given no output schema. Minor gap: no mention of failure scenarios (e.g., insufficient funds, invalid link), but overall sufficient for a mutation tool.
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?
Adds significant meaning beyond schema: explains that the 'url' parameter accepts share links, actions URLs, or raw product IDs in the same form as social_get_blink; explains the 'email' parameter as optional for receipt, with anonymous purchase support and that the download link is returned regardless.
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?
Description clearly states the action ('Buy') and the specific resource ('product from a Solinkify Blink link as shared on X'). The verb is specific and the resource is well-defined, distinguishing it from sibling tools like datahub_buy which likely handle different types of purchases.
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 over alternatives. The context 'as shared on X' implies it's for purchases initiated from social media Blinks, but no exclusion criteria or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.