Wever Labs Agentic Rails

Create a digest

wever_digest-create

Standing jobs: register a digest for the paying wallet with a cadence (hourly, daily, weekly or interval), an optional start_at, a callback_url and an expires_at up to 30 days ahead. Each window collects the wallet’s Wever Watch fires and standing-job results recorded while it was open (sources: watch_fires, job_results or both) and posts one signed digest report to callback_url. Windows with nothing to report are posted only with include_empty: true. One call covers every window until the digest ends. POST /api/digest-create. Standing jobs check and report: they run read-and-report Wever tools only and never move money, place orders or change state. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Every call carries X-Wever-Wallet-Proof bound to the exact JSON arguments and the tool route; a paid call adds Payment-Signature from the same wallet. Returns a report with an Ed25519 signed receipt. Contract: /api/standing-jobs-contract. Human page: https://weverlabs.com/standing-jobs/.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "cadence": "<cadence>",
      "callback_url": "<callback_url>",
      "expires_at": "<expires_at>"
    },
    "name": "wever_digest-create"
  }
}

Input Schema

Name	Required	Description
`label`	No	Optional name shown in lists, reports and digests.
`cadence`	Yes	hourly, daily, weekly, or interval with interval_seconds.
`sources`	No	watch_fires, job_results or both (the default).
`start_at`	No	Optional first run or window start. Defaults to the first whole minute at least 60 seconds after the call. Later runs follow this anchor.
`expires_at`	Yes	When the schedule ends, up to 30 days ahead. No run starts at or after this time.
`callback_url`	Yes	Public HTTPS URL that receives one signed digest report per window as a JSON POST.
`include_empty`	No	true posts a digest for windows with nothing to report. Defaults to false.
`interval_seconds`	No	Seconds between runs when cadence is interval: 900 (15 minutes) to 604800 (7 days).

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Beyond the annotations, the description discloses the payment model (0.10 USDC per call on Base via x402 exact, 10 free signed-wallet calls per rolling 30 days), the required auth headers (X-Wever-Wallet-Proof bound to exact JSON arguments, Payment-Signature on paid calls), and the return artifact (report with Ed25519 signed receipt). It also sets a safety boundary that standing jobs never move money, place orders or change state. The write behavior (registering a schedule) is consistent with readOnlyHint=false.

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?

The purpose is front-loaded, but the body is a dense run-on paragraph that packs scheduling semantics, payment mechanics, auth headers, contract links and a human URL into continuous prose without structure. The contract and human-page URLs and the per-call pricing detail, while useful, make it harder to scan for the operational essentials.

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 standing-job creation tool with no output schema, the description covers scheduling window semantics, expiry limits, empty-window behavior, invocation cost and auth requirements, and what is returned. Nothing an agent needs in order to invoke it correctly or anticipate the response appears to be missing.

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 coverage is 100% and the per-parameter descriptions are already detailed, so the schema carries most of the parameter burden. The description adds some semantic glue — what a window is, that sources drive window contents, that empty windows require include_empty: true, and the 30-day expiry ceiling — but it largely restates schema facts such as cadence options and required fields.

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 clause gives a specific verb and resource ('register a digest') plus the owning context ('standing jobs', 'paying wallet'), and the body makes clear this creates a recurring schedule rather than a one-off. An agent can distinguish it from wever_digest-status and wever_digest-cancel purely from the text.

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 states the situation the tool is for (collecting Wever Watch fires and standing-job results and posting one signed digest per window) and clarifies that a single call covers every window until expiry. It also notes the 'standing jobs run read-and-report tools only' boundary. It stops short of explicitly naming siblings like wever_digest-status for checking or wever_digest-cancel for stopping, so routing to alternatives is implied rather than stated.

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

All Wever Labs Agentic Rails 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?