Wever Labs Agentic Rails

Open a second-date market

wever_second-date-market-open

Idempotent

Create a market linked to your completed staked first date. Both daters sign in and approve its exact terms as consenting adults before betting opens. POST /api/second-date-market-open. API access costs 0.10 USDC per call on Base mainnet using x402 exact, under the existing shared 10 signed-wallet free calls per rolling 30 days. This access fee is separate from play-credit stakes. Each wallet begins with 25 free play credits. X-Wever-Wallet-Proof binds the exact JSON arguments and API path. Human consent and reports use https://weverlabs.com/second-dates/. Betting closes at the deadline or first human report. Missing reports return stakes seven days after the close. Keep request_id and exact arguments for retry; use a new request_id for current status. Read /api/second-dates-contract for schemas and public receipt verification key.

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": {
      "date_id": "<date_id>",
      "request_id": "<request_id>"
    },
    "name": "wever_second-date-market-open"
  }
}

Input Schema

Name	Required	Description	Default
`date_id`	Yes
`closes_at`	No
`request_id`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations already declare a non-read-only, open-world, idempotent, non-destructive mutation. The description adds substantial context beyond that: x402 API pricing, shared free-call quota, wallet-proof binding, consent process, betting close rules, missing-report stake return, and retry behavior.

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

Conciseness4/5

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

The purpose is front-loaded and most sentences carry operational value for a paid, consent-gated market-opening call. It is still a dense single paragraph and could be better structured, but it avoids significant repetition.

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 paid mutation with no output schema, the description covers cost, consent, closure, refunds, retry semantics, and points to the contract endpoint for schemas and receipt verification. It still leaves parameter-level and response-level details thin.

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

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it only partially does. It implies date_id links to the completed first date and explains request_id reuse for retries, but it never explains closes_at or the parameter patterns and constraints.

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 description states a specific verb and resource: creating a market linked to a completed staked first date. It distinguishes this from betting/resolution siblings by centering on the consent-gated opening of the market before betting begins.

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 gives clear prerequisites: a completed staked first date and both daters signing in to approve exact terms before betting opens. It also explains retry/status request_id handling, though it does not name explicit alternatives or when-not-to-use conditions.

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?