io.github.nevermined-io/catalog

Nevermined Catalog

Discover and pay for services from the Nevermined Catalog using a spend-capped budget.

1.65.0
Version
remote
Transport
12
Tools

Security review

Partly reviewed

Reviewed 27m ago.

  • tools: 12 tools scanned
  • metadata: scanned
  • mediumReviewRemote tools take credentials as input

    Whatever an agent passes to a remote tool leaves the machine. Never send connection strings, tokens or passwords to a third-party MCP server unless it is the service those credentials belong to.

    pay_service, quote_service, route_by_intent

Tools (12)

  • list_categories

    List the categories of paid services in the Nevermined Agent Services Catalog, with a count per category. Discovery only; no payment.

  • search_services

    Search the Nevermined Agent Services Catalog for paid services, ranked by ARD HYBRID relevance — semantic (meaning) matches merged with lexical (keyword) matches, most relevant first — falling back to pure lexical when the embedding provider is unavailable. Each result includes a closed matchReason, a per-item rankingSource, and one scale-specific score. A query is required; the other filters are optional. Returns matching listings (vendor, protocol, price label, endpoint). Only the first page is returned: the `pageToken` in the result cannot be passed back to this tool, so to see other matches narrow the query or filters, or raise `pageSize` (up to 100). Discovery only; no payment. To have the platform PICK (and optionally pay) the single best service for a need instead of choosing yourself, use route_by_intent.

  • get_service

    Fetch one catalog service by slug with metadata and a `requestShape` block. Read the endpoint's `payServiceArgs` before `pay_service`, replacing every `pathParams` placeholder. A checked invoke contract may include `invokePath`, `requestExample`, merchant-authored `responseSchema`/`responseExample`, and `exampleEvidence`: `paid-run` records a paid response, `challenge` proves only the request shape, and `docs` is unverified provider documentation. Only `paid-run` and `challenge` examples are pre-filled into `payServiceArgs`; adopt a `docs` example deliberately. Merchant response shapes are sanitised, and harvested examples are published only when they validate against their schema. An `endpointCheck` records a dated unpaid failure. A `requestSchema` is the merchant-declared JSON Schema of its request and is sanitised, not verified. A quote excludes the Router fee, which the budget must also cover. An unknown slug returns an error. Discovery only; no payment. Call `quote_service` for th

  • pay_service

    Pay for a catalog service from your spend-capped delegation and return the vendor response. This charges real funds. Call `get_service` FIRST: its `requestShape.endpoints[]` lists the callable paths with their HTTP method and price, and each `payServiceArgs` is the `slug`/`path`/`method` to pass here, after replacing any `pathParams` placeholder in `path` with a real value. A bare slug reaches the service base URL, which for a multi-endpoint API answers 404 instead of a payment challenge; only a single-endpoint service is called by slug alone. Send the endpoint's `payServiceArgs`: they carry an example only when it is `paid-run` or `challenge`. A `docs` example (and its `invokePath`) is unverified — use it only deliberately, filling any path parameter with the entity you want; otherwise build `body` from the endpoint description or the provider's docs. `method` may be omitted: it is taken from the catalog endpoint matching `path` (POST when the catalog names none) and echoed back under

  • quote_service

    Price ONE call to a catalog service WITHOUT paying it: it charges nothing, signs nothing and reserves no budget. Pass exactly what you would pass to `pay_service` (the same `slug`, `path`, `method`, `search`, `headers`, `body` and `delegationId`): the Router sends that request to the service unpaid, reads the price it asks for, and returns an opaque `quoteId`, its short `expiresAt`, the rail (`protocol`), the network and merchant amount (`settlement`) and the fee-inclusive total (`fee.capChargedCents`, whole cents rounded up; `fee.capChargedMicros` exact, in 1/10,000 of a cent). Unlike the `quote` on a get_service endpoint (the last merchant price the catalog observed, routing fee excluded), this is priced live for your exact request and includes the fee. Because the request really reaches the service, a service that does not charge for it performs it, so take care quoting a method with side effects; and a quote spends the same per-service rate limit as a payment, so quote once per dec

  • route_by_intent

    Given a plain-language description of what you need, find, and optionally pay in the same call, the single best payable catalog service, so you do not have to pick among listings yourself. Use it instead of search_services when you want the right service for a task rather than a list to browse: it ranks candidates on Nevermined's own relevance and quality signals (deterministic; no model reads the merchant listings), applies a fail-closed payability gate (listed, healthy, moderated, x402/mpp, not flagged unpayable), and returns the winner as `chosen` (with its opaque invoke handle, never a raw host) plus a ranked `shortlist`; every shortlist item carries a closed `matchReason`, `gateReason`, per-item `rankingSource`, and one scale-specific score. With `autoPay:false` (the default) it returns the pick only and charges nothing; the next step is normally `get_service` on `chosen.slug`, then `pay_service` with the endpoint you need. With `autoPay:true` it also pays the winner through the s

  • setup_delegation

    Start the spending-delegation ceremony and return ONE URL for a human to open. Use this when `pay_service` returns `{"error":"no_delegation"}` — it is the way out of that state. It sets up a stablecoin (crypto) delegation that spends from the human's personal wallet, so that wallet also needs funds on the network a service settles on (see `wallet_balance`); it does not enroll a card or create a card delegation. The human sets the currency, spending cap, duration and transaction limit themselves in the browser; you CANNOT set them and must not ask the human to pass them to you. Returns `{"status":"human_action_required","url":…}` — relay the url, wait for the human to confirm, then simply call `pay_service` again. `{"status":"already_active"}` means a usable spending budget is in place — for an OAuth commerce caller it is the grant approved on the consent screen — and nobody needs to do anything: tell the human `message` as it stands (it states the cap, spent, remaining and expiry the A

  • get_budget

    Read the spending budget pay_service spends from: its cap, what has been spent, what remains, how many payments were made (and the limit, if any), and when it expires. Reading costs nothing and charges nothing. Use it whenever the human asks how much is left, or before a run of paid calls. Money is in CENTS: `capCents` is whole cents; `spentCents` and `remainingCents` can carry up to four decimals because the budget is charged per call at 1/10,000 of a cent (e.g. `"1.632"` = 1.632¢), and `spentCents + remainingCents = capCents` while the budget is within its cap. Tell the human `message` as it stands and never substitute a figure of your own: the budget includes routing fees and rounding, so adding up your calls will not match it. With no `delegationId` it reads the budget pay_service would use; that only includes budgets that can still pay, so `{"status":"no_active_delegation"}` also covers a budget that ran out or expired — pass the `delegationId` from an earlier pay_service result t

  • get_payment_result

    Read the result of a paid call, by its `paymentId`. Use it when `pay_service` answered `{"status":"pending"}` (the service was still working when the Router stopped waiting — the payment is made and the call keeps running), or to recover a result whose response you lost. Reading costs nothing and charges nothing. `state: "Pending"` — still running, call again in a few seconds. `state: "Ready"` — `status` is the service's HTTP status and `body` its response (`bodyEncoding` says whether it is parsed JSON, text, or base64). `state: "Failed"` — the call ended without a response; `failureReason` says why. `{"status":"not_available"}` — nothing to return: results are kept for 24 hours for the account that paid, and only then. Do NOT call pay_service again to get a pending result: that returns the same pending answer. Requires your Nevermined API key on the Authorization header.

  • list_payments

    List your Router payments: the unified ledger across every service and delegation, newest first, at most 1000 records. Each record carries its `id` (the `paymentId` get_payment_result takes), `createdAt`, `status`, `protocol`, `network`, `requestId`, `delegationId` and `amount` in the asset's smallest unit (see `assetDecimals`), not in cents. Each row also carries `deliveryStatus`: `delivered` (request settled), `charged_not_delivered` (request failed and the merchant charge was observed), `charged_unconfirmed` (charge observed; delivery unconfirmed), `not_charged` (reconciliation proved no merchant charge), or `pending` (charge outcome unknown). On SPT and card rails, `pending` is not proof of no charge; flag `charged_not_delivered` to the user. Use this tool to reconcile an uncertain payment or find a paymentId; it does not return service responses (use get_payment_result) or the remaining budget (use get_budget, whose figures include fees and rounding). Reading costs nothing. Requir

  • payment_summary

    Count your Router payment requests: `total` is how many there were in the period (uncapped, unlike list_payments) and `series` is that count per day (`date`, `value`), oldest first. `chargedNotDelivered` is the count of failed payments in the period whose merchant charge was observed; flag a non-zero count to the user. This reports numbers of payments, not money: for what has been spent or what is left use get_budget, and for amounts per payment use list_payments. Reading costs nothing. Requires your Nevermined API key on the Authorization header.

  • wallet_balance

    Read the balances of YOUR OWN PERSONAL wallet — the funding source the crypto rails PULL from when pay_service charges a PERSONAL delegation. It answers `how much do I have, and on which chain`. Reading costs nothing and charges nothing. WHAT IT DOES NOT COVER, so you do not mis-diagnose: a delegation backed by an ORGANIZATION wallet is paid from that wallet, not this one; and a CARD delegation has no wallet at all — there `BCK.ROUTER.0009` is the card ISSUER declining, with nothing to top up, so this tool does not apply and the answer is a different card. BY RAIL: on MPP the wallet is checked BEFORE anything is signed, and the `BCK.ROUTER.0009` you get back already names the wallet and the chain — what it never says is HOW MUCH is there, which is what this tool supplies. On x402 there is NO balance pre-check and `BCK.ROUTER.0009` is never raised: the credential is minted, budget is reserved, and a short wallet only surfaces when the merchant's on-chain transfer fails — by which point