Skip to main content
Glama
Sign In
aimarket-mcp

aimarket-mcp

by alexar76
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

market_invoke

Runs a capability found with market_search, returning its result and a hub-signed receipt nonce so the output can be verified; pass only IDs returned by search.

Instructions

Run one capability found with market_search and return its result plus the nonce of the hub-signed receipt, so the result can be checked against the hub's public key. Use only capability_id/product_id/source_hub values market_search returned. Payment: a few free trial invokes per installation (see market_status for what is left), then the prepaid balance of AIMARKET_API_KEY (a key from the hub's /start page, topped up with USDC); listings sold only on chain need x402. When nothing can pay, it says what the call costs and how to pay instead of inventing a result. Side effects are the capability's own: most listings are read-only lookups, but some act (e.g. set a timer that calls back a URL) — read the market_search name first and ask the user before a priced or acting call. To check an answer, use metis_verify instead.

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": {
      "capability_id": "<capability_id>"
    },
    "name": "market_invoke"
  }
}

Input Schema

NameRequiredDescriptionDefault
inputNoThe capability's own input, as its listing describes it, e.g. {"city": "Paris"} for weather or {"vat": "NL004495445B01"} for a VAT check; omit or {} when it takes none.
product_idNoThe product_id from market_search, e.g. 'prod-skopos'. Inferred from the capability_id prefix when empty, which is often wrong — pass it.
source_hubNoThe source_hub from market_search, when it showed one. Required for federated capabilities — most of the catalogue; without it the hub looks for the capability locally and answers 404.
capability_idYesExact capability_id from market_search, e.g. 'skopos.fleet.status@v1'.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.6.4

TDQS

A4.6/5.0
Behavior4/5

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

Goes well beyond the annotations by disclosing the payment ladder (free trials, prepaid AIMARKET_API_KEY balance, x402 for on-chain listings), the failure behavior ('says what the call costs... instead of inventing a result'), and that side effects vary by capability. The annotations flag openWorldHint and non-idempotency, and the description earns credit by warning that some listings act, e.g. setting a timer that calls back a URL.

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 purpose and the source-of-identifiers rule are front-loaded, then payment, then side effects, then the cross-reference. Dense semicolon-chained sentences pack a lot in, but nearly every clause carries operational information; only the payment detail is slightly over-weighted.

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 an open-world, payable, non-idempotent invocation tool this is complete: identifier sourcing, cost and payment paths, trial exhaustion, no-payment fallback, side-effect variability, user-consent rule, and a receipt for verification. An output schema exists, so return-value detail is not needed.

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 adds a real constraint beyond the schema: the three identifier values must be the ones market_search returned. It reinforces the product_id inference pitfall and the 404 risk from an omitted source_hub, adding validation meaning rather than repeating field docs.

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 and resource — 'Run one capability found with market_search and return its result plus the nonce of the hub-signed receipt' — and distinguishes itself from market_search (discovery) and metis_verify (checking answers). An agent can tell exactly what this does without opening the 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?

Explicitly routes the agent: obtain capability_id/product_id/source_hub from market_search, check remaining trials via market_status, use metis_verify to check an answer, and ask the user before a priced or acting call. Multiple named alternatives and conditions are given, not implied.

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

Deploy Server

Other Tools