Skip to main content
Glama

Limit change check

wever_limit-change-check
Read-only

Agent Limits: submit a system’s limit-change process: each path that raises, loosens, suspends, lowers or tightens a limit, with who can take it (owner, admin, the agent, another agent, an automation or anyone), where the change is made, when a second party approves it (before it takes effect, after or never), the approver and when it is recorded, plus the limit changes recorded so far with who made them, who approved them and when each took effect, was approved and was recorded. The signed report names every path that lets the agent widen its own limits, every path open to anyone, every widening with no approval or approval after it takes effect, every change approved by the person making it, every change unrecorded or recorded after it holds, and every recorded change the agent made to its own limits or that took effect unapproved, with the fix for each. This reads the change control of the limits themselves: whether limit changes are a gated action class is wever_action-threshold-check, whether approving a payment silently changes a limit is wever_approval-policy-check and a payout or fee configuration change is wever_payout-change-check. Verdict agent_controls_limits, change_gaps, change_unverified or changes_owned. POST /api/limit-change-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/.

Input Schema

NameRequiredDescriptionDefault
agentNoThe agent whose limits these are.
labelNoOptional name recorded in the report.
pathsYesEach way a limit can be raised, loosened, suspended, lowered or tightened.
historyNoPast limit changes as recorded.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already cover the safety profile, and the description adds substantial context on top: reads only call material, no network/fetch/money movement/external write, paid URL pricing (0.10 USDC via x402 exact), a 10 free signed-wallet call allowance per rolling 30 days, a required X-Wever-Wallet-Proof bound to the exact JSON args and route, and an Ed25519 signed receipt in the return. That is behavior an agent cannot get from the annotations or schema.

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?

Front-loaded with purpose and sibling routing, which is good, but the first sentence is an ~80-word nested enumeration and the tail packs verdicts, endpoint, payment, auth binding, receipt, contract and human page into one block. Every element is relevant, yet the density hurts scannability and some of the path-field restatement could be cut.

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?

With no output schema, the description compensates by describing the signed report's content (widening paths, anyone-open paths, unattended widenings, self-approved and unrecorded changes, with the fix for each) and naming the four verdicts. Given the read-only annotations and full schema coverage, an agent has everything needed to call and interpret it.

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 schema already documents agent, label, paths (action/who/who_kind/via/approval/approver/recorded) and history fields. The description mirrors those enumerations in prose ('who can take it... where the change is made, when a second party approves it...') but adds no syntax, formatting, or defaulting guidance beyond the schema. Baseline 3.

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?

States a specific verb and resource ('submit a system's limit-change process') and immediately delimits it against three named siblings (wever_action-threshold-check for whether limit changes are a gated action class, wever_approval-policy-check for payment-approval side effects, wever_payout-change-check for payout/fee config). An agent can 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?

Explicitly scopes usage: 'This reads the change control of the limits themselves' and hands off three adjacent concerns to named siblings. It also lists the verdicts produced, which implicitly signals when the tool applies. What's missing is an explicit 'do not use this when...' exclusion beyond the sibling handoffs, so a 4 rather than a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.