Fresh402

Cross-domain Release Evidence

fresh402_cross_domain_release_evidence

Destructive

Combine one scoped website, an optional JSON OpenAPI comparison and selected finalized Base evidence into one bounded release brief. Separate provenance and missing/conflicting evidence; a release-label mention never proves deployment or causality. One fixed workflow charge; internal steps never create separate customer charges. First source use seeds state in this same operation; later observations use returned owned observation_id. Auth: authorized native-USDC x402 v2 on Base, enabled MPP, or an eligible prepaid key plus exact tariff 5 and max_credits. Ordinary unpaid calls return a challenge, not execution. Persist original input, proof and recovery token before submission; exact replay returns retained results without fresh work or another charge. Choose evidence detail before authorization. No free-trial or automatic paid fallback. 0.040 USDC or 16 credits. Limits and scope are authoritative, not a complete audit or compatibility guarantee.

Input Schema

Name	Required	Description	Default
`url`	No	Public HTTPS source for a new or existing canonical source/scope identity. Supply exactly one of url or observation_id. A new identity seeds once; the next operation compares.
`scope`	No	Immutable supported normalization rules. Selected attributes participate in change detection; ignored fields are outside the reported scope. No browser execution or linked-page crawling.
`detail`	No	Default compact: at most 20 evidence items per section. Expanded allows at most 200 document findings or 100 Base events and retains raw validated logs/getter ABI details within the same fixed work/output ceiling. Counts and omitted-evidence warnings remain explicit.	compact
`api_url`	No	Optional explicit JSON OpenAPI source for a new cross-domain identity; no link discovery. Saved observation_id freezes this URL too.
`onchain`	No	Required with url for a new cross-domain identity. One narrow finalized Base brief; its addresses become immutable and share one existing 18-RPC reservation.
`compare_to`	No	Default previous compares with the latest successful workflow observation; baseline compares with its original seed. Seeding is one paid workflow operation and reports no comparison, never a second internal charge.	previous
`release_label`	Yes	Claimed release identifier. Exact source mentions are evidence only, never authentication, deployment proof or causality. May change between observations without changing source identity.
`observation_id`	No	Owned observation_id returned by this same workflow. Reuses its immutable source/scope and saved baseline/latest observations; not a primitive watch_id. Seven-day state retention. Missing, foreign or expired IDs never silently rebaseline.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

changedInput schema / oneOf

Previous value: -[
-  {
-    "not": {
-      "required": [
-        "observation_id"
-      ]
-    },
-    "required": [
-      "url"
-    ]
-  },
-  {
-    "not": {
-      "required": [
-        "url"
-      ]
-    },
-    "required": [
-      "observation_id"
-    ]
-  }
-]New value: +[
+  {
+    "not": {
+      "required": [
+        "observation_id"
+      ]
+    },
+    "required": [
+      "url",
+      "onchain"
+    ]
+  },
+  {
+    "not": {
+      "anyOf": [
+        {
+          "required": [
+            "url"
+          ]
+        },
+        {
+          "required": [
+            "scope"
+          ]
+        },
+        {
+          "required": [
+            "api_url"
+          ]
+        },
+        {
+          "required": [
+            "onchain"
+          ]
+        }
+      ]
+    },
+    "required": [
+      "observation_id"
+    ]
+  }
+]

AddedNov 6, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare the mutation/destructive/open-world profile, and the description adds substantial value on top: auth methods (native-USDC x402 v2, MPP, prepaid key), tariff 5 plus max_credits, one fixed workflow charge with no internal per-step charges, challenge-not-execution for unpaid calls, seven-day state retention, and an 18-RPC reservation. There is mild tension with idempotentHint=false, since exact replay is said to return retained results without fresh work or another charge, but this is a replay-cache statement rather than a direct contradiction of the annotation.

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 strongest content is front-loaded in the first two sentences, and the closing disclaimers about audit/compatibility limits are load-bearing rather than filler. However, the middle section is written in telegraphic, clause-dense sentences (auth, charge, replay, and detail ordering packed together), which slows parsing for an agent that just needs the call contract.

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 an 8-parameter, nested-object, mutually-exclusive-schema tool with no output schema, the description covers everything an agent needs: cost, auth prerequisites, seed-vs-resume lifecycle, replay behavior, state retention, and explicit scope limits. Return-value shape is the only thing left implicit, and the brief/evidence-item sizing is described via the detail parameter.

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 description coverage is 100%, so the baseline would be 3. The description earns above baseline by explaining the lifecycle relationship behind the oneOf branches: url/onchain seeds a new identity while observation_id resumes an existing one, and compare_to's 'previous' vs 'baseline' semantics are framed in terms of that seed. It does not add detail about the nested scope selectors beyond what the schema already documents.

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 opening sentence names a specific composite verb and resource: combining one scoped website, an optional JSON OpenAPI comparison, and finalized Base evidence into one bounded release brief. Because the sibling set contains single-domain tools (fresh402_website_change_intelligence, fresh402_openapi_contract_diff, fresh402_onchain_evidence_brief), the explicit 'cross-domain / combined' framing lets an agent route correctly without opening any schema.

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?

It gives concrete call-order guidance: the first source use seeds state in the same operation, later observations must use the returned owned observation_id, and detail must be chosen before authorization. It also rules out unpaid execution and automatic paid fallback. The gap is that it never names which sibling to use when the agent wants only one domain or a primitive watch instead of this composite workflow.

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

All Fresh402 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?