SNHP — free negotiation math + agent memory
REMOTE · API.SNHP.DEV · SCANNED AUG 3
Free game-theory negotiation advisor for agents, plus paid receipted sessions and agent memory.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically against the live server, and we only credit what we can confirm. How we score →
Endpoint Security63
- The endpoint's TLS certificate is valid, in date, and uses a strong key. View diagnostics → Pass
- Authorisation not fully verified: no authorisation is required to call this server, and 9 tool(s) never declared a destructiveHint. The MCP spec treats an absent hint as destructive by default, so we cannot call this surface safe. See how to fix → View diagnostics → Unverified
- HTTPS is enforced; there's no plaintext access path. View diagnostics → Pass
- The HSTS (Strict-Transport-Security) header is present. View diagnostics → Pass
- DNSSEC check failed: this domain isn't protected by DNSSEC. See how to fix → View diagnostics → Fail
Transport & Reachability100
- Verified streamable-http transport via a live MCP handshake. View diagnostics → Pass
Schema Quality & AI Usability51
- AI-judged instruction clarity (good).Pass
- Context-footprint check failed: tool/resource definitions use about 5967 tokens (~397/item across 15 items; 15 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management27
- Stability observed for 8 of 30 days with no destabilising changes; credit accrues until the full window elapses.Partial
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (100% of tools); any adoption earns full credit.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
Add this component to your MCP client. Where a client-specific snippet is available, pick your client below and copy it straight into your config; otherwise use the connection detail shown.
remote · api.snhp.dev
claude mcp add --transport http ryuxik-snhp https://api.snhp.dev/mcp/
[mcp_servers.ryuxik-snhp] url = "https://api.snhp.dev/mcp/"
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"ryuxik-snhp": {
"type": "remote",
"url": "https://api.snhp.dev/mcp/",
"enabled": true
}
}
} openclaw mcp add ryuxik-snhp --url https://api.snhp.dev/mcp/ --transport streamable-http
mcp_servers:
ryuxik-snhp:
url: "https://api.snhp.dev/mcp/" {
"mcpServers": {
"ryuxik-snhp": {
"type": "http",
"url": "https://api.snhp.dev/mcp/"
}
}
} The mcpServers block is a cross-client convention. Remote transports vary, so check your client's docs.
Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 2 Aug 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 20 to 23. That category is still filling its 30-day observation window: 6 days of observed history at the previous scan, 7 at this one. The score rises as the window fills, whether or not the server changes.
- 31 Jul 26 +2
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 30 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 29 Jul 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 7 to 10. That category is still filling its 30-day observation window: 2 days of observed history at the previous scan, 3 at this one. The score rises as the window fills, whether or not the server changes.
- 28 Jul 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 3 to 7. That category is still filling its 30-day observation window: 1 days of observed history at the previous scan, 2 at this one. The score rises as the window fills, whether or not the server changes.
- 27 Jul 26 0
- We updated how we score, so this day's move reflects our rubric, not a change to the server See what changed → functional
- 26 Jul 26 59
First indexed and scored.
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 3 Aug 2026 · Probed https://api.snhp.dev/mcp/
TLS valid
Negotiated TLS 1.3 with TLS_AES_128_GCM_SHA256 .
| Subject | Issuer | Valid from | Valid until | Key | Signature | Serial |
|---|---|---|---|---|---|---|
| CN=api.snhp.dev | CN=YE2,O=Let's Encrypt,C=US | 28 Jun 2026 | 26 Sept 2026 | ECDSA 256 | ECDSA-SHA384 | 5e612197dccd3348240ac417698313b99c8 |
| SANs: api.snhp.dev | ||||||
| CN=YE2,O=Let's Encrypt,C=US (CA) | CN=Root YE,O=ISRG,C=US | 3 Sept 2025 | 2 Sept 2028 | ECDSA 384 | ECDSA-SHA384 | 4df3b15dd6c0784c507cd37b58e6f115 |
| CN=Root YE,O=ISRG,C=US (CA) | CN=ISRG Root X2,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | ECDSA-SHA384 | 872165fc34b6e5fba8add5b3705fb53a |
| CN=ISRG Root X2,O=Internet Security Research Group,C=US (CA) | CN=ISRG Root X1,O=Internet Security Research Group,C=US | 13 May 2026 | 2 Sept 2032 | ECDSA 384 | SHA256-RSA | 6c8f1dc727c7117f7baf853ac980f9cd |
DNSSEC insecure
Validation of api.snhp.dev. — Not signed
| Zone | DS | Keys | Algorithms | Outcome |
|---|---|---|---|---|
| . | trust_anchor | 20326, 38696 | 8, 8 | Verified |
| dev. | present | 60074 | 8 | Verified |
| snhp.dev. | absent | Unsigned (proven) parent-signed NSEC/NSEC3 proves an unsigned delegation |
Authentication No authorisation required
The endpoint answered without asking for a token. Anyone who knows the URL can reach it.
| Result | No authorisation required |
|---|---|
| HTTP status | 200 |
| Header | Value |
|---|---|
| strict-transport-security | max-age=31536000; includeSubDomains |
| content-security-policy | default-src 'none'; frame-ancestors 'none' |
| x-content-type-options | nosniff |
| x-frame-options | DENY |
| referrer-policy | no-referrer |
Transports 2 probes
| Transport | URL | Outcome | Status | Location |
|---|---|---|---|---|
| streamable-http | https://api.snhp.dev/mcp/ | Verified | 200 | |
| http (plaintext) | http://api.snhp.dev/mcp/ | HTTPS enforced | 301 | https://api.snhp.dev/mcp/ |
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability.
auction_bid Optimal auction bid ~485
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.
| Name | Type | Req | Description |
|---|---|---|---|
| auction_format | string | yes | 'first_price' (sealed), 'second_price_vickrey', or 'english_ascending'. |
| competitor_value_prior | object | yes | 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}}. |
| my_valuation | number | yes | What the item is worth to YOU, in dollars. |
| n_competing_bidders | integer | yes | How many OTHER bidders there are (not counting you). |
| reserve_price | — | — | The auction's reserve/minimum bid in dollars, if any (optional). |
| risk_aversion | number | — | Your risk aversion; 1.0 = risk-neutral (default 1.0). |
| Name | Type | Req | Description |
|---|---|---|---|
| dominant_strategy | — | — | — |
| error | — | — | — |
| expected_surplus | — | — | — |
| optimal_bid | — | — | — |
| rationale | — | — | — |
| win_probability | — | — | — |
No examples provided.
auction_reserve Revenue-optimal reserve price ~292
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}}).
| Name | Type | Req | Description |
|---|---|---|---|
| bidder_value_prior | object | yes | Rough model of what bidders will pay, e.g. {family:'uniform', params:{low:2000, high:8000}}. |
| n_bidders | integer | yes | How many bidders you expect. |
| seller_valuation | number | yes | What the item is worth to YOU, in dollars (your floor). |
| Name | Type | Req | Description |
|---|---|---|---|
| error | — | — | — |
| expected_efficiency_loss | — | — | — |
| expected_revenue | — | — | — |
| expected_revenue_no_reserve | — | — | — |
| rationale | — | — | — |
| reserve_price | — | — | — |
No examples provided.
clearance_price Clearance price & markdown schedule ~451
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.
| Name | Type | Req | Description |
|---|---|---|---|
| arrival_rate_per_second | number | yes | Expected shoppers per SECOND (= expected total shoppers / horizon_seconds). |
| buyer_arrival_prior | object | yes | Rough model of buyer willingness-to-pay, e.g. {family:'uniform', params:{low:40, high:150}}. |
| horizon_seconds | number | yes | Selling window in SECONDS (14 days = 14*24*3600 = 1209600). |
| inventory | integer | yes | Number of units you must sell before the cutoff. |
| n_simulations | integer | — | Monte-Carlo sample count for the estimate (default 2000). |
| seed | integer | — | RNG seed for reproducibility (default 42). |
| Name | Type | Req | Description |
|---|---|---|---|
| dynamic_schedule | — | — | — |
| dynamic_value_estimate | — | — | — |
| error | — | — | — |
| rationale | — | — | — |
| sellthrough_rate | — | — | — |
| static_expected_revenue | — | — | — |
| static_price | — | — | — |
| static_simulated_revenue | — | — | — |
No examples provided.
memory_load Load agent memory ~148
Load a memory you saved in an earlier session — retrieval is free. Get back an encrypted blob you parked earlier (the blind locker) by its claim `ticket`. Returns {ok, blob_b64, size_bytes, expires_at} — the ciphertext you saved, which only YOU can decrypt. A wrong owner reads as a missing ticket; an expired TTL is `expired`; a lost at-rest key is `at_rest_key_unavailable`. Free (the save settled it).
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | yes | The same SNHP API key you saved under (a different owner reads as a missing ticket). |
| ticket | string | yes | The claim ticket returned by memory_save. |
| Name | Type | Req | Description |
|---|---|---|---|
| blob_b64 | — | — | — |
| charged | — | — | — |
| code | — | — | — |
| error | — | — | — |
| expires_at | — | — | — |
| ok | — | — | — |
| reason | — | — | — |
| size_bytes | — | — | — |
No examples provided.
memory_save Save agent memory (blind locker) ~279
Persistent memory for your agent across sessions — save now, load in any later session. You encrypt before saving; the store holds only ciphertext (blind custody) and signs a receipt over its hash — it cannot read your memory. Saving uses your prepaid wallet; a new key's 50¢ starter credit covers your first saves, and loading it back (memory_load) is free. `blob_b64` is YOUR ciphertext as base64 — encrypt BEFORE saving; keys never transit, contents are never logged, so a breach leaks only sealed boxes. Charged a thin flat fee ONLY on durable store (empty/oversize/unencodable is uncharged). ttl_seconds is clamped to [60s, 7d] and the effective expires_at is returned. The receipt's content_hash is over YOUR ciphertext, so you can prove what you stored without the store ever seeing plaintext.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | yes | Your SNHP API key (a new key's 50c starter credit covers first saves). |
| blob_b64 | string | yes | YOUR ciphertext as base64 — encrypt BEFORE saving; the store holds only the sealed box and cannot read it. |
| ttl_seconds | — | — | How long to keep it, clamped to [60s, 7 days]; the effective expiry is returned (optional). |
| Name | Type | Req | Description |
|---|---|---|---|
| charged | — | — | — |
| code | — | — | — |
| error | — | — | — |
| expires_at | — | — | — |
| ok | — | — | — |
| price_millicents | — | — | — |
| reason | — | — | — |
| receipt | — | — | — |
| size_bytes | — | — | — |
| ticket | — | — | — |
| ticket_hash | — | — | — |
No examples provided.
negotiate Negotiate — your optimal next move ~772
Your math-optimal next move in any price negotiation — free, no account or key needed. USE THIS WHEN: you're haggling over a single PRICE across multiple back-and- forth rounds and want a better outcome than winging it. Validated edge: ~12% better head-to-head (measured on this recommender, n=20 paired LLM negotiations, 95% CI +6.5-17.4%, p<0.0001). NOT FOR: one-shot or fixed prices (it'll tell you to just negotiate directly); multi-issue bundles (use negotiate_bundle — it logrolls across several linked issues); or non-price decisions like accept-vs-decline a job offer (just reason it through). You provide only what you already know — no game theory: side "sell" or "buy" walk_away your reservation in dollars (seller=floor/minimum, buyer=ceiling/max) target your aspiration in dollars (seller=high, buyer=low) counterparty_offers their offers so far, in dollars, oldest first rounds_left (optional, default 8) roughly how many back-and-forths remain compute_ms (optional, default 0; EXPERIMENTAL) milliseconds of Monte-Carlo rollouts to spend refining the move. 0 = instant closed form. Validated to show NO realized edge over the closed form (n=400, mc_validation.py) — kept off by default as a research mechanism, not a quality improvement. The reply carries a "compute" block You get back, in dollars: {"action": "counter"|"accept"|"walk", "recommended_price": 5387.0, "message": "...the best I can do is $5,387.00", "fit": {...}, "expected_settlement": 4943.5, "confidence": 0.62} WORKED EXAMPLE — selling a contract, floor $4,000, hope $6,000, the buyer has bid $4,200 then $4,500: negotiate(side="sell", walk_away=4000, target=6000, counterparty_offers=[4200, 4500], rounds_left=6) -> counter ~$5,387 with a ready-to-send message; ACCEPT once their bid crosses the optimal target; WALK if they stay below your floor near the deadline. Works against…
| Name | Type | Req | Description |
|---|---|---|---|
| compute_ms | integer | — | EXPERIMENTAL. Milliseconds of Monte-Carlo rollouts to spend refining the move; 0 = instant closed form (validated to show no realized edge, off by default). |
| counterparty_offers | — | — | The other side's offers so far, in dollars, oldest first. Omit if they haven't offered yet. |
| item | string | — | Short label for what's being negotiated (used only in the drafted message). |
| my_previous_offers | — | — | Your own offers so far, in dollars, oldest first (optional context). |
| rounds_left | integer | — | Roughly how many back-and-forth rounds remain before the deadline (default 8). |
| side | string | yes | Which side you are: 'sell' or 'buy'. |
| target | number | yes | Your aspiration price in dollars (seller: high; buyer: low). |
| walk_away | number | yes | Your reservation price in dollars — the worst you'd accept (seller: your floor/minimum; buyer: your ceiling/maximum). |
| Name | Type | Req | Description |
|---|---|---|---|
| action | — | — | — |
| compute | — | — | — |
| confidence | — | — | — |
| error | — | — | — |
| expected_settlement | — | — | — |
| fit | — | — | — |
| message | — | — | — |
| rationale | — | — | — |
| recommended_price | — | — | — |
No examples provided.
negotiate_bundle Negotiate a bundle — logroll linked issues ~912
Negotiate several linked issues at once by logrolling — free, no account or key needed. USE THIS WHEN: a deal has more than one issue on the table and they trade off — a job offer (base + equity + signing), a SaaS contract (price + seats + term + SLA), any package deal. It concedes on the issues you care about LESS (and the other side cares about MORE) to win the ones you care about most — a trade that beats splitting every issue down the middle. For a single PRICE, use negotiate instead. Provide `issues`: a list of {"name", "options" (the choices), "my_utility" (how good each option is to YOU — one number per option, any scale), "their_utility" (how good each option is to THEM — their preference direction)}. Optionally `my_priorities` ({issue_name: weight}, how much each issue matters to you) and `their_offers` (their packages so far as {issue_name: option}, oldest first — this is what lets it INFER their priorities). Returns {action, recommended_offer (issue -> option), message, my_utility, their_expected_utility, inferred_their_priorities, trade_logic, fit, confidence, acceptance_probability}. Validated (separately from the single-issue +12%): returns a Pareto-efficient package that beats naive "split-every-issue-down-the-middle" bargaining by ~40% joint surplus (300 random 4-issue profiles). HONEST CAVEAT: the priority INFERENCE layered on top is weak (recovery r≈0.3) and currently adds only ~1% (and can be slightly NEGATIVE against some opponents) over the same engine run with no inference — so the proven value today is the efficient-package search, not (yet) the logrolling edge. Optional timing refinement: pass `rounds_left` (bargaining rounds remaining) with `compute_ms` > 0 to spend that many ms of Monte-Carlo rollouts choosing WHICH package to hold for as the other side concedes over the rounds — a firmer package closes later (discounted) than a generous one. 0 = the instant closed-form package; the reply then carries a `compute` block. Modest by desig…
| Name | Type | Req | Description |
|---|---|---|---|
| compute_ms | integer | — | EXPERIMENTAL. Milliseconds of rollouts to choose WHICH package to hold as they concede; 0 = instant closed-form package. |
| issues | array | yes | One dict per issue: {name, options (the choices), my_utility (value of each option to YOU), their_utility (value to THEM)} — utilities are one number per option, any scale. |
| my_batna | number | — | Your best alternative to no deal, as a utility fraction in [0,1] (default 0.40); the returned package is guaranteed to beat it. |
| my_priorities | — | — | {issue_name: weight} — how much each issue matters to you (any scale). Optional. |
| rounds_left | integer | — | Bargaining rounds remaining (used with compute_ms for the timing tier; default 8). |
| their_batna_estimate | number | — | Your estimate of the other side's BATNA, [0,1] (default 0.40). |
| their_offers | — | — | Packages the other side has tabled, oldest first, each as {issue_name: chosen_option} — lets it infer their priorities. |
| Name | Type | Req | Description |
|---|---|---|---|
| acceptance_probability | — | — | — |
| action | — | — | — |
| compute | — | — | — |
| confidence | — | — | — |
| error | — | — | — |
| fit | — | — | — |
| inferred_their_priorities | — | — | — |
| message | — | — | — |
| my_utility | — | — | — |
| recommended_offer | — | — | — |
| their_expected_utility | — | — | — |
| trade_logic | — | — | — |
No examples provided.
score_deal Score a deal against the Pareto frontier ~334
Score how good a deal is against your floor/target — free, no account or key needed. Score a settled package against the exact Pareto frontier — the SNHP leaderboard metric ("dollars left on the table") for YOUR negotiation. Args: issues: one dict per issue: {"name": str, "options": [labels], "my_utility": [per-option value to me], "their_utility": [per-option value to them]} — both sides' TRUE per-option values. my_weights: {issue_name: weight} — my true priorities (any scale). their_weights: {issue_name: weight} — their true priorities. package: the settled deal, {issue_name: option_label}. notional: deal size in dollars for the dollars-left framing. Returns realized joint welfare, the frontier best, the naive middle-split baseline, frontier capture, logroll capture, and dollars_left_on_table.
| Name | Type | Req | Description |
|---|---|---|---|
| issues | array | yes | One dict per issue: {name, options, my_utility, their_utility} — both sides' TRUE per-option values (one number per option). |
| my_weights | object | yes | {issue_name: weight} — your true priorities (any scale). |
| notional | number | — | Deal size in dollars, used for the 'dollars left on the table' framing (default 10000). |
| package | object | yes | The settled deal as {issue_name: chosen_option_label}. |
| their_weights | object | yes | {issue_name: weight} — their true priorities (any scale). |
| Name | Type | Req | Description |
|---|---|---|---|
| dollars_left_on_table | — | — | — |
| error | — | — | — |
| frontier_best | — | — | — |
| frontier_capture | — | — | — |
| joint_welfare | — | — | — |
| logroll_capture | — | — | — |
| my_utility | — | — | — |
| naive_split | — | — | — |
| their_utility | — | — | — |
No examples provided.
session_advise Session move — next single-price offer ~157
Your next move inside a receipted session (single-issue) — no additional charge (the $2 at session_open covered it). Pass the FULL offer history each time, oldest first. Returns move, exact price, ready-to-send message, and the receipt (why[], context_hash, deterministic compute block).
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | yes | The API key that opened the session. |
| my_offers | — | — | Your own offer history, in dollars, oldest first (optional). |
| rounds_left | — | — | Bargaining rounds remaining (optional). |
| session_id | string | yes | The session_id returned by session_open. |
| their_offers | array | yes | The FULL counterparty offer history, in dollars, oldest first. |
| Name | Type | Req | Description |
|---|---|---|---|
| compute | — | — | — |
| confidence_note | — | — | — |
| context_hash | — | — | — |
| error | — | — | — |
| message | — | — | — |
| move | — | — | — |
| move_index | — | — | — |
| offer | — | — | — |
| policy_id | — | — | — |
| receipt | — | — | — |
| why | — | — | — |
No examples provided.
session_bundle Session move — multi-issue bundle ~340
Multi-issue logrolled advice inside a receipted session — no additional charge. The logrolling tier, the thing the free tool does NOT have. Trade the issues you care less about for the ones you value: issues = [{name, options, my_utility (per option), their_utility (your read of their direction)}]; their_offers = packages they've tabled, oldest first. Returns the recommended package, trade logic, inferred counterparty priorities, acceptance probability, and the receipt. Deterministic closed form — no rollout theater. The package is guaranteed to clear YOUR stated BATNA (enforced, not promised).
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | yes | The API key that opened the session. |
| cooperation | — | — | Optional cooperation dial in [0,1] biasing toward joint surplus. |
| issues | array | yes | One dict per issue: {name, options, my_utility (per option), their_utility (your read of their direction)}. |
| my_batna | number | — | Your BATNA as a utility fraction in [0,1] (default 0.40); the package is guaranteed to clear it. |
| my_priorities | — | — | {issue_name: weight} — how much each issue matters to you (optional). |
| session_id | string | yes | The session_id returned by session_open. |
| their_batna_estimate | number | — | Your estimate of their BATNA, [0,1] (default 0.40). |
| their_offers | — | — | Packages they've tabled, oldest first, each {issue_name: option} (optional). |
| Name | Type | Req | Description |
|---|---|---|---|
| acceptance_probability | — | — | — |
| confidence_note | — | — | — |
| context_hash | — | — | — |
| error | — | — | — |
| message | — | — | — |
| move | — | — | — |
| move_index | — | — | — |
| package | — | — | — |
| receipt | — | — | — |
| their_expected_utility | — | — | — |
| why | — | — | — |
No examples provided.
session_close Close session & get the signed receipt ~164
Close a receipted session and get the signed summary receipt. Optional — sessions also expire on their own — but closing timestamps the outcome, which helps the machine learn real round-counts per category. Returns the `closed` flag AND a signed session-summary receipt (GAUNTLET #4) — moves count, total charged (one $2 open), and the per-move context_hashes — to hand your principal. An unknown session or key mismatch leaves `closed` false and returns an `error` instead of the receipt (indistinguishable, so a session id can't be probed).
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | yes | The API key that opened the session. |
| session_id | string | yes | The session_id to close. |
| Name | Type | Req | Description |
|---|---|---|---|
| closed | — | — | — |
| error | — | — | — |
| receipt | — | — | — |
No examples provided.
session_open Open a $2 receipted session ~364
Open a $2 receipted negotiation session: deterministic, replayable, every move signed. PAID ($2 once, from your credit balance) — the $2 covers EVERY move of this negotiation (up to 10 moves, 7 days), tuned to the category. A new key's 50¢ starter credit is a taste, not enough for a session — top up first. category: resale | supply | retail. side: buy | sell. walk_away = your true floor (sell) / ceiling (buy) — private, never crossed. Pass their_offers to get the first move back immediately with the session. Subsequent moves: session_advise with the session_id — no further charge.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | string | yes | Your SNHP API key; $2 is debited from its credit balance (covers every move of this one negotiation). |
| category | string | yes | Negotiation category for tuning: 'resale' | 'supply' | 'retail'. |
| my_offers | — | — | Your own offers so far, in dollars, oldest first (optional). |
| rounds_left | — | — | Bargaining rounds remaining for this move (optional; overrides the category default). |
| seed | integer | — | RNG seed for the deterministic engine (default 0). |
| side | string | yes | Which side you're on: 'buy' or 'sell'. |
| target | number | yes | Your aspiration price in dollars. |
| their_offers | — | — | The other side's offers so far, in dollars, oldest first — pass to get the first move back with the session (optional). |
| walk_away | number | yes | Your true reservation in dollars — floor (sell) / ceiling (buy); private, never crossed. |
| Name | Type | Req | Description |
|---|---|---|---|
| balance_after | — | — | — |
| category | — | — | — |
| context_hash | — | — | — |
| error | — | — | — |
| expires_at | — | — | — |
| first_move | — | — | — |
| first_move_error | — | — | — |
| funding | — | — | — |
| how_to_pay | — | — | — |
| max_moves | — | — | — |
| price_cents | — | — | — |
| price_millicents | — | — | — |
| receipt | — | — | — |
| session_id | — | — | — |
| side | — | — | — |
No examples provided.
stable_match Stable matching (Gale–Shapley) ~340
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 [].
| Name | Type | Req | Description |
|---|---|---|---|
| proposers | array | yes | List of {id, preferences:[ids of the OTHER side, most-wanted first]}. The result is PROPOSER-optimal — put the side you want to favor here. |
| receivers | array | yes | List of {id, preferences:[...], capacity (optional, default 1)}. |
| Name | Type | Req | Description |
|---|---|---|---|
| blocking_pairs | — | — | — |
| error | — | — | — |
| matching | — | — | — |
| n_proposals | — | — | — |
| unmatched_proposers | — | — | — |
No examples provided.
store_catalog Store catalog & wallet balance ~309
See what's on the shelf — free, no key needed: prices, predicates, receipt scheme, and your balance. THE STORE: one counter, one prepaid wallet, many slots. One read covers the whole shelf — the commodity slots, the blind locker (agent memory), and the paid receipted-session SKU (folds in what nextmove_catalog used to report separately). Every commodity slot settles ON DELIVERY: the wallet is debited only when a machine-checkable predicate passes — a failed fetch is never charged, because here you cannot pay for nothing. Each receipt names the backend that served and its EXACT wholesale cost (passthrough, no per-call markup); the counter's cut is a published fee on wallet top-ups, not on the calls — 5% + a fixed 30¢ per transaction (the 30¢ is the card rail's own per-transaction toll, passed through). Every new key gets a one-time 50¢ starter credit — unconditional, no card — enough to taste the shelf before funding it. Don't see the capability you need? store_request logs it; unmet demand decides what gets stocked next. Returns the money unit (millicents, 1000 per cent), per-slot {tier, max_price_millicents, predicate_id, request_doc, serving-backend ids}, the anchor SKUs, the paid_session card, and the two pricing facts. Never returns key material.
Input schema present but exposes no named parameters.
| Name | Type | Req | Description |
|---|---|---|---|
| admission | — | — | — |
| counter_fee | — | — | — |
| counter_fee_pct | — | — | — |
| error | — | — | — |
| keys | — | — | — |
| millicents_per_cent | — | — | — |
| paid_session | — | — | — |
| request_privacy | — | — | — |
| slots | — | — | — |
| starter_credit | — | — | — |
| unit | — | — | — |
No examples provided.
store_request Request a capability / check a filing ~357
Ask for a capability we don't sell yet — free; filings are public and drive what we stock. Two reads in one tool (absorbs the old store_request_status / nextmove_request): pass `request_id` to RE-QUERY a filing's status instead of filing anew — returns {found, request_id, status, status_note, filed_at, door, text} (found: false on an unknown id). Without a request_id it FILES a new ask and returns {request_id, status, watch, check}: every filing is logged verbatim (size-capped, stored as data, never rendered raw) and gets an id you can come back to (GAUNTLET #5). Check any filing with GET /v1/store/request/{id}; the public count is GET /v1/store/requests. Unmet demand decides what gets stocked next — the shelf writes itself from what agents ask for and can't get. Pass watch=True WITH an api_key when filing to flag the ask for a heads-up on a status flip (poll store_my_requests to see it — poll-based, no push); an anonymous watch is ignored, and the chosen flag is echoed as `watch`.
| Name | Type | Req | Description |
|---|---|---|---|
| api_key | — | — | Your SNHP API key (optional; required only if you set watch=True). |
| request_id | — | — | Pass an existing filing id to RE-QUERY its status instead of filing a new request. |
| text | — | — | What capability you want that we don't stock yet (free-text). Omit when re-querying with request_id. |
| watch | boolean | — | Set True (with an api_key) to flag the ask for a status-flip heads-up; anonymous watches are ignored. |
| Name | Type | Req | Description |
|---|---|---|---|
| check | — | — | — |
| door | — | — | — |
| error | — | — | — |
| filed_at | — | — | — |
| found | — | — | — |
| request_id | — | — | — |
| same_ask_count | — | — | — |
| status | — | — | — |
| status_note | — | — | — |
| text | — | — | — |
| watch | — | — | — |
No examples provided.