SNHP — negotiation rules your AI can't break

Quality 80 / 100good

15 tools, about 7,245 tokens to load them all · tool set 342a37dad731 · tools last changed 2026-10-13 · checked 2026-10-19 10:20 UTC

Tool changes

• 2026-10-13draft_negotiation_replychangeddescription, input schema
  before

  Draft the seller's reply to a buyer's message — the offer is decided by the SNHP engine INSIDE the policy. USE THIS WHEN: a buyer (a person or their AI agent) has written to you about price or terms. Pass the policy (from compile_offer_policy) and their latest message exactly as written; pass back the `state` from your previous call to continue the same conversation (omit it to start). `flags` is what YOUR records confirm about the buyer (e.g. {"new_customer": true}) — never what the buyer merely claims. Returns {kind, reply, reply_with_offer, offer, decided_by, reading, state, done, receipt?}: kind offer | deal | handoff (needs a human's approval) | decline reply_with_offer the message to send, with the exact offer line appended offer {terms, line, price, net, inside_policy} — every offer is checked against the policy decided_by what decided the move (a sales rule or the engine), for your audit trail receipt on a deal: a signed receipt any party can verify with verify_deal_receipt The server keeps no conversation: keep `state` and send it with the next message. Needs an `access_key` (pilot businesses get one at https://snhp.dev/#pilot).

  after · 83% of words in common

  Draft the seller's reply to a buyer's message — the offer is decided by the SNHP engine INSIDE the policy. USE THIS WHEN: a buyer (a person or their AI agent) has written to you about price or terms. Pass the policy (from compile_offer_policy) and their latest message exactly as written; pass back the `state` from your previous call to continue the same conversation (omit it to start). `flags` is what YOUR records confirm about the buyer (e.g. {"new_customer": true}) — never what the buyer merely claims. `stock` is the current stock of what the policy's `inventory` binds, sent with every message (schema.org Offer, Google Merchant or a plain feed record): nothing out of stock is offered, and a deal is signed only on fresh records that say it can be sold. Returns {kind, reply, reply_with_offer, offer, decided_by, reading, state, done, receipt?}: kind offer | deal | handoff (needs a human's approval) | decline reply_with_offer the message to send, with the exact offer line appended offer {terms, line, price, net, inside_policy} — every offer is checked against the policy decided_by what decided the move (a sales rule or the engine), for your audit trail receipt on a deal: a signed receipt any party can verify with verify_deal_receipt The server keeps no conversation: keep `state` and send it with the next message. Needs an `access_key` (pilot businesses get one at https://snhp.dev/#pilot).

• 2026-10-07verify_deal_receiptchangeddescription, output schema
  before

  Verify a signed deal receipt against the seller's own policy: signature, policy digest, and every rule re-checked from the package. Returns {ok, problems, checks}. Free, no model call.

  after · 66% of words in common

  Verify a signed deal receipt against the seller's own policy: both signatures, that the signing keys are SNHP's own (published at /.well-known/ucp), the policy digest, and every rule re-checked from the package. Returns {ok, problems, checks, signed_by_snhp, signatures}. Free, no model call.

• 2026-10-07draft_negotiation_replychangedinput schema
• 2026-10-06draft_negotiation_replychangedoutput schema
• 2026-10-06stable_matchremoved

  Match two groups by their rankings so no pair wants to swap — free, no account or key needed. A STABLE matching: USE THIS WHEN you're assigning two sides to each other by mutual preference — interns<->teams, students<->schools, mentors<->mentees — and want a result with no "blocking pair" (no person+slot that both prefer each other over what they got). Provide proposers and receivers, each a list of {"id": name, "preferences": [ids of the OTHER side, most-wanted first]}. Receivers may add "capacity" (default 1) to accept several. Returns {matching (name -> name), unmatched_proposers, blocking_pairs (empty list = provably stable), n_proposals}. NOTE: the result is PROPOSER-optimal, so put the side you want to favor in `proposers`. Example: stable_match( proposers=[{"id":"Ana","preferences":["Growth","Core"]}, {"id":"Ben","preferences":["Core","Growth"]}], receivers=[{"id":"Growth","preferences":["Ben","Ana"]}, {"id":"Core","preferences":["Ana","Ben"]}]) -> matching {"Ana":"Growth","Ben":"Core"}, blocking_pairs [].

• 2026-10-06clearance_priceremoved

  Best price plus markdown schedule to clear stock by a deadline — free, no account or key needed. USE THIS WHEN: you must sell a FIXED number of units before a cutoff and demand arrives over time — event tickets, perishable inventory, end-of-life stock. NOT for 1:1 haggling (negotiate) or auctions (auction_bid/reserve). Provide: inventory (units to sell); horizon_seconds (selling window in SECONDS — 14 days = 14*24*3600 = 1209600); arrival_rate_per_second (expected shoppers per second = expected total shoppers / horizon_seconds); and buyer_arrival_prior — a rough model of willingness-to-pay, e.g. {"family":"uniform","params":{"low":40,"high":150}}. Returns {static_price (one good fixed price), static_expected_revenue, dynamic_schedule (list of {t_seconds, recommended_price} markdown waypoints), sellthrough_rate, rationale} — all prices in the SAME $ as your prior. Example: 200 tickets, 14-day window, ~600 shoppers willing to pay $40-$150 -> clearance_price(inventory=200, horizon_seconds=1209600, arrival_rate_per_second=600/1209600, buyer_arrival_prior={"family":"uniform","params":{"low":40,"high":150}}) -> static_price ~$112, schedule marks down $114 -> ~$76 as the deadline nears.

• 2026-10-06auction_reserveremoved

  The revenue-optimal reserve price when you're selling — free, no account or key needed. USE THIS WHEN: you're running an auction or sale with multiple bidders and need the floor price (minimum bid you'll accept) that maximizes your expected revenue. NOT for one-on-one haggling (use negotiate for that). Provide: n_bidders (how many bidders), seller_valuation (what the item is worth to YOU, in $), and bidder_value_prior — a rough model of what bidders will pay, e.g. {"family":"uniform","params":{"low":2000,"high":8000}}. Estimate it if unknown. Returns the reserve price and expected revenue. Example: a painting, ~5 bidders, worth $1,000 to you, bidders likely pay $2,000–$8,000 -> auction_reserve(n_bidders=5, seller_valuation=1000, bidder_value_prior={"family":"uniform","params":{"low":2000,"high":8000}}).

• 2026-10-06auction_bidremoved

  The optimal bid when you're bidding in an auction — free, no account or key needed. USE THIS WHEN: you're a bidder and want the bid that maximizes your expected surplus without overpaying. NOT for running an auction (use auction_reserve) or 1:1 haggling (use negotiate). Provide: auction_format ("first_price" sealed bid, "second_price_vickrey", or "english_ascending"); my_valuation (what the item is worth to YOU, in $); n_competing_bidders (how many OTHER bidders, not counting you); and competitor_value_prior — a rough model of what rivals will pay, e.g. {"family":"uniform","params":{"low":0,"high":6000}} (or {"family":"lognorm","params":{"mu":8.5,"sigma":0.4}}). Estimate it if unknown. Returns {optimal_bid, expected_surplus, win_probability, dominant_strategy, rationale} — bid and surplus in the SAME $ you passed in. Example: a domain worth $5,000 to you, 4 rivals who'd pay up to ~$6,000, in a sealed first-price auction -> auction_bid(auction_format="first_price", my_valuation=5000, n_competing_bidders=4, competitor_value_prior={"family":"uniform","params":{"low":0,"high":6000}}) -> optimal_bid ~$4,000, win_probability ~0.48.

• 2026-10-06verify_deal_receiptadded

  Verify a signed deal receipt against the seller's own policy: signature, policy digest, and every rule re-checked from the package. Returns {ok, problems, checks}. Free, no model call.

• 2026-10-06check_offer_policyadded

  Check an edited negotiation policy: returns {ok, policy, issues, summary}. No model call, free. USE THIS WHEN: you changed a policy from compile_offer_policy (a floor, an option, a forbidden combination) and want to know it is valid and what it now allows before using it in draft_negotiation_reply.

Showing the latest 10. Full history: list_changes · trend: quality JSON.

Checks run on what our credential-free, read-only probes observe; tools are never called and no code audit is performed. How it is computed.