GrowVib - Social Media Growth

create_paid_order

DestructiveIdempotent

Place an order and pay for it with USDC on Base or Solana, with no GrowVib account and no human in the loop, using the x402 payment protocol. Call it FIRST without the payment argument: it returns the exact payment requirements, one accepts entry per network (amount in atomic units, asset, recipient, network, and for Solana the facilitator's feePayer). Pick the network your wallet is on: sign an EIP-3009 transferWithAuthorization (Base) or build and sign the USDC transfer transaction (Solana) for exactly those requirements, then call it AGAIN with the same arguments plus payment set to the signed x402 payment payload. Anything paid above the order's price stays as spendable balance on the wallet's account, so many small orders can be paid for with one settlement. If a call reports that the payment is still being confirmed, do NOT sign and send a new payment: the first one may already have gone through. Use get_quote first if you only want a price.

Input Schema

TableJSON Schema

Name	Required	Description
`link`	Yes	The target link the order is delivered to.
`payment`	No	The signed x402 v2 payment payload. Omit on the first call to receive the payment requirements.
`quantity`	Yes	Quantity to order.
`service_id`	Yes	The service id from search_catalog.
`agent_token`	No	The agent_token from a previous order's result. Send it INSTEAD of `payment` to pay out of the balance you already hold, with no new signature and nothing on chain. Requires `idempotency_key`. If your balance does not cover the order you get the payment requirements back as usual.
`idempotency_key`	No	A value unique to this order attempt (a UUID is fine), required when using `agent_token`. Sending the same key again returns the SAME order instead of buying a second time, so a retry after a timeout is safe.
`service_option_id`	No	Optional specific service option id; defaults to the service's primary option.

Schema Changelog

Changes observed during successful MCP inspections.

AddedSep 13, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Adds rich behavior beyond annotations: two-phase protocol flow, overpayment retained as spendable balance, idempotency via idempotency_key/agent_token instead of new signatures, and the retry-safety warning about pending confirmations. Annotations cover the safety flags; the description supplies the operational protocol context they cannot.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the two-phase instruction and network selection before edge cases, and every sentence earns its place. It is dense but justified for a multi-step protocol tool; slightly verbose for a single paragraph.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A 7-param destructive, open-world mutation tool with no output schema is fully covered: purpose, phased calling, network/asset handling, balance/idempotency, and retry semantics. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description meaningfully explains the unusual semantics: `payment` is a signed x402 payload omitted on the first call, and the `agent_token`/`idempotency_key` pairing for balance payment. It adds protocol-level meaning the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('place an order and pay for it') with the exact payment rails (USDC on Base/Solana via x402) and the differentiating constraint (no account, no human). It explicitly routes to sibling get_quote for price-only use, distinguishing it from alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('Use get_quote first if you only want a price'), the exact two-phase call sequence (first without payment, then with), how to select a network, and a critical anti-pattern ('do NOT sign and send a new payment'). Alternatives and exclusions are both named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All GrowVib - Social Media Growth tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?