Wever Labs Agentic Rails

Negotiation terms check

wever_negotiation-terms-check

Read-only

Agent Negotiation: submit one proposed deal’s terms: the buyer and seller, the price as written with its basis (fixed, per unit, per hour, per milestone or variable), the scope in and out, each deliverable with its due date, acceptance test and who accepts it, the timeline, each payment with its amount, trigger (signing, delivery, acceptance, a milestone, a date or nothing), what the trigger refers to and how soon it is paid, and any other term as written. The signed report says deliverable by deliverable whether an acceptance test decides it and payment by payment whether something makes it due, and names no price, a price in open wording, no deliverables, every deliverable with no acceptance test, no payment terms and every payment with no trigger, then triggers pointing at nothing, unclear amounts, payments that differ from a fixed price, vague acceptance wording, tests nobody runs, undated deliverables, deliverables outside the timeline, scope gaps and terms left for later (quoting TBD, as needed or market rate), with the fix for each. A service’s published terms are wever_service-terms-check, two contract versions are wever_contract-diff-check and delivered work against its criteria is wever_deliverable-check. The packet checklist is wever_negotiation-snapshot on https://weverlabs.com/mcp-free. Verdict terms_incomplete, terms_gaps, terms_unverified or terms_complete. POST /api/negotiation-terms-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-negotiation-contract. Human page: https://weverlabs.com/agent-negotiation/.

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": {
      "deliverables": "<deliverables>"
    },
    "name": "wever_negotiation-terms-check"
  }
}

Input Schema

Name	Required	Description
`deal`	No
`label`	No	Optional name recorded in the report.
`price`	No
`scope`	No
`terms`	No	Any other term as written.
`payments`	No	Each payment condition.
`timeline`	No
`deliverables`	Yes	Each deliverable.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare readOnly and closed-world, but the description adds material the annotations cannot carry: an enumerated verdict set, a paid x402 price of 0.10 USDC per call with a 10-call/30-day free tier, the X-Wever-Wallet-Proof binding requirement, and an Ed25519 signed receipt. It also spells out the full set of findings the report returns, which matters because there is no output 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?

The purpose is front-loaded, but the middle is a single dense run-on sentence enumerating every possible gap finding, and the tail stacks endpoint, pricing, auth and links into the same paragraph. The content largely earns its place given the absent output schema, but the structure makes it hard to scan.

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 nested eight-parameter tool with no output schema, the definition covers what goes in, what comes back (verdicts and findings), safety, pricing and auth. It leaves unresolved how an empty deliverables array is treated and how the signed receipt is shaped, both minor given the rest of the coverage.

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?

At 50% schema coverage the description compensates well, walking through buyer/seller, price with its basis (fixed, per unit, per hour, per milestone or variable), scope in and out, deliverables with due date and acceptance test, timeline, and each payment's amount, trigger, referent and due window. It does not clarify that only deliverables is required while all its sibling fields are optional, which is the one meaningful gap.

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 opens with a specific verb and resource — submit one proposed deal's terms and receive a signed report on whether deliverables are decided by acceptance tests and payments are made due. It then explicitly separates this from wever_service-terms-check, wever_contract-diff-check and wever_deliverable-check, so an agent can pick it out without reading 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?

It gives concrete routing rules to three named alternatives (published service terms, two contract versions, delivered work against criteria), which is clear when-to-use guidance. It stops short of stating exclusions or preconditions beyond the implied 'one proposed deal', so it is not a full when/when-not treatment.

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?