TWZRD Agent Intelligence

twzrd_watch_add

After registration, TWZRD will proactively re-check the seller's trust intel
when `recheck_after_unix` elapses and POST a notification to your webhook_url
if the score/decision materially changes.

The watch routes are control-proof authenticated (fail closed): signature
and timestamp prove the caller holds the payer wallet's key. Return the
watch row with the computed recheck_after_unix timestamp so your agent
knows exactly when to expect a re-call or proactively re-check itself.

Input Schema

Name	Required	Description
`signature`	Yes	base58 ed25519 signature made with the payer wallet's key over the twzrd-watch/v1 message for action=register: the seven lines [twzrd-watch/v1, register, str(timestamp), payer_wallet, seller_wallet, webhook_url or '', ''] joined by newlines.
`timestamp`	Yes	Unix seconds used in the signed message (freshness window: 300s).
`webhook_url`	No	Optional HTTPS URL to POST when intel goes stale.
`payer_wallet`	Yes	Your agent wallet address (the watcher).
`seller_wallet`	Yes	The seller/merchant wallet to watch.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 16, 2026

addedInput schema / properties / signature

Added value: +{
+  "description": "base58 ed25519 signature made with the payer wallet's key over the twzrd-watch/v1 message for action=register: the seven lines [twzrd-watch/v1, register, str(timestamp), payer_wallet, seller_wallet, webhook_url or '', ''] joined by newlines.",
+  "title": "Signature",
+  "type": "string"
+}

addedInput schema / properties / timestamp

Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "integer"
+    }
+  ],
+  "description": "Unix seconds used in the signed message (freshness window: 300s).",
+  "title": "Timestamp"
+}

changedInput schema / required

Previous value: -[
-  "payer_wallet",
-  "seller_wallet"
-]New value: +[
+  "payer_wallet",
+  "seller_wallet",
+  "signature",
+  "timestamp"
+]

First observedJul 11, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations only declare openWorldHint=false, idempotentHint=false, destructiveHint=false. The description adds substantial context: control-proof, fail-closed authentication where signature+timestamp prove the caller holds the payer wallet's key, and the asynchronous re-call/webhook behavior. It stops short of 5 by not flagging the idempotentHint=false implication that repeated registrations create distinct watches.

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, then layers on lifecycle, auth, and return-value context. Sentences are dense but each carries signal; overall slightly longer than strictly necessary but well organized.

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?

An output schema exists, so return structure need not be detailed, yet the description usefully notes the returned watch row and computed recheck_after_unix. Auth model, async lifecycle, and the freshness window (via schema) are covered, leaving little for an agent to guess before invoking.

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 baseline is 3. The description references webhook_url and the auth fields conceptually, but adds no format, constraint, or default detail beyond what the schema already documents for the five parameters.

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?

The opening sentence states a specific verb and resource ('Register a re-call watch on a seller wallet'), and the assembly of the watch/unwatch siblings (twzrd_watch_list, twzrd_watch_remove) makes the additive nature inferable from 'register'. It does not name any sibling explicitly, so it falls short of the top tier.

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 description explains the mechanism (proactive re-check after recheck_after_unix, webhook POST on material change), which implies when this tool is useful. However, it never states when to choose this over twzrd_watch_list/remove or other intel tools, and gives no explicit exclusions or prerequisites beyond it being a registration.

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

All TWZRD Agent Intelligence 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.