Skip to main content
Glama

GrowVib: Social Media Growth

place_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
NameRequiredDescriptionDefault
linkYesThe target link the order is delivered to.
paymentNoThe signed x402 v2 payment payload. Omit on the first call to receive the payment requirements.
quantityYesQuantity to order.
service_idYesThe service id from search_catalog.
agent_tokenNoThe 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_keyNoA 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_idNoOptional specific service option id; defaults to the service's primary option.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

With annotations already marking this as non-read-only, destructive, and idempotent, the description adds valuable behavior: the two-call x402 flow, network-specific signing, balance carryover, and the explicit retry/duplicate-payment warning. This is exactly the operational detail an agent needs.

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 description is dense and purposeful, front-loading the two-call protocol and key warnings. It is somewhat long, but every sentence carries operational value; the final get_quote mention is a useful brief alternative pointer.

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?

Covers the multi-step protocol, network-specific signing, overpayment behavior, retry safety, and when to use a sibling tool. With rich annotations and complete schema coverage, nothing essential is missing for a correct call.

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 covers 100% of parameters with descriptions, so the baseline is 3. The description adds critical integration semantics: how and when to pass `payment`, how `agent_token` substitutes for it, and how `idempotency_key` prevents duplicate orders. This lifts the score above baseline.

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 description clearly identifies the verb (place/pay), resource (orders via x402), and exact scope (USDC on Base/Solana, no account required). It also distinguishes itself from get_quote by explicitly saying to call get_quote if the user only wants a price, which separates it from the sibling tools.

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?

Provides explicit step-by-step usage: call once without payment to get requirements, then call again with the signed payment payload. It also gives exclusions and alternatives ('Use get_quote first if you only want a price') and warns against sending duplicate payments while confirmation is pending.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources