Wever Labs Agentic Rails

Shared cap check

wever_shared-cap-check

Read-only

Agent Limits: submit one cap shared by several agents or tasks (one wallet, budget or quota, with its amount and period), how spending against it is counted (in one place, per agent or nowhere, updated in real time, in batches or at period end, and whether each spend is checked and reserved against the shared count in one step before money moves), each agent drawing on it with what it reads its remaining room from (the shared count, its own estimate or nothing) and the most it can spend before its view refreshes, and any spending recorded against the cap in one period. The signed report says whether the cap is accounted in one place in real time, names every way agents can drain it in parallel (no shared count, a lagging count, an agent reading its own estimate, checking and spending in separate steps), gives how far the total can pass the cap from the agents’ in-flight room, and names recorded spending over the cap, with the fix for each. This reads how one cap is counted across agents: whether a budget has its controls is wever_budget-controls-check, what a cap aggregates over is wever_exposure-cap-check and one request against one budget is wever_agent-budget-guard. Verdict cap_overshot, cap_can_overshoot, accounting_unverified or accounted_in_one_place. POST /api/shared-cap-check. Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route. Returns a report with an Ed25519 signed receipt. Contract: /api/agent-limits-contract. Human page: https://weverlabs.com/agent-limits/.

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": {
      "cap": "<cap>",
      "agents": "<agents>"
    },
    "name": "wever_shared-cap-check"
  }
}

Input Schema

Name	Required	Description
`cap`	Yes
`label`	No	Optional name recorded in the report.
`agents`	Yes	Each agent or task drawing on the cap.
`ledger`	No
`observed`	No	Spending recorded against the cap in one period.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already declare readOnly, non-destructive, non-open-world, so the safety profile is largely covered. The description adds real value beyond them by disclosing the payment model (paid URL, 0.10 USDC via x402, shared free calls), the wallet-proof binding to the exact JSON arguments and route, and that it performs no network request, fetch or external write. It also names the four verdicts, which is behavior annotations cannot express.

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?

Every passage carries information, but the opening sentence is a single ~130-word run-on that forces the reader to re-parse before reaching the actual claim. The purpose statement arrives after the input enumeration rather than being front-loaded. Later sentences (siblings, verdicts, endpoint, payment, contract) are tighter.

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 nested-input tool with no output schema, the definition covers inputs, the verdict taxonomy, the signed receipt, the endpoint, the payment and proof mechanics, and links to the contract and human page. The only meaningful omission is a fuller statement of what the signed report contains besides the verdict names, though the sibling description of drains and overshoot bounds partly covers this.

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?

With 60% schema coverage and five parameters including nested objects, the description does meaningful semantic work: it explains cap kind/amount/period, the ledger's location, update timing and reserve-before-spend step, each agent's 'tracks' source and its refresh window, and recorded spending per period. The enum values are paraphrased rather than duplicated, so the agent gets a conceptual model of each field. It does not add format or validation detail beyond what the schema provides.

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 description names a specific analysis: taking a cap shared by several agents, the ledger semantics, per-agent tracking and observed spends, and returning a signed verdict report. It is clearly separable from named siblings (budget-controls, exposure-cap, agent-budget-guard). The purpose is only mildly obscured by the opening run-on sentence, which delays the 'what it does' statement until the 'The signed report says...' sentence.

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 explicitly routes the agent away from two siblings: budget-controls-check for whether a budget has its controls, exposure-cap-check for what a cap aggregates over, and agent-budget-guard for one request against one budget. That is concrete when-to-use/when-not-to-use guidance. It stops short of stating prerequisites or the conditions under which the shared-cap angle is the right one.

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?