Skip to main content
Glama
Sign In

Nevermined Catalog

by io.github.nevermined-io
OverviewDiscussionsAdmin

Payment summary

payment_summary
Read-only

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 reconciliation observed on-chain (a failed payment not yet reconciled is not counted); this is the confirmed failed-and-charged count only. countsByDeliveryStatus exposes all six ledger delivery states, including charged_unconfirmed, not_delivered and pending, with zero counts included. The latter two have unknown charge outcomes: do not count them as confirmed charges. Flag both charged buckets and explain unresolved outcomes to the user. These buckets include calls paid with your Nevermined credits, so check fundingSource and creditsStatus in list_payments before telling the user they were charged. This reports numbers of payments, not money: for what has been spent or what is left, and how much of it was charged without delivery, use get_budget, and for amounts per payment use list_payments. Reading costs nothing. Requires your Nevermined API key on the Authorization header.

Input Schema

NameRequiredDescriptionDefault
toNoISO-8601 upper bound on `createdAt`, inclusive. An unparseable value is an error.
fromNoISO-8601 lower bound on `createdAt`, inclusive. An unparseable value is an error.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / additionalProperties
      Removed value: -false
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare `readOnlyHint`; the description adds that reads are free, a Nevermined API key on the Authorization header is required, `series` is oldest-first, zero counts are included, and `charged_unconfirmed`/`not_delivered`/`pending` are unresolved charge outcomes not to be counted as confirmed. It also discloses credit-funded calls and directs verification in `list_payments`.

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 key caveats are front-loaded, and nearly every sentence carries operational meaning. The dense prose block contains several nuanced warnings that could be more scannable, but there is little outright waste.

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?

There is no output schema, but the description explains every reported field, what is included/excluded in counts, and the required auth/cost context. It also covers ambiguous delivery-status buckets and sibling alternatives, so an agent has enough to call and interpret the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already documents `to`/`from` as inclusive ISO-8601 bounds with parse errors. The description only refers to 'the period' and adds no further constraint or format meaning for these parameters, so the baseline 3 applies.

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 ('Count') and resource ('Router payment requests') and enumerates the returned fields (`total`, `series`, `chargedNotDelivered`, `countsByDeliveryStatus`). It explicitly distinguishes itself from `list_payments` (uncapped vs capped) and `get_budget` (numbers vs money), so an agent can select it 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 money questions to `get_budget` and per-payment amounts to `list_payments`, and warns to check `fundingSource`/`creditsStatus` in `list_payments` before telling the user they were charged. This supplies clear when-to-use and when-not-to-use conditions tied to sibling tools.

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

All Nevermined Catalog toolsInspect
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