Skip to main content
Glama

agent-transaction-control

by network.flint
OverviewDiscussionsAdmin

FLINT Scout Credits: Topup

scout_credits_topup
Destructive

Call once with session_token to get a pay_url; pay it with awal (awal x402 pay -X POST -d '{}' <pay_url>) or any x402 client; no headers needed on the pay request. Or pass payment_signature to settle through this tool. One $1.00 x402 payment buys 100 FLINT Scout scan credits, matching today's $0.01 x402 price without signing a payment for every run_flint_scout call. Requires session_token from auth_verify_otp so the credits land on that account; call auth_request_otp then auth_verify_otp first if you do not have one. With no topup_id, the first call creates a fresh top-up intent (an sct_ id good for 24 hours) and returns its pay_url alongside the same $1.00 x402 challenge. Pass topup_id to retry paying or settling that same intent instead of creating a new one. Once credited, call run_flint_scout with the same session_token and no payment_signature to draw one credit per scan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topup_idNoOptional existing top-up intent id from a prior call, to retry paying or settling it instead of creating a new one. Intents expire 24 hours after creation.
session_tokenYesAgent session token from auth_verify_otp. Credits are added to this account.
payment_signatureNoOpaque caller-signed x402 PAYMENT-SIGNATURE value from a wallet-enabled client. Never provide a private key or seed phrase.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / topup_id
      Added value: +{
+  "description": "Optional existing top-up intent id from a prior call, to retry paying or settling it instead of creating a new one. Intents expire 24 hours after creation.",
+  "pattern": "^sct_[0-9A-Za-z]{20,32}$",
+  "type": "string"
+}
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations supply the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=true), and the description adds substantial context beyond them: 24-hour intent expiry, $1.00=100 credits pricing, account binding via session_token, and two distinct payment paths. The one gap is that destructiveHint/idempotency implications (e.g. what happens on a failed or repeated payment) are not addressed.

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?

Front-loaded with the core action and dense with useful workflow detail, though it is comparatively long with several semicolon-joined clauses and an inline command. Every sentence conveys actionable information, so little is wasted despite the length.

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 mutation tool with no output schema, three params, and open-world payment behavior, the description covers prerequisites, both settlement paths, intent lifecycle, credit economics, and the follow-up call. An agent has everything needed to invoke it correctly.

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. However, the description adds genuine semantics beyond the schema: it explains that omitting topup_id creates a fresh sct_ intent returning a pay_url, while passing topup_id retries that same intent rather than creating a new one, and it ties session_token to the credited account.

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+resource (top up FLINT Scout scan credits) and immediately distinguishes itself from siblings by naming run_flint_scout and scout_credits_balance workflows. An agent can tell exactly what this tool does and how it fits with adjacent tools.

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 covers when to call (once, with session_token), the alternatives (pay the returned pay_url via awal/any x402 client vs. settle in-tool with payment_signature), prerequisites (auth_request_otp then auth_verify_otp), and the retry path via topup_id. It even states the downstream call (run_flint_scout with no payment_signature).

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

All agent-transaction-control 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