ZEAM :: Prism

Report on an MCP server

attest_server

Read-onlyIdempotent

Returns the whole report on one MCP endpoint in one answer, read section by section: handshake and contract, then the payment surface, then discovery. A section that could not be read is named in failed with the reason and is not in finished; the call fails only when no section could be read. A call cut for time returns the sections finished so far, marked partial and named in finished, with those still to do named in unfinished, every request made so far in evidence, and about_ms, the time the whole report needs at most, with each request still to make counted at the slowest this server answered, never at a request this shelf stopped; before the server has answered any, at the slowest an earlier report on this shelf was answered in, and with no such report there is no about_ms. Cut as its last section finishes, the call returns the whole report, partial false, with no about_ms. A call its caller cancels answers client_gone with the same snapshot: the sections finished and every request made so far. Same checks as the three single-section tools; about 25 requests to the server named. Each request is waited on for up to 15 s; one not answered by then is reported timed_out, never as the server's answer. Paid, on a line: $0.000001 per millisecond. With no wallet code, ZEAM :: Pass buys the time and opens the line: a pass (https://mcp.zeamprism.com/pass) or your own wallet (https://mcp.zeamprism.com/how-to-pay). Example: {"url":"https://mcp.zeamprism.com/mcp"}

Input Schema

Name	Required	Description
`url`	Yes	string — the MCP endpoint, absolute http(s) URL, e.g. https://host/mcp. Private and internal names and addresses are refused.
`line`	No	Optional. A line credential, for a client that cannot send the x-line header or _meta["zeam-pass/line"]: the call runs on that line's time.
`tool`	No	optional string — the tool to call unpaid; default: the first tool that answers an unpaid call with x402 terms, trying the tools the server prices first, then the unpriced ones in tools/list order (at most `probe` tools are tried).
`probe`	No	optional int — how many tools to try when `tool` is omitted; default 5.
`arguments`	No	optional object — arguments for that tool, sent first and as given; default: {}, then the example the server publishes for the tool, then arguments built from its inputSchema.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 24, 2026

changedOutput schema / anyOf

Previous value: -[
-  {
-    "properties": {
-      "about_ms": {
-        "anyOf": [
-          {
-            "description": "on a partial answer: an estimate of the time the whole report needs, at the pace this server answered so far",
-            "type": "number"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "at": {
-        "anyOf": [
-          {
-            "description": "ISO time of the run",
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "error": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "evidence": {
-        "anyOf": [
-          {
-            "description": "every request made, in the order sent: method, url, request headers of note, status, ms; a request that drew no answer has status 0 and its error, a redirect followed is listed in redirects, and a request still unanswered when a report was cut has unanswered: true",
-            "items": {},
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "failed": {
-        "anyOf": [
-          {
-            "description": "the sections that could not be read: section, error",
-            "items": {},
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "finished": {
-        "anyOf": [
-          {
-            "description": "the sections this answer holds, each complete",
-            "items": {},
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "ok": {
-        "anyOf": [
-          {
-            "type": "boolean"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "partial": {
-        "anyOf": [
-          {
-            "description": "true while a section is still to do",
-            "type": "boolean"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "section": {
-        "anyOf": [
-          {
-            "description": "the last section this frame completes, or plan before any; the last frame carries all of them",
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "unfinished": {
-        "anyOf": [
-          {
-            "description": "the sections not in this answer",
-            "items": {},
-            "type": "array"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      },
-      "url": {
-        "anyOf": [
-          {
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      }
-    },
-    "type": "object"
-  },
-  {
-    "required": [
-      "error"
-    ],
-    "type": "object"
-  },
-  {
-    "required": [
-      "accepts"
-    ],
-    "type": "object"
-  },
-  {
-    "required": [
-      "receipt"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "properties": {
+      "about_ms": {
+        "anyOf": [
+          {
+            "description": "on a partial answer: the time the whole report needs at most, on the costs met so far: the time spent, and each request still to make, the one under way included, at the slowest this server answered. A request this shelf stopped (timed_out, too_large or canceled) is never counted as an answer. Before this server has answered any, each is counted at the slowest an earlier report on this shelf was answered in; with no such report, the answer carries no about_ms",
+            "type": "number"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "at": {
+        "anyOf": [
+          {
+            "description": "ISO time of the run",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "error": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "evidence": {
+        "anyOf": [
+          {
+            "description": "every request made, in the order sent: method, url, request headers of note, status, ms; a request that drew no answer has status 0 and its error; one this shelf stopped has status null and says why: timed_out with limit_ms (no answer in 15 s), too_large with limit_bytes, or canceled; a redirect followed is listed in redirects, and a request still unanswered when a report was cut has unanswered: true",
+            "items": {},
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "failed": {
+        "anyOf": [
+          {
+            "description": "the sections that could not be read: section, error",
+            "items": {},
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "finished": {
+        "anyOf": [
+          {
+            "description": "the sections this answer holds, each complete",
+            "items": {},
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "ok": {
+        "anyOf": [
+          {
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "partial": {
+        "anyOf": [
+          {
+            "description": "true while a section is still to do",
+            "type": "boolean"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "section": {
+        "anyOf": [
+          {
+            "description": "the last section this frame completes, or plan before any; the last frame carries all of them",
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "unfinished": {
+        "anyOf": [
+          {
+            "description": "the sections not in this answer",
+            "items": {},
+            "type": "array"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "url": {
+        "anyOf": [
+          {
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      }
+    },
+    "type": "object"
+  },
+  {
+    "required": [
+      "error"
+    ],
+    "type": "object"
+  },
+  {
+    "required": [
+      "accepts"
+    ],
+    "type": "object"
+  },
+  {
+    "required": [
+      "receipt"
+    ],
+    "type": "object"
+  }
+]

AddedOct 15, 2026

TDQS

A3.8/5.0

Behavior5/5

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

Goes far beyond the readOnly/idempotent/openWorld annotations: it defines failed vs finished, the exact partial-snapshot contract on timeout (finished, unfinished, evidence, about_ms), the client_gone behavior on caller cancellation, the 15 s per-request wait with timed_out, the ~25-request load, and the billing unit. This is the kind of operational detail an agent cannot get from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, and every sentence does carry real semantics. However, the body is a single dense run-on with deeply nested clauses that is hard to parse, and the payment/wallet instructions sit awkwardly at the tail rather than being structured separately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, multi-section, partial-result tool this is nearly complete: success, partial, total-failure, cancellation, timeout, timing estimate, and cost are all covered, and an output schema exists so return shape needn't be spelled out. The gap is the unexplained unpaid x402 probe phase, where the tool sends supplied or derived arguments to another tool on the target server before this report runs.

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 description coverage is 100%, so the schema already documents url, line, tool, probe, and arguments thoroughly, making 3 the baseline. The description adds the 25-request scale and the 15 s timeout but says nothing about the unpaid-probe behavior that tool/probe/arguments control, which is the least obvious part of the contract.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource: 'Returns the whole report on one MCP endpoint in one answer, read section by section: handshake and contract, then the payment surface, then discovery.' That enumerates the three sections, which implicitly maps onto the single-section siblings. It never names attest_contract/attest_payment/attest_discovery directly, so the differentiation is inferable rather than explicit.

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

Usage Guidelines3/5

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

The 'one answer' framing and 'Same checks as the three single-section tools' imply this is the aggregate alternative to the per-section tools, and 'about 25 requests' plus per-millisecond pricing hints when it is expensive. But there is no explicit when-to-use statement, no 'prefer X when you only need the payment surface', and no guidance on when the aggregate is the wrong choice.

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

All ZEAM :: Prism 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?