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.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "service_id": "<service_id>",
      "quantity": "<quantity>",
      "link": "<link>"
    },
    "name": "create_paid_order"
  }
}

Input Schema

Name	Required	Description
`link`	Yes	The target link the order is delivered to.
`posts`	No	Only for a subscription option on an auto-delivery service (get_quote tells you when one is needed): how many of the target's future posts to cover. The quantity is then the amount per post and the price is posts times that amount. Omit for every ordinary option.
`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.

Changed1 schema field changedNov 7, 2026

addedInput schema / properties / posts

Added value: +{
+  "description": "Only for a subscription option on an auto-delivery service (get_quote tells you when one is needed): how many of the target's future posts to cover. The quantity is then the amount per post and the price is posts times that amount. Omit for every ordinary option.",
+  "type": "number"
+}

AddedOct 27, 2026
RemovedOct 27, 2026
AddedSep 13, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag this as destructive, open-world, and idempotent, but the description adds real behavioral context the annotations cannot convey: the first call returns payment requirements rather than an order, overpayment is retained as spendable balance, and the confirmation-pending warning prevents duplicate payments. The description does not contradict any annotation.

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

Conciseness4/5

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

The workflow is front-loaded: purpose, first call, signing, second call, then caveats. It is dense but nearly every sentence carries operative information; the only mild cost is length, which makes it harder to scan on a quick pass.

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?

For a multi-step payment tool with no output schema, the description covers what the first call returns (accepts entries with amount, asset, recipient, network, feePayer), how to complete payment, retry/idempotency safety, and overpayment handling. An agent has everything needed to invoke it correctly.

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 schema already carries per-parameter documentation; the description still adds meaning by explaining the sequencing of `payment` across two calls and the balance-based alternative path via `agent_token` + `idempotency_key`. It does not add syntax detail beyond the schema, so it stays below a 5.

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

Purpose5/5

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

The opening sentence names a specific verb (place an order), the payment asset and chains (USDC on Base or Solana), the payment protocol (x402), and the no-account/no-human-in-the-loop scope. That is enough to distinguish it from siblings like create_checkout and get_quote without opening any schema.

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?

It gives an explicit two-step protocol (call FIRST without `payment`, then call AGAIN with the signed payload), tells the caller which network to pick and how to sign for each, and routes price-only callers to `get_quote`. It even names a failure case to avoid: do not re-sign when a payment is still being confirmed.

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?