ZEAM Prism MCP

buy_time

buy_time

Buys one block of time on your line. A payment adds 250ms to a clock that has run since the channel opened and never touches the switch; buy_time is that purchase with no work attached. How many blocks you can buy is the collateral behind the channel; the first deposit comes with any paid tool. Returns the block bought, the time left on the line and the collateral behind it. When the balance runs out the line is cut, nothing more is charged, and time bought and not burned comes back on refund. Paid and settled on chain; not idempotent, each call buys another block. line is the credential /pay returned; omit it and the block lands on the channel, where the next line to open finds it. Not needed when a call carries its own payment. Example: {"line":"<the credential /pay returned>"}

Input Schema

TableJSON Schema

Name	Required	Description	Default
`line`	No	the credential from /pay, so this payment is applied to your line

Output Schema

TableJSON Schema

Name	Required	Description	Default
`hint`	No
`line`	No
`open`	No
`paid`	No
`tick`	No
`buysMs`	No
`boughtMs`	No
`metering`	No
`collateral`	No
`msRemaining`	No
`paidMicroUSD`	No
`thisCallMicroUSD`	No
`settledBeforeMicroUSD`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 18, 2026

removedOutput schema / properties / cumulativeMicroUSD

Removed value: -{
-  "anyOf": [
-    {
-      "description": "charged to date; only when no line matched",
-      "type": [
-        "number",
-        "null"
-      ]
-    },
-    {
-      "type": "null"
-    }
-  ]
-}

addedOutput schema / properties / settledBeforeMicroUSD

Added value: +{
+  "anyOf": [
+    {
+      "description": "what we had settled against this channel before this call; only when no line matched",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

addedOutput schema / properties / thisCallMicroUSD

Added value: +{
+  "anyOf": [
+    {
+      "description": "what this call is charged: the row it paid",
+      "type": [
+        "number",
+        "null"
+      ]
+    },
+    {
+      "type": "null"
+    }
+  ]
+}

AddedSep 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes well beyond the annotations: it discloses that the operation is paid and settled on chain, is not idempotent, each call buys another block, the line is cut when balance runs out, nothing more is charged, and unused time is refunded. This is rich behavioral context with no contradiction to the annotations.

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 dense but consistently purposeful, front-loading the core action and then layering lifecycle, payment, and parameter details. The example at the end is helpful without bloating the structure.

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?

The description covers purpose, purchasing mechanics, collateral, refunds, line-cut behavior, and the output values. Given the output schema exists union with the description's explicit return statement, an agent has everything needed to call this tool correctly.

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

Parameters5/5

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

Although the schema already covers 'line' at 100%, the description adds crucial nuance: omitting it lands the block on the channel, it is not needed when a call carries its own payment, and the example shows the expected credential format. This fully compensates and then some.

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 opens with a specific action: 'Buys one block of time on your line' and precisely defines the effect as 'a payment adds 250ms to a clock.' It also distinguishes the tool from work-bearing siblings by noting it 'never touches the switch' and is 'that purchase with no work attached.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives practical guidance on when to use it, such as 'Not needed when a call carries its own payment' and clarifies that omitting the line parameter places the block on the channel. It does not explicitly name sibling tools as alternatives, but the 'no work attached' contrast gives enough routing context.

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

All ZEAM Prism MCP tools Inspect

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

Need Help?