Wever Labs Agent Products

Agent Daily Operator Brief

wever_agent-daily-operator-brief

Paid URL: 0.25 USDC per call on Base; 10 signed-wallet free calls shared over rolling 30 days. Free computation: /api/mcp or /api/service-resolver. Read the backend 402 body for x402 terms. Turn supplied service health and queue observations into a prioritized operator brief. Operating boundary: Supply service health and queue observations. Read the ordered priorities and their source observations. Agents prepare the brief; humans use it to choose the next operational task. POST /api/agent-daily-operator-brief. Existing product credentials, signed mandates, and single-use action grants remain required where applicable. This adapter grants no authority and never supplies server credentials. This current operation is a bounded computation on caller-supplied data.

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": {
      "as_of": "<as_of>",
      "services": "<services>",
      "queues": "<queues>"
    },
    "name": "wever_agent-daily-operator-brief"
  }
}

Input Schema

Name	Required	Description
`as_of`	Yes	A valid UTC calendar timestamp with whole seconds, supplied by the caller.
`queues`	Yes	Unique queue names. Empty queues must have a null or zero oldest age.
`services`	Yes	Unique service_id values.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 29, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Well beyond the annotations, it discloses pricing (0.25 USDC per call on Base, 10 free calls per rolling 30 days), where to read x402 terms, that credentials/mandates/grants remain required, and that the adapter itself supplies no credentials or authority. The one gap is that readOnlyHint=false and openWorldHint=true are never explained, leaving the agent to guess whether the paid call is the only side effect.

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?

Not applicable here.

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?

With annotations present, a fully described schema and no output schema, the description covers the essentials plus the output shape ('ordered priorities and their source observations'). What is missing is any hint of failure modes, e.g. what happens on malformed observations or insufficient payment.

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%, including patterns, enums, maxItems and the null-age rule for empty queues, so the schema carries the parameter detail. The description only loosely references 'service health and queue observations' and adds no meaning beyond it, so the baseline of 3 applies.

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 sentence 'Turn supplied service health and queue observations into a prioritized operator brief' names a specific verb, input and output, so an agent knows exactly what it produces. It does not, however, name or contrast any sibling (e.g. callback-health-monitor or sla-rail), so the differentiation is left implicit.

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 'Operating boundary' paragraph implies when this is appropriate: the caller supplies observations, the tool orders them, and a human acts on the result. That is useful framing, but there is no explicit when-not guidance and no named alternative for live monitoring or SLA evaluation among the many sibling rails.

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

All Wever Labs Agent Products 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.