Skip to main content
Glama

pronto-stream

by io.github.nmxmxh

settle_payment

Idempotent

Redeem a payment you have made and activate your plan. Step two of two, after open_payment and the transfer.

The payment is verified by reading Base: the transfer must have reached the settlement address, from the wallet this purchase was opened with, for at least the amount owed, and be five blocks deep. A payment that is real but not yet deep enough returns a pending error naming that — the money has moved, so call this again with the same hash rather than paying twice. One transaction settles one subscription.

On success your existing API key resolves to the new plan with nothing to change on your side: you become your own principal, and no person holds the subscription.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
transaction_hashYesThe Base transaction hash of your USDC transfer: 0x followed by 64 hex characters.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations, the description reveals concrete verification behavior: reading Base, checking the settlement address, wallet origin, amount, and block depth. It also explains the pending-error scenario and the idempotent reuse of the same hash, plus the success effect on the API key.

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 well structured and appropriately sized: a clear opening, a detailed verification/error paragraph, and a concise success outcome. Every sentence adds functional value without filler.

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 a single-parameter tool with no output schema, the description covers the full invocation context: prerequisites, verification rules, retry behavior, and post-success state. An agent has enough information to call the tool correctly and interpret outcomes.

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?

The input schema already fully documents transaction_hash with format details. The description adds the guidance to reuse the same hash on retry, but it does not need to explain the parameter further because schema coverage is 100%.

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 states a specific action: redeem a payment and activate your plan, and identifies its role as 'step two of two' after open_payment and the transfer. This clearly distinguishes it from the related open_payment sibling.

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?

The description explicitly frames when to call the tool: after open_payment and the transfer. It also instructs what to do if the payment is real but not deep enough: call again with the same hash rather than paying twice. This is strong practical usage guidance.

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

All pronto-stream toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.7/5.0
Disambiguation5/5

Each tool targets a distinct operation: the two facet-listing tools are explicitly differentiated as quick manifest vs exhaustive listing, and search_signals vs scope_signals is cleanly split between lexical search and facet filtering. The billing/payment tools also form a clear lifecycle with no overlapping responsibilities.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern: get_* and list_* for reads, and action verbs like register_agent, open_payment, settle_payment, scope_signals, search_signals for operations. No mixed casing or inconsistent verb styles.

Tool Count5/5

15 tools is at the upper edge of the well-scoped range but each tool earns its place: five cover data retrieval, four cover discovery/metadata, and five cover identity/billing. No redundant or filler tools.

Completeness5/5

The surface covers the full workflow for the stated domain: discover vocabulary, search/scope the live wire, retrieve individual signals and related signals, compute fused products, register an identity, and purchase/activate a plan. The only apparent omissions, such as cancellation, are outside the described prepaid self-service flow.

Resources