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

Beyond the annotations, the description discloses the billing model (0.10 USDC on Base via x402 exact, plus 10 free signed-wallet calls per 30 days), the authentication requirements (X-Wever-Wallet-Proof bound to the exact JSON arguments and route, Payment-Signature for paid calls), and the async side effect (each run POSTs a signed report to callback_url). It also explains validation ordering ('validates the input before billing'), the 30-day expiry ceiling, and the exact success payload (job id, accepted anchor, interval, expiry, planned runs, first run times). The only gap is what happens when a callback delivery fails or a job is cancelled, which sibling tools cover.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose and parameters are front-loaded in the first two sentences, which is good. However, the second half is a dense run-on of payment rails, wallet-proof headers, contract paths and a human URL that reads as boilerplate repeated across the Wever tool family rather than information needed to select and invoke this tool. Splitting the operational contract into distinct sentences about scheduling rules, billing, and returns would make the payload far more scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a nine-parameter, async, paid, open-world tool with no output schema, the description covers what an agent most needs: what is accepted, what is refused, what the response contains, and how the callback behaves. The explicit return-field list compensates for the missing output schema. It is not fully complete on failure and lifecycle behavior (callback retry policy, interaction with wever_schedule-cancel), but those are secondary for a create call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 all nine parameters in detail, including the {{run_at}}/{{run_date}} templating and the 900–604800 interval bounds. The description largely restates those constraints (cadence list, interval range, 30-day expiry, templating) rather than adding new meaning, though it does add the useful rule that the tool name must come from the schedulable list in the contract. That is a marginal gain over an already-complete schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'register a recurring job for the paying wallet', and enumerates the exact shape of the registration (tool, input, cadence, callback_url, expires_at). It is clearly distinct from execution-style siblings like wever_refund-eligibility-check or wever_payout-execute because it explicitly names them as schedulable targets rather than actions. It stops short of naming its closest siblings (wever_schedule-list, wever_schedule-status, wever_watch-create), so an agent must infer the boundary from the tool name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete selection context: use it to schedule read-only Wever tools, hourly/daily/weekly/interval cadences, and it states the exclusion clearly — 'a tool that moves money, places an order or changes state is refused with tool_not_schedulable'. It also says 'one call covers every run until the job ends', which routes the agent away from looping the underlying tool manually. It never compares against wever_watch-create or wever_digest-create, which also create recurring behavior, leaving a real alternative unaddressed.

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