AIMarket — live agent marketplace

market_invoke

Invoke a capability found via market_search. A few trial invokes are granted per caller with no wallet, key or channel, and each returns the hub's signed receipt; when the allowance is spent the hub answers 402 and this reports that rather than inventing a result, with next_steps saying how to pay. Paid access uses payment_channel (+ secret) or an on-chain x402 payment (x_payment + x_payment_nonce).

Input Schema

TableJSON Schema

Name	Required	Description
`input`	No	Input object for the capability; {} when it takes none.
`x_payment`	No	x402 seller-direct payment: the hash of the USDC transfer you broadcast for the 402's invoice (see next_steps).
`product_id`	Yes	The product_id from market_search.
`source_hub`	No	The source_hub from market_search, when it shows one. Required for federated capabilities — most of the catalogue; omitting it makes the hub look for the capability locally and answer 404.
`capability_id`	Yes	The exact capability_id from market_search.
`max_price_usd`	No	Atomic total-price ceiling. Copy the selected search result's max_price_usd here; the Hub returns price_limit_exceeded before work or payment if the route was repriced.
`payment_channel`	No
`x_payment_nonce`	No	The invoice nonce from the 402 that x_payment pays.
`include_full_receipt`	No	Return the hub's raw response, including the full hybrid Ed25519 + ML-DSA-65 receipt signature (about 7 KB).
`payment_authorization`	No
`payment_channel_secret`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 25, 2026

addedInput schema / properties / include_full_receipt

Added value: +{
+  "description": "Return the hub's raw response, including the full hybrid Ed25519 + ML-DSA-65 receipt signature (about 7 KB).",
+  "type": "boolean"
+}

changedInput schema / properties / max_price_usd / description

Previous value: -"Atomic total-price ceiling. Copy the selected search result's price here; the Hub returns price_limit_exceeded before work or payment if the route was repriced."New value: +"Atomic total-price ceiling. Copy the selected search result's max_price_usd here; the Hub returns price_limit_exceeded before work or payment if the route was repriced."

addedInput schema / properties / x_payment

Added value: +{
+  "description": "x402 seller-direct payment: the hash of the USDC transfer you broadcast for the 402's invoice (see next_steps).",
+  "type": "string"
+}

addedInput schema / properties / x_payment_nonce

Added value: +{
+  "description": "The invoice nonce from the 402 that x_payment pays.",
+  "type": "string"
+}

Changed1 schema field changedSep 10, 2026

addedInput schema / properties / max_price_usd

Added value: +{
+  "description": "Atomic total-price ceiling. Copy the selected search result's price here; the Hub returns price_limit_exceeded before work or payment if the route was repriced.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "number"
+}

First observedAug 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and handles it well. It discloses trial allowances, signed receipts, the 402 fallback, the refusal to invent results, next_steps guidance, and the two payment mechanisms. This gives an agent a realistic model of tool behavior beyond a simple 'invoke' label.

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

Conciseness5/5

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

The description is dense but organized, front-loading the core purpose and then explaining the trial path, failure behavior, and paid alternatives. Every sentence contributes critical information, and there is no filler or repetition of schema field names beyond what is necessary for payment flow clarity.

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

Completeness4/5

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

For a complex tool with 11 parameters, no output schema, and no annotations, the description covers the main workflow, failure mode, and payment options well. It still leaves payment_authorization opaque and does not describe the shape of a successful response beyond mentioning a signed receipt, which prevents a perfect score.

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?

The description adds meaning to several schema-underspecified parameters by grouping payment_channel with its secret and pairing x_payment with x_payment_nonce. It also clarifies the trial/no-payment mode and the federated source_hub requirement. However, payment_authorization remains entirely unexplained in both schema and description, and the description does not map every parameter explicitly.

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 opens with 'Invoke a capability found via market_search', which states a specific verb and resource and explicitly ties this tool to its search sibling. It clearly differentiates market_invoke from market_search and the other environment tools by focusing on the invocation/payment act rather than data retrieval.

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

Usage Guidelines4/5

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

The description clearly positions the tool as the follow-up to market_search by requiring product_id/capability_id/source_hub from search results. It also explains when trial invokes apply versus paid access, and contrasts the two payment paths. It does not explicitly state 'use market_search first' as a directive, but the dependency is strongly implied.

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

All AIMarket — live agent marketplace 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.

market_invoke

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources